質問

なぜハードコーディングされたチャンク制限 (圧縮後 0.5 メガ) があるのですか memcached?誰かが再コンパイルしてそれを改善した人はいますか?このような大きな塊を送信すべきではないことはわかっていますが、これらの非常に重い塊が時々発生して大混乱を引き起こします。

役に立ちましたか?

解決

この質問は以前、 公式FAQ

memcached で到達する可能性のある制限にはどのようなものがありますか?(ウェイバックマシン)

引用するには:

おそらくMemcacheで表示される単純な制限は、キーとアイテムのサイズの制限です。キーは 250 文字に制限されています。保存されたデータは、最大の典型的なスラブサイズであるため、1メガバイトを超えることはできません。」

FAQ は改訂され、これをカバーする 2 つの個別の質問が追加されました。

キーの最大長はどれくらいですか?(250バイト)

キーの最大サイズは 250 文字です。メモは、プレフィックスが元のキーの前面にタックされているため、クライアントの「プレフィックス」または同様の機能を使用している場合、この値は少なくなります。より短いキーは、メモリを保存し、より少ない帯域幅を使用するため、一般的に優れています。

アイテムのサイズが 1 MB に制限されているのはなぜですか?

ああ、これはよくある質問ですね!

短い答え:メモリ アロケータのアルゴリズムの仕組みが原因です。

長い答え:Memcachedのメモリストレージエンジン(将来的にプラグ可能/調整されます...)は、メモリ管理にスラブアプローチを使用します。メモリは、さまざまなサイズのスラブチャンクに分割され、最小数から始まり、可能な限り最大の値までの要因によって上昇します。

最小値は400バイトで、最大値は1メガバイトであり、要因は1.20であるとします。

スラブ 1 - 400 バイト スラブ 2 - 480 バイト スラブ 3 - 576 バイト ...等

スラブが大きいほど、それと前のスラブの間にはギャップが大きくなります。したがって、最大値が大きいほど、メモリストレージの効率が低くなります。Memcachedは、存在するすべてのスラブに対していくつかのメモリを事前に割り当てる必要があるため、最大値を大きくすることでより小さな要因を設定するには、さらに多くのオーバーヘッドが必要です。

それをしたくない理由は他にもあります...Webページについて話している場合、その大きさの値を保存/ロードしようとしている場合は、おそらく何か間違ったことをしているでしょう。そのサイズでは、データ構造をメモリにロードして開梱するのに顕著な時間がかかり、サイトはあまりうまく機能しないでしょう。

1MBを超えるアイテムを本当に保存したい場合は、編集されたものでMemcachedを再コンパイルすることができます slabs.c:POWER_BLOCK 値、または非効率的なmalloc/freeバックエンドを使用します。その他の提案には、データベース、mogilefsなどが含まれます。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top