10

コードベース全体を使用ThriftからCQL使用datastax java driver 1.0.1に変更しましたcassandra 1.2.6..

倹約では、最初から頻繁にタイムアウトが発生し、先に進むことができませんでした... CQLを採用し、それに従って設計されたテーブルが成功し、タイムアウトが少なくなりました....

それで、倹約では機能しなかった巨大なデータを挿入することができました...しかし、ステージの後、約3.5GBのデータフォルダー。書き込みタイムアウト例外が頻繁に発生します。以前と同じユースケースを繰り返しても、タイムアウト例外がスローされます。一度機能したそのランダムは、新しいセットアップの後でも再び機能しません。

CASSADNRA サーバー ログ

これはcassandraサーバーの部分ログDEBUGモードで、エラーが発生しました：

http://pastebin.com/rW0B4MD0

クライアントの例外:

Caused by: com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra timeout during write query at consistency ONE (1 replica were required but only 0 acknowledged the write)
    at com.datastax.driver.core.exceptions.WriteTimeoutException.copy(WriteTimeoutException.java:54)
    at com.datastax.driver.core.ResultSetFuture.extractCauseFromExecutionException(ResultSetFuture.java:214)
    at com.datastax.driver.core.ResultSetFuture.getUninterruptibly(ResultSetFuture.java:169)
    at com.datastax.driver.core.Session.execute(Session.java:107)
    at com.datastax.driver.core.Session.execute(Session.java:76)

インフラストラクチャ: cassandra、i7 プロセッサに与えられた 8GB ヒープを備えた 16GB マシン..タイムアウト用に調整されたこの yaml で SINGLE ノード cassandra を使用しています。他のすべてはデフォルトです:

  • read_request_timeout_in_ms: 30000
  • range_request_timeout_in_ms: 30000
  • write_request_timeout_in_ms: 30000
  • truncate_request_timeout_in_ms: 60000
  • request_timeout_in_ms: 30000

USE CASE : 組み合わせ (私のプロジェクト用語) を cassandra に保存するユースケースを実行しています....現在、100 の並列スレッドで 250 000 の組み合わせを保存することをテストしています..各スレッドは 1 つの組み合わせを保存しています...実際のケースでは数十をサポートする必要があります数百万ですが、それには別のハードウェアとマルチノード クラスタが必要です...

1 つのコンビネーションの保存には約 2 秒かかり、以下が含まれます。

  • 527 INSERT INTO クエリ
  • 506 個の UPDATE クエリ
  • 954 の SELECT クエリ

100個の並列スレッドが100個の組み合わせを並列に格納します。

WRITE TIMEOUTS のランダムな動作が 200,000 まで動作し、その後タイムアウトをスローし、時には 10k の組み合わせでも動作しないことがわかりました。ランダムな動作。

4

4 に答える 4

1

同様の問題があったため、dev cassandra nodes config yamlを読むのに少し時間を費やしました。約 30 億個の sha2 ハッシュを 600MB の RAM しかない開発ノードにロードしようとすると、システムが停止してタイムアウトになります ;)

キャッシュサイズを減らしてフラッシュする前に待機するなどして修正しました。これにより、ノードの書き込みが遅くなりましたが、安定していました。その後、必要なだけ多くのデータをロードできました。

しかし、申し訳ありませんが、どのオプションがあったかわかりませんでした。パフォーマンス チューニングと、CPU コア、RAM などに基づいてシステムの正しい値を計算する方法についてのドキュメントを読んだことを覚えています。

私が抱えていた問題は、キャッシュがディスクに十分に速く書き込まれなかったため、すべてがブロックされ始めたことです。より頻繁に書き込み、新しいリクエストを待機させると言った後、ノードは安定し、インポートは少し遅くなりました。

cassandra のデフォルト オプションは、負荷を分散できるマルチノード クラスタ内の多数のコアを備えた重い RAM マシン用であると思われます。ローカル開発環境で実行するには、ねじ込みます。その開発環境であり、ライフシステムではありません。コーヒーを1杯か2杯飲むのに時間がかかります;）

正しい方法で考えるのに役立つことを願っています

于 2013-08-07T11:31:36.657 に答える
0

私はこの問題にも遭遇しました。cassandra.yaml のパラメータを変更することで対処しました。cassandra.yaml で「timeout」を検索すると、read_request_timeout_in_ms: 5000 write_request_timeout_in_ms: 2000 という数字が表示されます。数値を増やして「cassandra -f」を再起動すると、問題は解決しました。それもあなたを助けることを願っています！

于 2016-03-08T09:14:13.240 に答える