2012-08-09 14 views
6

私はCassandraの読み取りパフォーマンスを改善するための助けが必要です。列ファミリのサイズが大きくなるにつれて、読取りパフォーマンスの低下が懸念されます。単一ノードのカサンドラについて、次の統計があります。Cassandra Amazon EC2、パフォーマンス実験を読む

オペレーティングシステム: - :のapache-カサンドラ-1.1.0
Javaバージョン: "1.6.0_14" のJava(TM)SEランタイムのLinuxのCentOS 5.4(最終)
カサンドラバージョンをリリース環境(1.6.0_14-B08を構築) は、Java HotSpot(TM)64ビットサーバーVM(14.0-B16、混合モードを構築する)

カサンドラ構成:(cassandra.yaml)

  • rpc_server_type:HSHA
  • disk_access_mode:MMAP
  • concurrent_reads:64
  • concurrent_writes:32

プラットフォーム:4エフェメラルディスクをアマゾン-EC2/RightScaleのm1.Xlargeインスタンスraid0で(15ギガバイト合計メモリ、4仮想コア、2 ECU、合計ECU = 8)


実験構成: 私はGC

カサンドラの設定でいくつかの実験を行うことを試みている:
10 GB RAMはCassandra Heapに割り当てられ、3500MBはHeap NEWサイズです。

JVM設定:
JVM_OPTS = "$ JVM_OPTS -XX:+ UseParNewGC"
JVM_OPTS = "$ JVM_OPTS -XX:+ UseConcMarkSweepGCを"
JVM_OPTS = "$ JVM_OPTS -XX:+ CMSParallelRemarkEnabled"
JVM_OPTS = "$ JVM_OPTS -XX:SurvivorRatio = 1000"
JVM_OPTS = "$ JVM_OPTS -XX:MaxTenuringThreshold = 0"
JVM_OPTS = "$ JVM_OPTS -XX:CMSInitiatingOccupancyFraction = 40"
JVM_OPTS = "$ JVM_OPTS -XX:+ UseCMSInitiatingOccupancyOnly -XX:+ UseCompressedOops "
OpsCenterのコミュニティ2.0からの
結果の統計:

読むには208秒
OSのロード24.5あたり28から18に要求し二
書き込みあたり240から25に要求します。85
書き込み要求レイテンシ127〜160ミクロス
読み出し要求レイテンシ82202 94612へのミクロス
ネットワークトラフィック二
OS受け取ったネットワークトラフィックの4338キロバイト平均毎秒
OSディスクキューのサイズ13〜15あたり44646キロバイトの平均送信 OS保留
読み取り要求を要求25 32から

OSディスクレイテンシ48〜56ミリ秒
OSディスク読み取りスループット第
ディスクのIOPあたり4.6 Mbが第あたり420を読み込み

IOWAIT 80%CPUの平均

アイドル13%のCPUの平均

ROWCACHEは無効です。


列の家族、私は唯一のCLIを使用して作成されてから読んでい列ファミリーの
一つ

create column family XColFam 
with column_type='Standard' 
and comparator = CompositeType(BytesType,IntegerType)';" 

列ファミリーSSTableサイズ= 7.10ギガバイト、SSTableカウント= 2

XColFamカラムファミリーは59499904番です。 (ほとんどが長さが変化するutf8リテラルで、mx4jtoolsで推定されます)、薄い性質のカラムがあり、値は0バイトです。

ほとんどの行は、列名の第1コンポーネントのおよそ20〜30バイトで、第2は8バイトの整数の非常に小さい列数を持つ必要があります。....複合列の第2コンポーネント動的である可能性がありますが、確率は低いです.........第1成分は品種で繰り返されますが、行の列の数は異なる場合があります。

私はカラムファミリーを圧縮するためにSnappyCompressionを試しましたが、サイズの変更はありませんでした。

私は20のスレッドで時間のために実行スケジュールされたサービスを持っていないし、複数のキーのためのランダム読み取り要求を行う(リクエストあたりの今のその2つの鍵)は、このコラムの家族に、完全な行を読んで、何列スライスまたはなど

1分あたりのリクエスト数が少なすぎるため、今はうまくいきません。以前は列ファミリのサイズがそれほど大きくないときには以前よりうまくいきました。それは約3から4 GBでした。

カラムファミリのサイズの増加に伴い、読取りパフォーマンスが低下することが懸念されます。

GCとメモリの使用量が多かったため、GCとメモリの一部を調整しようとしました。データのサイズが小さく、波の形が非常に小さいとき。


どのようにしてCassandraのパフォーマンスを向上させることができますか?あなたの提案は高く評価されます。

+0

読み取り要求待ち時間82202〜94612マイクロ秒...待ち時間82秒? – Crowie

答えて

0

look cassandraは相対I/Oに依存します.ECインスタンスには設計上の「不十分」なI/Oがあります(Xen仮想化) そして私の最初の勧告は、実際のハードウェアでCassandraを使用することです。たとえば、CommitLogにSSDディスクを使用できます。 Cassandra hardware proposalsを見てください。

ただし、独自のハードウェアに切り替えることは少し根本的な選択肢です。

アマゾン弾性ブロックストア(EBS)EBSは、Amazon EC2インスタンスで使用するために、ブロックレベルのストレージボリューム を提供しようとアマゾンで滞在します。 Amazon EBSボリュームは ネットワークに接続されており、 インスタンスの存続期間とは関係なく保持されます。 Amazon EBSは、実行中のAmazon EC2インスタンスに接続し、インスタンス内のデバイスとして公開できる高可用性で信頼性の高い 予測可能なストレージボリュームを提供します。 Amazon EBS は、データベース、ファイル システム、またはローブロックレベルのストレージへのアクセスを必要とするアプリケーションに特に適しています。

Amazon EBSでは、Amazon EC2インスタンスによってデバイスとしてマウントできる1 GBから1 TBのストレージボリュームを作成できます。複数のボリュームを同じインスタンスにマウントできます。 Amazon EBSでは、必要に応じてプロビジョニングされたIOPSボリュームを選択することにより、特定のレベルのI/Oパフォーマンスをプロビジョニングできます。これにより、Amazon EC2インスタンスごとに数千のIOPSまで予測可能に拡張できます。行キャッシュとキーキャッシュ:

Cassandra Performance Testing on EC2

+0

Ephermal ec2インスタンスは本質的にEBSより高速であり、RAID10を使用しないと、EBSバブル(ハングまたはタイムアウト)の影響を受けやすくなります。 SSDインスタンスのfiインスタンスは指数関数的に速いと言われています – David

+0

@David in ec2でも「自然」は仮想化されています;)しかし、あなたは正しいです。彼らは速く、彼らはより良いtoughputを持っています。しかし、EBS RAIDはランダムにシークすることでパフォーマンスが向上します [これと比較](http://victortrac.com/blog/2010/01/02/ec2-ephemeral-disks-vs-ebs-volumes-in-raid/)。 これは、過度のカサンドラのパフォーマンスにとってより価値があるかもしれません。 – aholbreich

0

短い答えをチェックしてください。

ほとんどのシステムのように頻繁に読み取られるサブセットがデータに含まれている場合は、行キャッシュとキーキャッシュを使用してください。

ロー・キャッシュはインメモリー・キャッシュで、頻繁に読み取られるローをメモリー内に完全に保管します。あなたがデータが広がっている場合、これは望ましい効果がないかもしれないことに留意してください。

キーキャッシュは、一般に、パーティションキーとそのオフセットのみをディスクに格納するので、より適しています。これは、一般的にカサンドラによる検索をスキップするのに役立ちます(パーティションインデックスとパーティションサマリーを使用する必要はありません)。

キースペースとテーブルでキーキャッシュを有効にして、パフォーマンスをチェックしてみてください。