etcd 一次性插入大量数据导致超时

[kalista]

数据量大概在一百万条，一开始是每次插入建立一个新连接，发现 put 操作超时，后面改成了 put 共用一个连接，在跑了两小时后仍然超时，想问下各位有没有比较好的办法做这个操作，还是说我应该想办法了解为什么超时，服务器间网络是没有问题的。

[imherer]

100w ？什么数据这么多数据，感觉这个不应该用 etcd 来做

[kalista]

@imherer 一言难尽，属于历史遗留问题了，现在版本又得想办法做这个操作

[dallaslu]

「 etcd （读作 et-see-dee ）是一种开源的分布式统一键值存储，用于分布式系统或计算机集群的共享配置、服务发现和的调度协调」

一百多万条了，要不要试试别的吧

[leonme]

属于乱用中间件了……

[hopingtop]

一百万数据并不多的。如果在读场景少的情况下。 从节点不多的情况，一般不会出现这样的情况。
出现问题，主要是看 client 的使用方式是否有问题，还有就是 ETCD 的配置。如果是云服务，一般是大多数场景的最佳配置。特别注意一下 关于 ETCD 存储大小和压缩相关的设置
看看 client 端吧。 如果是基于 v2 版本的 HTTP ， 也要注意一下 Request 包是否有什么问题。
还有就是每一个 KV ，V 是否过大？
如果会其他语言，可以试着换一种语言的 Client 试试

[hopingtop]

@hopingtop 这里只单纯讨论为什么可能出现超时，不讨论为什么要这么用 ETCD

[mogging]

是不是--max-request-bytes 用的是默认值

[SmiteChow]

etcd 也没想到自己被迫吃这么多 k-v

讲真，盲猜是一直在一个节点进行快速写入+内部节点同步导致 cpu 爆掉问题。
建议搞 pool ，把集群所有节点都连上，均匀写入以及控制写入频率。

[luoqeng]

etcd 是用来存 Meta 数据的

[996635]

检查 etcd 版本, 3.4 以后有优化
另外对于一个分布式系统来说, 并发写事务性能不会太高, 官方的 benchmark 是 10 万 KEY,QPS 有 33K, leader only 和 all members 差别还是蛮大的.

[996635]

建议先查 etcd server log, 看一下超时的原因再做优化