卡桑德拉读/写性能 - 高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

回答

相关问题