2016-08-03 14 views
1

YCSB Endpoint benchmarkは、CassandraがNosqlデータベースの黄金の子だと考えています。しかし、独自のボックス(ハイパースレッディング、60 GBのメモリ、2 500 GBのSSDを搭載した8つのコア)で結果を再現すると、ワークロードbの読み込みスループットが低下しています(ほとんど95%読取り、5%更新)。YCSB読み取りのスループットが低いcassandra

cassandra.yamlの設定は、異なるIPアドレスとディスク構成(データの場合は1 SSD、コミットログの場合は1)を除き、エンドポイント設定とまったく同じです。スループットは1秒あたり〜38,000回ですが、スレッド/クライアントノードの数(相対的に)に関係なく、約16,000です。私。 256スレッドのワーカーノードでは〜16,000 ops /秒、4ノードではそれぞれ〜4000 ops/secと報告されます。

私はSSDデータドライブのreadahead値を8KBに設定しました。私は以下のカスタムワークロードファイルを配置します。

iostatを使用してディスクio &cpuの使用状況を分析すると、読み取りスループットは一貫して〜200,000 KB/sになると思われます。これは、ycsbクラスタのスループットが高くなる(レコードは100バイトです)。 〜25-30%のCPUが%iowait未満であると思われ、ユーザーが使用しているのは10〜25%です。

topとnloadの統計情報は表面上ボトルネックではありません(<メモリ使用量は50%、10Gb/sリンクでは10-50Mbits/sec)。

# The name of the workload class to use 
workload=com.yahoo.ycsb.workloads.CoreWorkload 

# There is no default setting for recordcount but it is 
# required to be set. 
# The number of records in the table to be inserted in 
# the load phase or the number of records already in the 
# table before the run phase. 
recordcount=2000000000 

# There is no default setting for operationcount but it is 
# required to be set. 
# The number of operations to use during the run phase. 
operationcount=9000000 

# The offset of the first insertion 
insertstart=0 
insertcount=500000000 

core_workload_insertion_retry_limit = 10 
core_workload_insertion_retry_interval = 1 

# The number of fields in a record 
fieldcount=10 

# The size of each field (in bytes) 
fieldlength=10 

# Should read all fields 
readallfields=true 

# Should write all fields on update 
writeallfields=false 

fieldlengthdistribution=constant 

readproportion=0.95 

updateproportion=0.05 

insertproportion=0 

readmodifywriteproportion=0 

scanproportion=0 

maxscanlength=1000 

scanlengthdistribution=uniform 

insertorder=hashed 

requestdistribution=zipfian 
hotspotdatafraction=0.2 

hotspotopnfraction=0.8 
table=usertable 

measurementtype=histogram 

histogram.buckets=1000 
timeseries.granularity=1000 
+0

スループットは、クライアントの数に関してスケーリングが全く行われていません。クライアント1人で、設定されたops/secを取得します。並列に2つのycsbクライアントを実行すると、それぞれがスループット/ 2を取得し、4つのクライアントはスループット/ 4を取得します。ycsbクライアントのコアと最大接続を1024に設定します。nloadは、クライアント(1クライアントから2クライアントに向かうときに2倍のトラフィックを期待する)。トラフィックは〜20Mbitsしかないので、間違いなくボトルネックになります。 – Rdesmond

+0

SSTablesの圧縮はパフォーマンスに影響しませんでした。 – Rdesmond

+0

あなたは何を求めているのか、より具体的になるはずです。 – cabad

答えて

0

鍵はcasssandra.yamlファイルのnative_transport_max_threadsを増やしていました。

コメントの設定の増加(ycsbクライアントでの接続数の増加、およびcassandraでの同時読み込み/書き込み)に加えて、Cassandraは〜80,000 ops/secに飛躍しました。

関連する問題