卡桑德拉讀/寫性能 - 高CPU

我已經開始使用Casandra自最近幾天以來，這就是我想要做的。卡桑德拉讀/寫性能 - 高CPU

我有大約2百萬個維護用戶配置文件的對象。我將這些對象轉換爲json，將它們壓縮並存儲在blob列中。平均壓縮的json大小約爲10KB。這是我的表看起來如何在卡桑德拉，

表：

dev.userprofile (uid varchar primary key, profile blob);

選擇查詢：從dev.userprofile其中uid = '' 選擇配置;

更新查詢：

update dev.userprofile set profile='<bytebuffer>' where uid = '<uid>'

每隔一小時，我從我申請我USERPROFILE對象隊列中的事件。每個事件對應一個userprofile對象。我得到大約100萬個這樣的事件，所以我必須在短時間內更新1M左右的用戶配置對象，即更新應用程序中的對象，壓縮json並更新cassandra blob。我必須在幾分鐘內完成更新所有100萬個用戶配置文件對象。但我注意到它現在需要更長的時間。

在運行我的應用程序時，我注意到我平均可以更新大約400個配置文件/秒。我已經看到很多CPU iowait - cassandra實例上的70％以上。此外，負載最初在16（相當於8個vcpu實例）時相當高，然後下降到4左右。

我在做什麼錯？因爲當我更新2KB大小的小對象時，我注意到cassandra操作/ sec要快得多。我能夠獲得約3000 OPS /秒。關於如何改善表現的任何想法？

<dependency> 
    <groupId>com.datastax.cassandra</groupId> 
    <artifactId>cassandra-driver-core</artifactId> 
    <version>3.1.0</version> 
</dependency> 
<dependency> 
    <groupId>com.datastax.cassandra</groupId> 
    <artifactId>cassandra-driver-extras</artifactId> 
    <version>3.1.0</version> 
</dependency>

我只是卡桑德拉設置的一個節點m4.2xlarge AWS實例中進行測試

Single node Cassandra instance 
m4.2xlarge aws ec2 
500 GB General Purpose (SSD) 
IOPS - 1500/10000

nodetool cfstats輸出

nodetool cfhistograms輸出

Percentile SSTables  Write Latency  Read Latency Partition Size  Cell Count 
           (micros)   (micros)   (bytes) 
50%    3.00    9.89   2816.16    4768     2 
75%    3.00    11.86   43388.63    8239     2 
95%    4.00    14.24   129557.75    14237     2 
98%    4.00    20.50   155469.30    17084     2 
99%    4.00    29.52   186563.16    20501     2 
Min    0.00    1.92    61.22    216     2 
Max    5.00   74975.55  4139110.98   379022     2

Dstat輸出

---load-avg--- --io/total- ---procs--- ------memory-usage----- ---paging-- -dsk/total- ---system-- ----total-cpu-usage---- -net/total- 
1m 5m 15m | read writ|run blk new| used buff cach free| in out | read writ| int csw |usr sys idl wai hiq siq| recv send 
12.8 13.9 10.6|1460 31.1 |1.0 14 0.2|9.98G 892k 21.2G 234M| 0  0 | 119M 3291k| 63k 68k| 1 1 26 72 0 0|3366k 3338k 
13.2 14.0 10.7|1458 28.4 |1.1 13 1.5|9.97G 884k 21.2G 226M| 0  0 | 119M 3278k| 61k 68k| 2 1 28 69 0 0|3396k 3349k 
12.7 13.8 10.7|1477 27.6 |0.9 11 1.1|9.97G 884k 21.2G 237M| 0  0 | 119M 3321k| 69k 72k| 2 1 31 65 0 0|3653k 3605k 
12.0 13.7 10.7|1474 27.4 |1.1 8.7 0.3|9.96G 888k 21.2G 236M| 0  0 | 119M 3287k| 71k 75k| 2 1 36 61 0 0|3807k 3768k 
11.8 13.6 10.7|1492 53.7 |1.6 12 1.2|9.95G 884k 21.2G 228M| 0  0 | 119M 6574k| 73k 75k| 2 2 32 65 0 0|3888k 3829k

編輯

切換到上sstables LeveledCompactionStrategy &禁用壓縮，我沒有看到一個很大的改進：

有在型材有點起色/秒更新。它現在的550-600配置文件/秒。但是，CPU峯值仍然是愛荷華州。

gcstats

Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed (ms) GC Reclaimed (MB)   Collections  Direct Memory Bytes 
      755960     83    3449     8   73179796264     107      -1

dstats

---load-avg--- --io/total- ---procs--- ------memory-usage----- ---paging-- -dsk/total- ---system-- ----total-cpu-usage---- -net/total- 
1m 5m 15m | read writ|run blk new| used buff cach free| in out | read writ| int csw |usr sys idl wai hiq siq| recv send 
7.02 8.34 7.33| 220 16.6 |0.0 0 1.1|10.0G 756k 21.2G 246M| 0  0 | 13M 1862k| 11k 13k| 1 0 94 5 0 0| 0  0 
6.18 8.12 7.27|2674 29.7 |1.2 1.5 1.9|10.0G 760k 21.2G 210M| 0  0 | 119M 3275k| 69k 70k| 3 2 83 12 0 0|3906k 3894k 
5.89 8.00 7.24|2455 314 |0.6 5.7 0|10.0G 760k 21.2G 225M| 0  0 | 111M 39M| 68k 69k| 3 2 51 44 0 0|3555k 3528k 
5.21 7.78 7.18|2864 27.2 |2.6 3.2 1.4|10.0G 756k 21.2G 266M| 0  0 | 127M 3284k| 80k 76k| 3 2 57 38 0 0|4247k 4224k 
4.80 7.61 7.13|2485 288 |0.1 12 1.4|10.0G 756k 21.2G 235M| 0  0 | 113M 36M| 73k 73k| 2 2 36 59 0 0|3664k 3646k 
5.00 7.55 7.12|2576 30.5 |1.0 4.6 0|10.0G 760k 21.2G 239M| 0  0 | 125M 3297k| 71k 70k| 2 1 53 43 0 0|3884k 3849k 
5.64 7.64 7.15|1873 174 |0.9 13 1.6|10.0G 752k 21.2G 237M| 0  0 | 119M 21M| 62k 66k| 3 1 27 69 0 0|3107k 3081k

你可以注意到CPU峯值。之前我增加負擔進一步

我主要關注的是IOWAIT。任何具體的我應該找這造成這個？因爲600檔/秒（即600讀取+寫入）對我來說似乎很低。

來源

2016-10-30 plspl

更新條目時，必須先讀取它，解壓縮它，更新更改的部分，然後壓縮記錄並再次存儲。該操作高度依賴於條目的大小。如果速度不取決於條目的大小，則會出現問題。 –

在寫入更新之前沒有讀取。 –

添加了select查詢，我在更新之前使用它來讀取數據。 – plspl

你可以試試LeveledCompactionStrategy？在這樣的大型對象上進行1：1讀取/寫入操作時，保存在讀取上的IO可能會對付在較昂貴壓縮上花費的IO。

如果您在發送數據之前已經壓縮了數據，則應該關閉表格中的壓縮。它將其分成64kb的塊，它將主要由只有6個不會得到很多壓縮的值所支配（如可怕的壓縮比SSTable Compression Ratio: 0.9984539538554672所示）。

ALTER TABLE dev.userprofile 
    WITH compaction = { 'class' : 'LeveledCompactionStrategy' } 
    AND compression = { 'sstable_compression' : '' };

400個型材/秒是非常非常緩慢，但並可能有一些工作要做你的客戶端，可能是瓶頸，以及上。如果你在8核心系統上有4個負載，它可能不會使Cassandra放慢速度。確保您的請求並行並異步使用它們，順序發送請求是一個常見問題。

隨着更大的斑點將會對GC產生影響，因此監視它們並添加該信息可能會有所幫助。我會驚訝於10kb的對象會影響它，但它的東西要注意，可能需要更多的JVM調整。

如果有幫助，從那裏我會建議調整堆並升級到至少3.7或最新的3.0行。

來源

2016-10-31 02:57:33

謝謝。我看到一些改進。 1）有沒有辦法檢查壓縮是否真的關閉？將表格顯示爲「sstable_compression」的空白。是嗎？另外，愛荷華還沒有走。我看到Ocassional cpu spikes發佈了新的統計信息： – plspl

發言太快。高cpu尖峯（iowait）和高負載仍然存在。 – plspl

剛剛意識到您使用的EBS。只需使用I2實例和實例存儲以獲得令人敬畏的性能，EBS就會更容易，EBS會需要更多的手持。 Theres與一些成功的人進行了良好的介紹：http：//www.slideshare.net/AmazonWebServices/bdt323-amazon-ebs-cassandra-1-million-writes-per-second 你能發佈更新後的stats/histos切換LCS？仍然主要來自閱讀io。你有沒有經歷過推薦的操作系統設置？ https://docs.datastax.com/en/landing_page/doc/landing_page/recommendedSettingsLinux.html（儘管這不是EBS的一個開始） –

卡桑德拉讀/寫性能 - 高CPU

回答

相關問題