【问题标题】:cassandra, secondary indexes building during adding of a new node lasts forevercassandra,在添加新节点期间建立的二级索引永远持续
【发布时间】:2016-02-25 11:19:14
【问题描述】:

我正在尝试向我们的集群添加新节点(cassandra 2.1.11、16 个节点、32Gb 内存、2x3Tb 硬盘、8 核 CPU、1 个数据中心、2 个机架,每个节点上大约有 700Gb 的数据)。新节点启动后,16 个现有节点的数据(总计约 600Gb)成功传输到新节点,并开始构建二级索引。二级索引构建过程看起来很正常,我看到一些二级索引构建和一些流任务成功完成的信息:

INFO  [StreamReceiveTask:9] 2015-11-22 02:15:23,153 StreamResultFuture.java:180 - [Stream #856adc90-8ddd-11e5-a4be-69bddd44a709] Session with /192.168.21.66 is complete

INFO  [StreamReceiveTask:9] 2015-11-22 02:15:23,152 SecondaryIndexManager.java:174 - Index build of [docs.docs_ex_pl_ph_idx, docs.docs_lo_pl_ph_idx, docs.docs_author_login_idx, docs.docs_author_extid_idx, docs.docs_url_idx] complete

根据日志,目前 16 个流中有 9 个已成功完成。一切看起来都很好,除了一个问题:这个过程已经持续了 5 天。日志中没有错误,没有任何可疑之处,只是进度非常缓慢。

nodetool compactionstats -H

显示

   Secondary index build   ...    docs    882,4 MB   1,69 GB   bytes     51,14%

所以有一些建索引的过程,也有一些进展,但是很慢,半小时1%左右。

新节点和任何现有节点之间的唯一显着区别是,cassandra java 进程有 21k 个打开文件,相比之下,任何现有节点上打开文件有 300 个,而新节点上的数据目录中有 80k 个文件。任何现有节点上数据目录中 300-500 个文件的对比。

正常吗?以这个速度看来我要花 16 周左右的时间才能再添加 16 个节点。

【问题讨论】:

  • 你设置了流式套接字超时吗?
  • 不,我没有,streaming_socket_timeout_in_ms 属性在配置中被注释掉,我认为没有与套接字相关的问题,因为所有数据都已经传输到目标节点,现在它建立二级索引并且速度很慢
  • 二级索引构建速度非常慢,但如果您无限期挂起,则可能是由于流式会话,因此请确保您设置套接字超时。
  • 你能负担得起删除索引吗?无论如何,它们在生产查询中表现不佳。
  • 实际上我不能放弃它,顺便说一句,它足以满足我的查询。索引构建过程似乎并没有停滞不前,它实际上有一些进展,只是非常缓慢,尽管目标节点上有很多空闲的未使用的 cpu/disk/mem 资源。

标签: cassandra datastax


【解决方案1】:

我知道这是一个老问题,但我们在 2.1.13 中使用 DTCS 遇到了这个确切的问题。我们能够通过将内存刷新阈值增加到 0.7 在我们的测试环境中修复它 - 这对我们没有任何意义,但可能值得尝试。

【讨论】:

  • 感谢您的回答,在我的情况下,解决方案主要是将同时压缩的数量从一个(默认)增加到七个
猜你喜欢
  • 2016-05-02
  • 2018-06-23
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-07-25
  • 2018-05-04
  • 1970-01-01
  • 2016-06-29
相关资源
最近更新 更多