Cassandra亞馬遜EC2，很多IOWait

我們有關於Amazon EC2/Rightscale m1.large實例的單個節點cassandra上的以下統計信息，其中包含兩個帶有raid0的臨時磁盤。（7.6 GB總內存）Cassandra亞馬遜EC2，很多IOWait

4 GB RAM分配給cassandra堆，800MB是堆新尺寸。

以下統計信息是從OpsCenter中社區2.0

讀請求每秒
寫入285〜340請求每秒
OS加載15.15 257 720 17.15
寫請求延遲293至685百萬分之一
OS發送網絡流量每秒18 MB到30 MB
操作系統接收到的網絡流量每秒22 MB到34 MB
操作系統磁盤隊列大小23到26請求
Rea d請求待定8-20
讀取請求延遲69140至92885百萬分之一
OS磁盤延遲37至42毫秒
OS磁盤吞吐量每秒
磁盤IOPS 12至14 MB讀取600至740每秒
磁盤IOPS寫入每秒

2-7 IOWAIT 60〜70％的CPU平均

空閒24至30％的CPU平均

Rowcache被禁用。

上述統計數據是否滿足所提供的配置......或者我們如何調整它以獲得更少的IOWait ..........因爲我們認爲我們正在經歷很多IOWait。 ....我們如何調整它以獲得最佳效果。

讀取請求是混合的.........有些來自一個超級列族和一個擁有超過百萬個按鍵的標準......並且不變。超級列最多14個不同的號碼。子列從1到10000並且不變。標準列族中最多有14列...............子列本質上非常薄，0字節值.... 8字節用於名稱。

進程正在從超級列族中移除數據並將處理後的數據寫入標準列。

將EBS磁盤更好地工作....在Amazon EC2上

來源

2012-05-09 Asim

我還不能肯定是否可以輕鬆地調整您的配置，以獲得更多的磁盤性能，但使用斯納皮壓縮可以幫助一個很好的協議使你應用程序需要閱讀更少的整體。它可能也有助於使用新的組合鍵佈局，而不是超級柱。

有一件事我可以肯定地說：EBS將不是工作更好。如果你關心延遲，不惜一切代價遠離。

來源

2012-05-09 17:25:49

感謝保羅.......我們正在使用cassandra更像是一個原始數據存儲工作與字節....我們正在使用超列作爲可追加列表/隊列異步修改多個客戶端.... ...和一個隊列中的數據單元（子列）是如此小，像8字節....所以我不認爲壓縮可以在這裏工作....並且組合鍵或列提供上述行爲，因爲他們正在被表示爲預定義的SQL結構......我們沒有。 – Asim

我有一個問題.....我們可以閱讀一個請求中的一個鍵對應多個超級列的所有子列的列表....因爲這將減少請求的數量...........和rowcache會在這裏幫助........因爲我們在我們的過程中曾經讀過一次key + supercolumn組合。 – Asim

@AsimAli是的，組合鍵佈局可以提供類似的行爲，甚至不需要CQL。使用CQL更容易，但如果能更好地適合您預先存在的代碼，則可以使用簡單的節儉創建組合並使用它們。 –

Cassandra亞馬遜EC2，很多IOWait

回答

相關問題