之所以能夠重新創建一個簡單的場景，看近底部連續應激後不平衡卡桑德拉集羣負載寫道
首先，一些底色成問題的更新。我正在Amazon EC2上做一些Cassandra實驗。我在東方有4個節點，在西方有4個節點。爲了模擬我的使用案例，我使用運行在單獨的East-EC2實例上的cassandras內部壓力工具發佈：
./stress -d us-eastnode1，...，us-eastnode4 --replication-strategy NetworkTopologyStrategy - -strategy-properties us-east：3，us-west：3 -e LOCAL_QUORUM -c 200 -i 10 -n 1000000
接下來我運行了同樣的寫法，同時也開始了對應的local_quorum讀取另一個單獨的West -EC2例如：
./stress -d美國westnode1，...，美國westnode4 -o讀-e LOCAL_QUORUM -c 200 -i 10-百萬
杉後st 300k左右讀取，其中一個西方節點開始以約80％iowait cpu阻塞，並將總讀取速度降低約90％。與此同時，寫作完成的速度接近正常速度。爲了弄清楚是什麼導致這個單一節點變成了Iowait塊，我剛剛開始閱讀，並立即出現了同樣的問題。
我的代幣是這樣的，它在東方節點周圍是平衡的，每個西方節點+1在每個對應的東方節點上，即。 us-eastnode1：0，us-westnode1：1，us-eastnode2：42535295865117307932921825928971026432等。實際負載在整個集合中達到平衡，所以我從中找到了可能的原因。
我最終進行了一次重大壓縮（儘管CF只有10個sstables，並且沒有小時的壓縮已經被啓動了>小時）。一旦我再次嘗試讀取壓力，節點就很好......然而，下一個連續節點則會遇到同樣的問題。這是我發現的最大線索，但我不知道它在哪裏。
我已經問過卡桑德拉IRC，但從那裏沒有任何想法。任何人對我可以嘗試的新事物有任何想法，試圖找出這裏出了什麼問題？
第二天更新 一些進一步的鑽研，我能夠通過簡單地運行寫應激兩次，然後運行該讀重現此。 nodetool cfstats在第一次寫入後顯示每個節點負責約750k個密鑰，這對於DC中4個節點的1,000,000個密鑰和RF：3是有意義的。但是，在第二次寫入壓力之後，us-westnode1擁有約1,500,000個密鑰，而us-westnode1-3每個擁有約875,000個密鑰。然後當它嘗試讀取時，具有它應該具有的兩倍負載的節點正在陷入停滯。 這讓我覺得麻煩在於壓力工具。它將覆蓋具有相同c0-c199列的相同0000000-0999999行。然而，不管怎樣，沒有一個節點的數據負載與第一次運行時的數據負載大致相同。
簡單娛樂 通過刪除第二個DC作爲變量縮小了問題的範圍。現在運行1個DC，每個擁有25％所有權的4個節點RandomPartitioner，並寫入以下內容：
./stress -d node1，...，node4 --replication-factor 3 -e QUORUM -c 200 -i 10 -n 1000000
經過一次寫入（和次要壓縮）之後，每個節點都有〜7.5gb的負載。
經過兩次寫入（和次要壓縮）後，每個節點都有〜8個。6GB的負載，除了節點2〜15GB。 在所有節點上運行主要壓縮後，每個節點回到〜7.5gb的負載。
這是否只是一個奇怪的壓縮問題，當有效覆蓋整個數據集時就會出現壓力問題？
您正在EC2上運行？你使用實例存儲還是EBS？ – fennec 2012-02-14 17:48:32
實例存儲。今天進一步調查並正在更新問題。似乎與第二次運行壓力寫入時不正確的負載平衡有關。 – user1207932 2012-02-14 19:57:45