从 cassandra 2.1.4 升级到 2.1.5答案

【问题标题】：Upgrade from cassandra 2.1.4 to 2.1.5从 cassandra 2.1.4 升级到 2.1.5
【发布时间】：2015-08-04 22:39:35
【问题描述】：

大家

几天前，我将我们的 6 节点 EC2 集群从 cassandra 2.1.4 升级到了 2.1.5。

从那时起，我的所有节点的 cpu 使用率都“爆炸式增长”——它们大部分时间都是 100% cpu，它们的平均负载在 100-300 之间（！！！）。

这不是在升级后立即开始的。几个小时后，其中一个节点开始，慢慢地，越来越多的节点开始表现出相同的行为。它似乎与我们最大的列族的压缩相关，并且在压缩完成后（开始后约 24 小时），节点似乎恢复正常。才2天左右，希望不会再发生，不过我还在监控中。

这是我的问题

这是错误还是预期行为？

如果这是预期的行为 -

这个问题的解释是什么？
它是否记录在我遗漏的某个地方？
我应该以不同的方式进行升级吗？每 24 小时左右一次可能有 1 或 2 个节点？最佳做法是什么？

如果是错误 -

知道吗？
我应该在哪里报告这个？我应该添加哪些数据？
降级到 2.1.4 是否可行？

对此的任何反馈都会很棒

谢谢

阿米尔

更新：

这是相关表格的结构。

创建表 tbl1 (

key text PRIMARY KEY,

created_at timestamp,

customer_id bigint,

device_id bigint,

event text,

fail_count bigint,

generation bigint,

gr_id text,

imei text,

raw_post text,

"timestamp" timestamp

) 紧凑的存储空间

AND bloom_filter_fp_chance = 0.01

AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'

AND comment = ''

AND compaction = {'min_threshold': '4', 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32'}

AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}

AND dclocal_read_repair_chance = 0.0

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 = 'NONE';

日志并没有透露太多信息（至少对我而言）。这是日志外观的 sn-p

INFO [WRITE-/10.0.1.142] 2015-05-23 05:43:42,577 YamlConfigurationLoader.java:92 - 从文件加载设置：/etc/cassandra/cassandra.yaml

INFO [WRITE-/10.0.1.142] 2015-05-23 05:43:42,580 YamlConfigurationLoader.java:135 - 节点配置：[authenticator=AllowAllAuthenticator;授权人=允许所有授权人；自动快照=真； batch_size_warn_threshold_in_kb=5； batchlog_replay_throttle_in_kb=1024；广播_rpc_address=10.0.2.145; cas_contention_timeout_in_ms=1000； client_encryption_options=; cluster_name=Gryphonet21 集群； column_index_size_in_kb=64； commit_failure_policy=停止； commitlog_directory=/data/cassandra/commitlog; commitlog_segment_size_in_mb=32； commitlog_sync=定期； commitlog_sync_period_in_ms=10000; compaction_throughput_mb_per_sec=16；并发计数器写入=32；并发读取=32；并发写入=32； counter_cache_save_period=7200; counter_cache_size_in_mb=null； counter_write_request_timeout_in_ms=5000；交叉节点超时=假； data_file_directories=[/data/cassandra/data]; disk_failure_policy=停止； dynamic_snitch_badness_threshold=0.1； dynamic_snitch_reset_interval_in_ms=600000； dynamic_snitch_update_interval_in_ms=100； endpoint_snitch=GossipingPropertyFileSnitch;提示切换启用=真；提示_handoff_throttle_in_kb=1024；增量备份=假； index_summary_capacity_in_mb=null； index_summary_resize_interval_in_minutes=60； inter_dc_tcp_nodelay=false；节点间压缩=全部； key_cache_save_period=14400; key_cache_size_in_mb=null； max_hint_window_in_ms=10800000； max_hints_delivery_threads=2； memtable_allocation_type=heap_buffers; native_transport_port=9042; num_tokens=16;分区器=随机分区器； permissions_validity_in_ms=2000; range_request_timeout_in_ms=10000； read_request_timeout_in_ms=5000； request_scheduler=org.apache.cassandra.scheduler.NoScheduler; request_timeout_in_ms=10000； row_cache_save_period=0； row_cache_size_in_mb=0； rpc_address=0.0.0.0； rpc_keepalive=true； rpc_port=9160； rpc_server_type=同步； saved_caches_directory=/data/cassandra/saved_caches； seed_provider=[{class_name=org.apache.cassandra.locator.SimpleSeedProvider，参数=[{seeds=10.0.1.141,10.0.2.145,10.0.3.149}]}]； server_encryption_options=; snapshot_before_compaction=false； ssl_storage_port=7001； sstable_preemptive_open_interval_in_mb=50； start_native_transport=真； start_rpc=真；存储端口=7000； thrift_framed_transport_size_in_mb=15； tombstone_failure_threshold=100000； tombstone_warn_threshold=1000；涓流_fsync=假；涓流_fsync_interval_in_kb=10240； truncate_request_timeout_in_ms=60000; write_request_timeout_in_ms=2000]

INFO [HANDSHAKE-/10.0.1.142] 2015-05-23 05:43:42,591 OutboundTcpConnection.java:494 - 无法与 /10.0.1.142 握手版本

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,713 MessagingService.java:887 - 在过去 5000 毫秒内丢弃了 135 条 MUTATION 消息

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,713 StatusLogger.java:51 - 池名称 Active Pending Completed Blocked All Time Blocked

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,714 StatusLogger.java:66 - CounterMutationStage 0 0 0 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,714 StatusLogger.java:66 - ReadStage 5 1 5702809 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,715 StatusLogger.java:66 - RequestResponseStage 0 45 29528010 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,715 StatusLogger.java:66 - ReadRepairStage 0 0 997 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,715 StatusLogger.java:66 - MutationStage 0 31 43404309 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,716 StatusLogger.java:66 - GossipStage 0 0 569931 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,716 StatusLogger.java:66 - AntiEntropyStage 0 0 0 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,716 StatusLogger.java:66 - CacheCleanupExecutor 0 0 0 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,717 StatusLogger.java:66 - MigrationStage 0 0 9 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,829 StatusLogger.java:66 - ValidationExecutor 0 0 0 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,830 StatusLogger.java:66 - 采样器 0 0 0 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,830 StatusLogger.java:66 - MiscStage 0 0 0 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,831 StatusLogger.java:66 - CommitLogArchiver 0 0 0 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,831 StatusLogger.java:66 - MemtableFlushWriter 1 1 1756 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,831 StatusLogger.java:66 - PendingRangeCalculator 0 0 11 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,832 StatusLogger.java:66 - MemtableReclaimMemory 0 0 1756 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,832 StatusLogger.java:66 - MemtablePostFlush 1 2 3819 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,832 StatusLogger.java:66 - CompactionExecutor 2 32 742 0 0

INFO [ScheduledTasks:1] 2015-05-23 05:43:42,833 StatusLogger.java:66 - InternalResponseStage 0 0 0 0 0

INFO [HANDSHAKE-/10.0.1.142] 2015-05-23 05:43:45,086 OutboundTcpConnection.java:485 - 与 /10.0.1.142 的握手版本

更新：

问题仍然存在。我认为在每个节点上的一次压缩完成后，节点会恢复正常，但事实并非如此。几个小时后，CPU 跳到 100%，平均负载在 100-300 之间。

我正在降级回 2.1.4。

更新：

使用 phact 的 dumpThreads 脚本来获取堆栈跟踪。此外，尝试使用 jvmtop，但它似乎只是挂起。

输出太大，无法在此处粘贴，但您可以在 http://downloads.gryphonet.com/cassandra/ 找到它。

用户名：cassandra 密码：cassandra

【问题讨论】：

您在使用 DTCS 吗？什么压缩策略？
你能粘贴你的数据模型吗？
cassandra 日志中有什么内容？
你能拉出一个线程转储吗？方法如下——sudo su - cassandra -s /bin/bashwget https://gist.githubusercontent.com/phact/22aa5085e58a43de7425/raw/de435ea127f1acde1054ad3c6af4995856e1a1be/threadDump.shwget https://gist.githubusercontent.com/phact/6c2699e884950acd2ed0/raw/688827d8f1c0fc882985394f2e1ee5be21bef804/topthreads.pywget https://gist.githubusercontent.com/phact/22aa5085e58a43de7425/raw/de435ea127f1acde1054ad3c6af4995856e1a1be/threadDump.shexport mypid='cat /run/dse/dse.pid'sudo chmod 777 threadDump.sh./threadDump.sh $mypid 10 10粘贴jstack.out和top.out
或者将它们放到 pastebin 或其他东西上

标签： cassandra cassandra-2.1

【解决方案1】：

尝试使用 jvmtop 查看 cassandra 进程在做什么。它有两种模式，一种查看当前正在运行的线程，另一种显示每个类过程的 cpu 分布（--profile），将两个输出粘贴到此处

【讨论】：

我已将其中一个节点重新升级到 2.1.5。等待问题重现。有东西会第一时间更新

【解决方案2】：

回答我自己的问题 -

我们正在使用一个非常具体的节俭 API - describe_splits_ex，这似乎会导致问题。很明显，当 CPU 使用率达到 100% 时，查看所有不同线程的所有堆栈跟踪。对我们来说，这很容易解决，因为我们将此 api 用作优化，而不是必须的，所以我们停止使用它，问题就消失了。

但是，这个 api 也被 cassandra-hadoop 连接器使用（至少它在早期版本中使用过），所以如果你正在使用连接器，我会在升级到 2.1.5 之前进行测试。

不确定 2.1.5 中的哪些更改导致了该问题，但我知道它在 2.1.4 中没有发生，并且在 2.1.5 中一直发生。

【讨论】：