这是一个创建于 1109 天前的主题，其中的信息可能已经有所发展或是发生改变。
数据量大概在一百万条，一开始是每次插入建立一个新连接，发现 put 操作超时，后面改成了 put 共用一个连接，在跑了两小时后仍然超时，想问下各位有没有比较好的办法做这个操作，还是说我应该想办法了解为什么超时，服务器间网络是没有问题的。
 |
1
imherer 2021-11-08 18:31:07 +08:00
100w ？什么数据这么多数据，感觉这个不应该用 etcd 来做
|
 |
3
dallaslu 2021-11-08 18:32:43 +08:00
「 etcd （读作 et-see-dee ）是一种开源的分布式统一键值存储，用于分布式系统或计算机集群的共享配置、服务发现和的调度协调」
一百多万条了，要不要试试别的吧 |
 |
4
leonme 2021-11-08 18:38:15 +08:00 via iPhone
属于乱用中间件了……
|
 |
5
hopingtop 2021-11-08 20:44:54 +08:00
一百万数据并不多的。如果在读场景少的情况下。 从节点不多的情况，一般不会出现这样的情况。
出现问题，主要是看 client 的使用方式是否有问题，还有就是 ETCD 的配置。如果是云服务，一般是大多数场景的最佳配置。特别注意一下 关于 ETCD 存储大小和压缩相关的设置 看看 client 端吧。 如果是基于 v2 版本的 HTTP ， 也要注意一下 Request 包是否有什么问题。 还有就是每一个 KV ，V 是否过大？ 如果会其他语言，可以试着换一种语言的 Client 试试 |
 |
7
mogging 2021-11-08 21:48:02 +08:00 via Android
是不是--max-request-bytes 用的是默认值
|
 |
8
SmiteChow 2021-11-09 11:02:15 +08:00
etcd 也没想到自己被迫吃这么多 k-v
讲真，盲猜是一直在一个节点进行快速写入+内部节点同步导致 cpu 爆掉问题。 建议搞 pool ，把集群所有节点都连上，均匀写入以及控制写入频率。 |
 |
9
luoqeng 2021-11-09 12:27:14 +08:00
etcd 是用来存 Meta 数据的
|
 |
10
996635 2021-11-09 16:31:41 +08:00
检查 etcd 版本, 3.4 以后有优化
另外对于一个分布式系统来说, 并发写事务性能不会太高, 官方的 benchmark 是 10 万 KEY,QPS 有 33K, leader only 和 all members 差别还是蛮大的. |
|
11
996635 2021-11-09 16:34:42 +08:00
建议先查 etcd server log, 看一下超时的原因再做优化
|
Select Language