私の環境では membase が非常に遅いという問題があります。Rails 2.3.10 ruby 1.8.7で複数の本番サーバー(Passenger)を実行しています。これらのサーバーは、クラスター内の 2 つの membase マシンと通信します。
各 membase マシンには 64G のメモリと 100g EBS が接続されており、1G スワップです。
私の問題は、membase の応答時間が非常に遅く、実際には現在、アプリケーションのライフサイクル全体で最も遅い部分です。
私の質問は：なぜですか？
私が使用している Rails gem は memcache-northscale です。メンバーベース サーバーは 1.7.1 (最新) です。
サーバーは 1 秒あたり 2K ～ 7K の操作を行っています (クラスターの場合)。
membase からの応答時間 (NewRelic に基づく) は平均 250 ミリ秒で、これは非常に大きく、不合理です。
なぜこれが起こっているのか誰か知っていますか？今回改善するにはどうしたらよいでしょうか？
手元にあるデータですぐに言うのは難しいですが、問題がどこにあるのかを絞り込むために掘り下げたいことがいくつかあると思います.
まず第一に、membase の統計は、かなりの数のバックグラウンド フェッチを示していますか? これは、「1 秒あたりのディスク読み取り」の Web UI 統計にあります。もしそうなら、それがより高いレイテンシーの原因である可能性があります.
統計とサイジングの詳細については、マニュアル、特に統計とクラスター設計の考慮事項に関するセクションを参照してください。
次に、平均 250 ミリ秒を報告しています。これはスライド平均ですか、それとも全体ですか? 最大 90 番目または最大 99 番目のレイテンシのようなものはありますか? ほとんどの要求 (たとえば、ディスク フェッチを必要としない RAM からの要求) が実際には非常に高速である場合に、いくつかの範囲外のディスク フェッチによって大きな平均値が得られることがあります。
システムは可用性ゾーン全体に分散していますか? どのようなインスタンスを使用していますか? クライアントとサーバーは同じ Amazon AWS リージョンにありますか? 最初の答えは「はい」かもしれないと思います。これは、最近の測定から、xlarge インスタンスを使用すると約 1.5 ミリ秒のオーバーヘッドが発生することを意味します。これは、特定のメソッドで多くのフェッチを同期およびシリアルで実行している場合に問題になる可能性があります。
すべてが 1 つのリージョンにあると思いますが、これらの遅延は WAN の遅延のように聞こえるため、再確認する価値があります。
最後に、更新された Ruby gem があり、Fauna と後方互換性があります。Couchbase, Inc. は、Fauna アップストリームへの追加に取り組んでいます。可能であれば、ここで参照されている gem を試してみてください: http://www.couchbase.org/code/couchbase/ruby/2.0.0
また、クライアント側でのMoxiの実行も検討する必要があります。Membaseにアクセスするには、プロキシ（Moxiと呼ばれる）を経由する必要があります。デフォルトでは、サーバーにインストールされます。つまり、実際にはキーを持っていないサーバーの1つにリクエストを送信する可能性があります。Moxiはそれを取得します...しかし、それからあなたはネットワークトラフィックを倍増させています。
クライアント側にMoxiをインストールすると、この余分なネットワークトラフィックが排除されます：http：//www.couchbase.org/wiki/display/membase/Moxi
ペリー