2011-08-14 9 views
0

私は、membaseが私の環境で非常に遅いという問題があります。 私は、レール2.3.10 ruby​​ 1.8.7でいくつかの実動サーバー(Passenger)を実行しています。 これらのサーバーは、クラスタ内の2つのmembasマシンと通信します。membaseサーバーの応答時間が遅いのはなぜですか?

それぞれのmembaseマシンは、64Gのメモリと100G EBSの1Gスワップを備えています。

私の問題は、membaseは応答時間が非常に遅く、実際にはすべてのアプリケーションライフサイクルにおいて現在最も遅い部分です。

私の質問は:なぜですか?

私が使用しているレールの宝石類はmemcache-northscaleです。 membaseサーバーは1.7.1(最新)です。

サーバは(クラスタの)毎秒2K-7KのOPS

間で行っている(NewRelicに基づく)MemBase値からの応答時間が巨大で不合理である平均で250ミリ秒です。

誰もがなぜこれが起こっているのか分かりませんか? この時間を改善するために何ができますか?

答えて

2

手元のデータですぐに言うのは難しいですが、問題がどこにあるかを絞り込むために掘り下げたいことがいくつかあります。

まず、membaseを使用して統計情報にバックグラウンドフェッチのかなりの数を表示しますか?これは、Web UIの「ディスク読み取り/秒」統計にあります。もしそうなら、それはより高いレイテンシの原因である可能性が高いです。

manualの統計とサイジングの詳細、特に統計とクラスタ設計に関するセクションを参照できます。

第2に、あなたは平均250msを報告しています。これはスライド平均か全体か?あなたは、最大90番目または最大99番目の待ち時間のようなものを持っていますか?ほとんどの要求(たとえば、ディスクフェッチを必要としないRAMからの要求)が実際には非常に高速である場合、外向きディスクフェッチによっては大きな平均を得ることができます。

システムは可用性ゾーン全体に広がっていますか?どのようなインスタンスを使用していますか?クライアントとサーバーは同じAmazon AWS地域にありますか?私は答えが "はい"になる可能性があると考えています。これは、最近測定したxlargeのインスタンスを使用すると約1.5msのオーバーヘッドを意味します。これは、一定の方法で連続して多数のフェッチを同期して実行している場合には問題になります。

私はすべてが1つの地域にあると思っていますが、待ち時間がWAN待ち時間のように聞こえるので、2回チェックする価値があります。

最後に、Faunaと下位互換性のある最新のRuby gemがあります。 Couchbase、Inc.は、Fauna上流に追加する作業を続けています。可能な場合は、ここで参照宝石を試してみたいことがあります:あなたはまた、クライアント側でMoxiを実行しているを見てみたいと思うでしょう http://www.couchbase.org/code/couchbase/ruby/2.0.0

+0

問題は可用性ゾーンでした。すべてのサービスを同じゾーンに移動すると、それは魅力のように機能します。今、membaseは36msAVで非常に良いです。 – KensoDev

0

。 Membaseにアクセスするには、プロキシ(Moxiと呼ばれる)を経由する必要があります。デフォルトではサーバーにインストールされています。つまり、実際にキーを持っていないサーバーの1つに要求を出す可能性があります。 Moxiはそれを得るつもりです...しかし、あなたはネットワークトラフィックを倍増しています。クライアント側でMoxiのインストール

は、この余分なネットワークトラフィックを排除します:http://www.couchbase.org/wiki/display/membase/Moxi

ペリー