单个节点上的Cassandra读取重载
几个星期以来，我们在cassandra 2.1.8集群上有一个无法理解的重载节点。ReadStage线程池通常已满，此节点上有许多已丢弃的任务，只有此任务。单个节点上的Cassandra读取重载,cassandra,Cassandra,几个星期以来，我们在cassandra 2.1.8集群上有一个无法理解的重载节点。ReadStage线程池通常已满，此节点上有许多已丢弃的任务，只有此任务。 该节点接收的全局负载是其他节点负载的两倍。 它是一个9节点集群，RF为3 告密者是网络拓扑，但拓扑文件是默认的。因此，所有节点都被视为位于同一机架和同一数据中心中 当我们选择此节点上承载的单个数据，并尝试多次从cqlsh中选择它时（使用consistency one），需要从重载节点中以90%的比例选择数据（参见跟踪上的）。即使数据也托管在
该节点接收的全局负载是其他节点负载的两倍。
它是一个9节点集群，RF为3 告密者是网络拓扑，但拓扑文件是默认的。因此，所有节点都被视为位于同一机架和同一数据中心中 当我们选择此节点上承载的单个数据，并尝试多次从cqlsh中选择它时（使用
consistency one跟踪上的）。即使数据也托管在通过cqlsh连接到的节点上，也会发生这种情况。
我们尝试将节点隔离在拓扑中的特定机架中，但没有改变任何内容
节点已被删除（停用）并再次添加。
本周末又添加了一个节点（以前集群中只有8个节点）。
但重载节点没有任何变化。
新节点的协调器也更喜欢重载节点
问题只出现在读取请求上。
突变没有任何问题
什么可以解释这一点？
除了告密者之外，协调人还有什么可以选择它将请求哪个节点的吗？
我们能做些什么来解决这个问题
谢谢你的建议
编辑：
这个问题在几张桌子上提出。但是，作为信息，这是我们进行测试的表的描述：
CREATE TABLE main.app (
id uuid PRIMARY KEY,
acc uuid,
apdex_f int,
apdex_t int,
cnx uuid,
iid bigint,
name text,
prod boolean,
sla_active boolean,
st ascii,
techno text,
tz ascii
) WITH bloom_filter_fp_chance = 0.01
AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
AND comment = ''
AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99.0PERCENTILE';
这是经过测试的查询：
SELECT name from app where id = 630bbc5e-387a-424a-a8a3-e4948ec7470a;
这是跟踪（我刚刚执行了10次，结果几乎与此相同）
该数据存在于我连接到的节点上（172.16.0.1）
我刚刚注意到另一件奇怪的事情：新节点（上周末添加的）已经比重载节点保存了更多的数据（3.5倍），即使它在将近10天后被添加到集群中。您使用的查询和/或模式是什么？我最初的想法是，在这个节点上要么有很多墓碑，要么有一个非常大的分区。如果你看一下追踪，它会告诉你有很多墓碑。如果没有，请检查该节点上的系统日志并搜索“大分区”-如果有大分区，它将显示在那里，并且还应为您提供分区ID。跟踪中不会出现墓碑。测试请求是在一个非常小的CF上，我用完整的表描述编辑了消息。事实上我错了。有墓碑。我在问题上添加了线索。无论如何，我不明白为什么协调器的行为会依赖于墓碑。感谢您添加更多信息-肯定不是一个大的分区问题，因为您甚至没有使用集群列。从.8到.1发送请求的时间间隔为70毫秒，这可能有很多原因——GC暂停、大数据负载、网络/硬件问题……如果您在这些服务器上运行其他进程/应用程序，也可能会产生干扰。system.log中有什么突出的地方吗？警告、错误、GC消息？谢谢您的回答。.8节点位于专用服务器上，是一台物理机器。cassandra进程单独使用8个CPU核。gc日志处于活动状态，很少有gc暂停。延迟是过载的结果：ReadStage线程池通常已满（32），有时多达数千个挂起的任务。我不明白的是，为什么协调员90%的时间都在请求这个节点，而这个数据在另外两个节点上。您使用的查询和/或模式是什么？我最初的想法是，在这个节点上要么有很多墓碑，要么有一个非常大的分区。如果你看一下追踪，它会告诉你有很多墓碑。如果没有，请检查该节点上的系统日志并搜索“大分区”-如果有大分区，它将显示在那里，并且还应为您提供分区ID。跟踪中不会出现墓碑。测试请求是在一个非常小的CF上，我用完整的表描述编辑了消息。事实上我错了。有墓碑。我在问题上添加了线索。无论如何，我不明白为什么协调器的行为会依赖于墓碑。感谢您添加更多信息-肯定不是一个大的分区问题，因为您甚至没有使用集群列。从.8到.1发送请求的时间间隔为70毫秒，这可能有很多原因——GC暂停、大数据负载、网络/硬件问题……如果您在这些服务器上运行其他进程/应用程序，也可能会产生干扰。system.log中有什么突出的地方吗？警告、错误、GC消息？谢谢您的回答。.8节点位于专用服务器上，是一台物理机器。cassandra进程单独使用8个CPU核。gc日志处于活动状态，很少有gc暂停。延迟是过载的结果：ReadStage线程池通常已满（32），有时多达数千个挂起的任务。我不明白的是，为什么协调员90%的时间都在请求这个节点，而这个数据在另外两个节点上。
activity | timestamp | source | source_elapsed
-----------------------------------------------------------------------------------------------------+----------------------------+------------+----------------
Execute CQL3 query | 2015-11-02 19:03:19.866000 | 172.16.0.1 | 0
Parsing SELECT name from app where id = 630bbc5e-387a-424a-a8a3-e4948ec7470a; [SharedPool-Worker-7] | 2015-11-02 19:03:19.867000 | 172.16.0.1 | 36
Preparing statement [SharedPool-Worker-7] | 2015-11-02 19:03:19.867000 | 172.16.0.1 | 135
reading data from /172.16.0.8 [SharedPool-Worker-7] | 2015-11-02 19:03:19.868000 | 172.16.0.1 | 354
Sending READ message to /172.16.0.8 [MessagingService-Outgoing-/172.16.0.8] | 2015-11-02 19:03:19.868000 | 172.16.0.1 | 394
READ message received from /172.16.0.1 [MessagingService-Incoming-/172.16.0.1] | 2015-11-02 19:03:19.935000 | 172.16.0.8 | 43
Executing single-partition query on app [SharedPool-Worker-18] | 2015-11-02 19:03:19.935000 | 172.16.0.8 | 479
Acquiring sstable references [SharedPool-Worker-18] | 2015-11-02 19:03:19.935000 | 172.16.0.8 | 500
Merging memtable tombstones [SharedPool-Worker-18] | 2015-11-02 19:03:19.935000 | 172.16.0.8 | 518
Key cache hit for sstable 5 [SharedPool-Worker-18] | 2015-11-02 19:03:19.935000 | 172.16.0.8 | 544
Seeking to partition beginning in data file [SharedPool-Worker-18] | 2015-11-02 19:03:19.935000 | 172.16.0.8 | 560
Skipped 0/1 non-slice-intersecting sstables, included 0 due to tombstones [SharedPool-Worker-18] | 2015-11-02 19:03:19.936000 | 172.16.0.8 | 747
Merging data from memtables and 1 sstables [SharedPool-Worker-18] | 2015-11-02 19:03:19.936000 | 172.16.0.8 | 772
Read 1 live and 0 tombstone cells [SharedPool-Worker-18] | 2015-11-02 19:03:19.936000 | 172.16.0.8 | 808
Enqueuing response to /172.16.0.1 [SharedPool-Worker-18] | 2015-11-02 19:03:19.936000 | 172.16.0.8 | 873
Sending REQUEST_RESPONSE message to /172.16.0.1 [MessagingService-Outgoing-/172.16.0.1] | 2015-11-02 19:03:19.936000 | 172.16.0.8 | 1119
REQUEST_RESPONSE message received from /172.16.0.8 [MessagingService-Incoming-/172.16.0.8] | 2015-11-02 19:03:19.937000 | 172.16.0.1 | 70396
Processing response from /172.16.0.8 [SharedPool-Worker-11] | 2015-11-02 19:03:19.937000 | 172.16.0.1 | 70431
Request complete | 2015-11-02 19:03:19.936484 | 172.16.0.1 | 70484