🧑🏿‍🤝‍🧑🏿 👲 ⚛️ Redisの内部：ライン 🧝🏿 🔧 📊

Redisの単純な文字列 `strings`がRAMで56バイトを占める理由を知っているなら、この記事には興味がないと思います。 Redisにはどのような文字列があるのか、そしてこのデータベースを使用する開発者がどのように動作し、動作するのかを理解することが重要である理由を他の人に伝えようとします。この知識は、アプリケーションの実際のメモリ消費量を計算しようとしている場合、または負荷の高い統計またはデータアカウンティングシステムを構築する計画を立てている場合に特に重要です。または、よくあることですが、redisインスタンスが突然大量のメモリを消費し始めた理由を緊急に理解しようとしています。

私が話すのは、Redisでの文字列の保存方法、文字列の保存に使用される内部構造、Redisが内部で使用する最適化の種類です。大きな構造体を効果的に格納する方法と、それらに基づいて構築された文字列または構造体を使用する価値がない状況。ラインはRedisの重要な構造であり、HSET / ZSET / LISTはそれらのベースに基づいて構築され、内部構造を表す小さなオーバーヘッドが追加されます。この記事が必要な理由-redisタグのstackoverflowを1年以上読んで積極的に対応しています。この間、開発者がRAMを操作するRedisの機能と高速化のために支払う必要があるものを理解していないという事実に関連して、常にさまざまな質問が絶え間なく流れています。

実際に使用されるメモリ量の質問に対する答えは、オペレーティングシステム、コンパイラ、プロセスのタイプ、使用されるアロケータ（redisでは、デフォルトではjemalloc）によって異なります。 centos 7を実行している64ビットサーバーでアセンブルされたredis 3.0.5のすべての計算を行います。

ここでは、C / C ++を書いていない人、またはすべてが低レベルでどのように機能するかについてあまり詳しくない人には、ここで少し間奏が必要だと思われます。計算を理解しやすくするために、いくつかの概念を非常に単純化しましょう。 C / C ++プログラムで構造体を宣言し、その中に符号なし整数フィールド（4バイトの符号付き整数なし）がある場合、コンパイラーはそのサイズを実際のRAMで8バイトに慎重に調整します（x64アーキテクチャーの場合）。この記事では、メモリアロケータについて定期的に説明します。これは、メモリを「スマートに」割り当てる種類です。たとえば、jemallocは、割り当てられたフラグメントのアライメントに依存して、メモリの新しいブロックの検索速度を最適化しようとします。 jemallosのメモリ割り当てとアラインメント戦略については十分に説明されていますが、選択したフラグメントのサイズは最も近い次数2に丸められるという単純化を使用する必要があると思います。あなたがもう少しはっきりすることを願っています。これらは、インタープリター言語では、論理的に心配するべきではないことですが、ここではそれらに注意を向けるようお願いします。

Salvatore Sanfilippo（別名antirez）による著者によるラインの概念と実装は、SDS（Simple Dynamic String、 github.com / antirez / sds ）と呼ばれる大根プロジェクトの1つにあります。

+--------+-------------------------------+-----------+ | Header | Binary safe C alike string... | Null term | +--------+-------------------------------+-----------+ | `-> Pointer returned to the user.

これは単純な `c`構造であり、その見出しには、現在割り当てられているメモリの現在のサイズと空き領域、行自体、および大根自体が追加する必須の終了ゼロが格納されます。 sds行では、ヘッダーのコスト、ヘッダーのサイズを変更する戦略、およびメモリを割り当てる際に構造を整列するペナルティに最も関心があります。

2015年7月4日、ラインの最適化で長い話が終わりました。これは大根3.1に分類されるはずです。この最適化により、ラインヘッダーのメモリが大幅に節約されます（合成テストで16％から200％）。大根の最大行長の512MBの制限を削除します。これはすべて、文字列の長さを変更するときにヘッダーの長さが動的に変更されるために可能になります。したがって、ヘッダーは、最大256バイトの文字列では3バイト、65 kb未満の文字列では5バイト、最大512 mbの文字列では9バイト、サイズがuint64_t（64ビットに適合する文字列では17バイト）のみを占有します符号なし整数）。ところで、この変更により、実際のファームは約19.3％のメモリ（〜42 GB）を節約します。ただし、最新のヘッダー3.0.xでは、8バイト+ 1バイトから最後のゼロまですべてがシンプルです。文字列「文字列」に必要なメモリ量を推定してみましょう：16（ヘッダー）+ 7（文字列の長さ）+ 1（末尾のゼロ）= 24バイト（コンパイラーは2つの符号なしintを調整するため、ヘッダーごとに16バイト）。その際、jemallocは32バイトを割り当てます。とりあえずこれを省略しましょう（理由が後で明らかになることを望みます）。

文字列のサイズを変更するとどうなりますか？行のサイズを大きくし、すでに十分なメモリが割り当てられていない場合、大根は定数SDS_MAX_PREALLOC（sds.hで定義され、1,048,576バイト）で新しい長さをチェックします。新しい長さがこの値より小さい場合、メモリは要求された量の2倍に割り当てられます。文字列の長さがすでにSDS_MAX_PREALLOCを超えている場合、この定数の値は新しい要求された長さに追加されます。この機能は、「ビットマップを使用するとメモリが消える」という話で重要になります。ところで、ビットマップにメモリを割り当てる場合、setbitコマンドの実装の特性により、要求された量の2倍が常に割り当てられます（bitops.cのsetbitCommandを参照）。

これで、ラインがRAMで32バイトを占有すると言うことができます（アラインメントを考慮して）。 hashedin.com （ redisメモリ最適化ガイド）から連中のヒントを読んだ人は、100バイト未満の文字列を使用しないことを強くお勧めすることを思い出すかもしれません。「set foo bar」コマンドを使用する場合など、短い文字列を保存するには、〜96バイトを費やします。そのうちの90バイトはオーバーヘッドです（64ビットマシン上）。彼らはcですか？次に考えてみましょう。

大根のすべての値はredisObject型の構造体に保存されます。これにより、大根は値のタイプ、その内部表現（大根ではこれをエンコードと呼びます）、LRUのデータ、値の値を参照するオブジェクトの数、および値自体を知ることができます。

 +------+----------+-----+----------+-------------------------+ | Type | Encoding | LRU | RefCount | Pointer to data (ptr*) | +------+----------+-----+----------+-------------------------+

少し後に、コンパイラのアライメントとjemalloc機能を考慮して、ラインのサイズを計算します。文字列に関しては、文字列を保存するためにどのエンコーディングが使用されているかを知ることが非常に重要です。現在、大根は3つの異なるストレージ戦略を使用しています。

REDIS_ENCODING_INTは非常に単純です。長い値にキャストされた値がLONG_MIN 、 LONG_MAXの範囲にある場合、この形式で文字列を格納できます。したがって、文字列「dict」はこのエンコーディングの形式で正確に保存され、1952672100（0x74636964）という番号になります。 REDIS_SHARED_INTEGERSの範囲（ redis.hで定義され、デフォルトでは10000に等しい）の事前に割り当てられた特別な値の範囲には、同じエンコードが使用されます。この範囲の値は、大根の始まりですぐに強調表示されます。
REDIS_ENCODING_EMBSTRは 、最大39バイトの文字列（ object.cの定数REDIS_ENCODING_EMBSTR_SIZE_LIMITの値）に使用されます。これは、redisObjectとsds行を含む構造体が、アロケータによって割り当てられた単一のメモリ領域に配置されることを意味します。これを念頭に置いて、アライメントを正しく計算できます。ただし、これは大根のメモリフラグメンテーションの問題とその対処方法を理解する上で重要です。
REDIS_ENCODING_RAWは 、長さがREDIS_ENCODING_EMBSTR_SIZE_LIMITを超えるすべての行に使用されます。この場合、ptr *は、sds行のあるメモリ領域への通常のポインターを格納します。

EMBSTRは2012年に登場し、短い行で作業するときにパフォーマンスが60〜70％向上しましたが、メモリへの影響とその断片化に関する深刻な研究はまだありません。

文字列「strings」の長さはわずか7バイトです。その内部表現のタイプはEMBSTRです。この方法で作成された行は、次のようにメモリに配置されます。

 +--------------+--------------+------------+--------+----+ | robj data... | robj->ptr | sds header | string | \0 | +--------------+-----+--------+------------+--------+----+ | ^ +-----------------------+

これで、文字列「strings」を格納するために必要なRAMの量を計算する準備が整いました。

（4 + 4） ^* + 8（エンコード）+ 8（lru）+ 8（refcount）+ 8（ptr）+ 16（sdsヘッダー）+ 7（行自体）+ 1（終端ゼロ）= 56バイト。

redisObjectの型と値は、同じ数字の下位4ビットと上位4ビットのみを使用するため、アライメント後のこれら2つのフィールドは8バイトを使用します。

鼻で運転していないことを確認しましょう。エンコードと値を見てみましょう。行のデバッグにあまり知られていないコマンドを1つ使用します-DEBUG SDSLEN。ちなみに、このコマンドは公式ドキュメントには含まれていませんが、 redis 2.6で追加されたため、非常に便利です。

 set key strings +OK debug object key +Value at:0x7fa037c35dc0 refcount:1 encoding:embstr serializedlength:8 lru:3802212 lru_seconds_idle:14 debug sdslen key +key_sds_len:3, key_sds_avail:0, val_sds_len:7, val_sds_avail:0

使用されるエンコーディングはembstrで、文字列の長さは7バイト（val_sds_len）です。 hashedin.comの人たちが話していた96バイトはどうですか？私の理解では、それらは少し間違っていて、「set foo bar」を使用した例では112バイトのRAM（値ごとに56バイト、キーごとに同じ量）が必要であり、そのうち106はオーバーヘッドです。

もう少し高く、BITMAPを使用した場合のメモリのフェードについての話を約束しました。私が話したい機能は、それを使用している一部の開発者の注意から漏れています。みんな、記憶の最適化に関するコンサルタントはこれで定期的に稼いでいます。 redis-labsやdatadogなど。「ビットおよびバイトレベルの操作」コマンドファミリはredis 2.2で登場し、すぐにリアルタイムカウンター（たとえばSpoolの記事）の命の恩人として位置付けられ、メモリを節約できます。メモリを最適化するための公式ガイドには、このデータファミリを使用してオンラインで保存することに関する広告スローガンもあります。「1億人のユーザーにとって、このデータはRAMをわずか12メガバイトしか占有しません。」説明では、 SETBITとSETRANGEは、メモリを割り当てるときにサーバーラグが発生する可能性があることを警告しますが、重要なことは省略していますが、「BITMAPを使用すべきではない場合」または「BITMAPの代わりにSETを使用する方がよい場合」セクションを参照してください。

ラインが大根でどのように成長するかを理解すると、そのビットマップを見ることができます：

スパースデータには使用しないでください。
ペイロードと実際の負荷の関係を理解します（下の例を参照）。
ビットマップを埋めるダイナミクスを考慮してください。

例を考えてみましょう。最大1,000万人が登録されており、1,000万人目のユーザーがオンラインであるとします。

 setbit online 10000000 1 :0 debug sdslen online +key_sds_len:6, key_sds_avail:0, val_sds_len:1250001, val_sds_avail:1048576

実際のメモリ消費量は2,298,577バイトで、1,250,001バイトが「有用」です。ユーザーの1人のストレージのコストは約2.3 MBです。 SETを使用する場合、〜64バイト（4バイトのペイロードを含む）が必要になります。データのまばらさを減らし、ビットマップが30％の範囲に収まるように、適切な集約間隔を選択する必要があります。この場合、実際にこのデータ構造にメモリを効果的に使用します。これは、数百万人の視聴者がいて、10,000〜100,000人がオンラインで視聴している場合、ビットマップをこの目的で使用するとメモリのオーバーヘッドになる可能性があるという事実に基づいています。

最後に、大根のラインのサイズ変更は、メモリブロックの一定の再割り当てです。メモリの断片化は、大根の別の特異性であり、開発者はほとんど考えません。

 info memory $222 # Memory used_memory:506920 used_memory_human:495.04K used_memory_rss:7565312 used_memory_peak:2810024 used_memory_peak_human:2.68M used_memory_lua:36864 mem_fragmentation_ratio:14.92 mem_allocator:jemalloc-3.6.0

mem_fragmentation_ratioメトリックは、オペレーティングシステムによって割り当てられたメモリ（ used_memory_rss ）と大根によって使用されたメモリ（ used_memory ）の関係を示します。同時に、 used_memoryとused_memory_rssには、データ自体と、保存および表示用の内部大根構造の保存コストの両方が既に含まれています。大根はRSS（Resident Set Size）をオペレーティングシステムによって割り当てられたメモリの量と見なします。メモリがオペレーティングシステム自体によって物理的に割り当てられた場合、ユーザーデータ（およびその内部プレゼンテーションのコスト）に加えて、断片化コストも考慮されます。

mem_fragmentation_ratioを理解する方法は？値2.1は、データストレージに必要以上に210％のメモリを使用することを示しています。 1未満の値は、メモリが不足しており、オペレーティングシステムがスワップすることを示します。

実際には、mem_fragmentation_ratioの値が1〜1.5の範囲外にある場合は、何か問題があることを意味します。試してください：

大根をリロードします。再起動せずにアクティブに書き込む大根が長くなるほど、mem_fragmentation_ratioが高くなります。主にアロケーターの機能が原因です。特に、used_memoryとused_memory_peakに大きな違いがある場合に役立つことが保証されています。最後のインジケータは、大根インスタンスが起動してからこれまでに必要としていたメモリの最大量を示します。
どんな種類のデータと、どれだけの量を保存するかを確認してください。したがって、データを保存するのに4 GBで十分な場合は、32ビット大根アセンブリを使用します。少なくとも64ビットアセンブリを使用している場合は、少なくとも32ビットバージョンにDameをデプロイしてください（rdbは大根のビットサイズに依存せず、32ビットバージョンの64ビットインスタンスによって作成されたrdbを簡単に実行できます）。ほぼ確実に、これにより、フラグメンテーション（および使用されるメモリの量）が〜7％（アライメントの節約のため）減少します。
違いと機能を理解している場合は、アロケーターを変更してみてください。大根は、glibmalloc、jemalloc（ facebookのエンジニアが考えることを読んでください）、tcmallocで収集できます。

フラグメンテーションについて話すとき、LRUをオンにした大根の詳細や、通常の文字列キーが多数ある場合の追加の問題を考慮しません。これらはすべて別の記事にまとめられています。あなたがそれについて書く価値があるかどうか、そして大根で作業するときにあなたにとって他に重要だと思われる提案を共有してくれたら感謝します。

ユーザーpansaは、スワップ状況では、オペレーティングシステムがプロセスにRAMの一部を返した後、大根がused_memory_rssの値を再計算しないことを正しく観察します。大根は、データにアクセスするときにこの値をすでに再計算します。

目次：

参考のための追加資料：

Redisの内部：ライン

More articles: