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, 看一下超时的原因再做优化
|