卡桑德拉2.1集羣顯示持續的高CPU佔用率和響應速度很慢

在我們部署了5月3日。我們的3節點cassandra集羣變得非常緩慢，許多web請求都超時了。 EOD 5月3日，我們推出了另一臺m1.large機器來解決超時問題。話雖如此，該集羣仍然非常緩慢; 5月4日我們推出了5個i3.xLarge節點。這對我們的應用程序響應時間有相當大的幫助，5月5日我們從集羣中刪除了舊的m1.large。截至5月5日爲止，所有事情都很快速且響應迅速。今天早上，應用程序再次開始超時。卡桑德拉2.1集羣顯示持續的高CPU佔用率和響應速度很慢

我們已經注意到一些奇怪的CPU使用率行爲 - 100％和200％之間的CPU使用情況發生波動，無論負載（他們是四個核心機）的。週末非常輕巧，絕對沒有負載，星期一的負載相對較重，但我們看到CPU使用率絕對沒有變化。

正如你可以在下面2周圖看，我們的數據庫CPU使用率一度被綁定到應用程序的使用。您可以看到第3臺的大幅增長，第4臺新機的推出，以及從6日開始的穩定的高CPU使用率。

我們已經花了很多時間試圖找出CPU使用率是一個好的量，並能識別（和隨後排除）主要有三個原因：

High khugepaged CPU usage.
調整不當的垃圾收集
調整不準確

我們排除了所有這三件事。

我們的服務器有0.0％的khugepaged CPU使用率。
我們的GC通量約爲96％。我們還調整了堆和新的堆大小以及切換到G1 GC。我們的日誌曾經顯示與長時間的GC暫停相關的警告，但不再執行。此外，GC線程僅佔用少量的CPU使用量。
nodetool compactionstats返回0，尚未完成的任務。我們已經切換到LeveledCompactionStrategy並將GC_GRACE_SECONDS設置爲1天。我們的日誌曾經顯示與大量墓碑相關的警告，但不再提供。 nodetool compactionhistory顯示每小時約一次壓實，並且根據它們發生的日誌非常快（< 1秒）。

看來卡桑德拉的SharedPoolWorker線程有很高的使用率。這是一個被類型的線程的一個節點的CPU使用率（看起來都非常相似）：

84.6 SharedPoolWorker 
22.1 Thrift 
13.5 CCompilerThread 
11.9 MessagingServiceOutgoing 
9.4 MessagingServiceIncoming 
3.6 GangworkerParallelGCThreads 
1.6 DestroyJavaVM 
.3 VMThread 
.1 Thread 
.1 ScheduledTasks 
.1 OptionalTasks 
0 ...

檢查出SharedPool一工作者線程的狀態表明，絕大多數都是與以下堆棧跟蹤等待：

java.lang.Thread.State: WAITING (parking) 
    at sun.misc.Unsafe.park(Native Method) 
    at java.util.concurrent.locks.LockSupport.park(Unknown Source) 
    at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:85) 
    at java.lang.Thread.run(Unknown Source)

我認爲這是問題，但我不確定爲什麼這可能是因爲CPU等待時間很少（等於dstat一直爲0％）。

現在，有趣的是，任何給定的節點上運行nodetool tpstats示出了在活性少數ReadStage線程，偶爾一個或兩個中未決。沒有任何阻止，所有時間被阻止，或者被丟棄。

下面是輸出到nodetool cfstats和這裏的nodetool netstats：

Mode: NORMAL 
Not sending any streams. 
Read Repair Statistics: 
Attempted: 12229 
Mismatch (Blocking): 2 
Mismatch (Background): 0 
Pool Name     Active Pending  Completed Dropped 
Commands      n/a   0   707576   0 
Responses      n/a   0   859216  n/a

有誰有關於爲什麼這可能發生的任何想法？我們可以研究哪些潛在的事物？

來源

2017-05-08 cscan

的問題實際上是我們的API。它有GC問題導致大量的db讀/寫線程被凍結。

來源

2017-05-11 23:10:02 cscan

它可以與高數量的墓碑或高數量的掃描單讀sstables的 - 即，由於高量產生恆定高CPU負載和較慢的響應的讀取它需要爲每一個請求做。

這些症狀可以顯示，例如，使用STCS持續和頻繁地更新（更新行，而不是添加新數據）數據。

您可以添加主表的nodetool tablestats/cfstats的問題？

來源

2017-05-09 10:20:39 nevsv

我已經更新了問題，包括'nodetool cfstats'和'nodetool netstats'。它看起來像'nodetool tablestats'與卡桑德拉3.沿第一個版本，我們也切換到LeveledCompactionStrategy正是由於這個原因。 – cscan

去LCS應該是一個不錯的選擇。如果數據更新頻繁，請考慮將gc_grace設置爲較低的值。關於cfststs - 表邊存儲看起來有問題，每個切片讀取大量的邏輯單元。 – nevsv

卡桑德拉2.1集羣顯示持續的高CPU佔用率和響應速度很慢

回答

相關問題