2

我们有一个测试代码模式，它使用 java 客户端执行 Cassandra INSERT/READ/QUERY 操作。我们已经使用具有以下配置的物理服务器构建了单节点设置。

  • 操作系统是 Linux SuSE 11.SP2
  • 物理服务器上的内存是 32GB
  • 交换内存为 32GB
  • CPU有4核，每个2GHz
  • 提交日志驻留在 100GB 的 SSD 磁盘上（RAID-0 和系统本地）
  • 数据日志驻留在 7TB 的 SAS 磁盘上（5 个 SAS 磁盘配置为 RAID-0 和系统本地）。
  • JRE 版本 1.7.0.25
  • Cassandra 版本 1.2.5（默认分区）
  • 最大堆大小 8GB
  • HEAP_NEW_SIZE 400MB（根据 Cassandra 的建议，每个内核 100MB）。

注意 将 CPU 从 4 核增加到 8 核有助于提高性能，但效果非常有限。

我们正在使用下面的测试模式，它有 5 个二级索引。

"CREATE TABLE test_table (
  hash_key text PRIMARY KEY,
  ctime timestamp,
  ctime_bucket bigint,
  extension text,
  filename text,
  filename_frag text,
  filesize bigint,
  filesize_bucket bigint,
  hostname text,
  mtime timestamp,
  mtime_bucket bigint
) WITH
  bloom_filter_fp_chance=0.010000 AND
  caching='KEYS_ONLY' AND
  comment='' AND
  dclocal_read_repair_chance=0.000000 AND
  gc_grace_seconds=864000 AND
  read_repair_chance=0.100000 AND
  replicate_on_write='true' AND
  populate_io_cache_on_flush='false' AND
  compaction={'class': 'SizeTieredCompactionStrategy'} AND
  compression={'sstable_compression': 'SnappyCompressor'};

CREATE INDEX test_table_ctime_bucket_idx ON test_table (ctime_bucket);
CREATE INDEX test_table_extension_idx ON test_table (extension);
CREATE INDEX test_table_filename_frag_idx ON test_table (filename_frag);
CREATE INDEX test_table_filesize_bucket_idx ON test_table (filesize_bucket);
CREATE INDEX test_table_mtime_bucket_idx ON test_table (mtime_bucket);"

我们正在尝试使用默认调整参数进行 INSERT 和 READ 测试，但是我们发现读写性能非常缓慢。与写入性能相比，读取速度非常慢。当我们从上述模式中删除二级索引时，我们获得了大约 2 倍的性能提升，但是我们仍然认为通过调整 Cassandra 参数可以提高性能。但是，使用二级索引的性能非常糟糕。

  • 1M INSERT 提供大约 7k Ops/sec
  • 10M INSERT 提供大约 5K Ops/sec（略微降低性能）
  • 100M INSERT 提供大约 5K Ops/sec
  • 1000MM INSERT 提供大约 4.5K Ops/sec

如果我们删除二级索引，对于上面列出的所有工作负载，我们可以获得大约 11K Ops/sec 的性能。

  • 1M READ 提供大约：4.5k Ops/sec
  • 10M READ 仅提供大约：225 ops/sec（大幅降低性能）

我们想从您的专家团队了解哪些特定的调整参数应用于 WRITE 和 READ 操作以获得更好的性能。我们如何推迟压缩和 GC 以避免在这些操作中发挥一定作用的性能瓶颈。如果有任何系统特定的调整要应用，我们想从您的专家团队中知道。

我们正在尝试使用以下调优参数（在 Cassandra.yaml 和 Cassandra-env.sh 中），但是我们在写入和读取性能方面并没有得到太大改善。

4

1 回答 1

4

这是一个非常经典的 i/o 绑定案例，尤其是在使用较大数据集时性能下降的情况。 iostat可以证实这一点。

您需要切换到 SSD，将机器添加到集群中，或者减少工作负载的随机性（提高缓存效率）。

编辑：我注意到您在 SSD 上有提交日志。提交日志是纯粹的顺序写入，因此不会从 SSD 上获得太多好处。将提交日志放在您的一个 HDD 上，并将数据文件放在 SSD 上。

于 2013-08-27T19:03:18.297 回答