RabbitMQのキューメモリ消費量とスループットをリアルタイムに試算・可視化できる、完全ブラウザ完結型の高精度サイジングツールです。
クライアントサイドでのリアルタイム解析・可視化シミュレーションに対応した、RabbitMQキューのメモリ消費量およびスループット設計・サイジングガイド。
Erlang BEAMの合意形成エンジンおよびストレージサブシステムを指定します。クォーラムキュー（Quorum Queues）はRaftコンセンサスを実装しており、インフライトなステートマシンエントリごとに約30〜40%の追加RAMを必要とします（CQv2の約32Bに対し約384B）。クラシックキューv2（CQv2）はメッセージを32MBの不変ディスクスラブに分割格納し、従来のクラシックキューv1（CQv1）のErlangヒープETSディクショナリと比較して、ページアウトされたインデックスメモリを77%削減します。
非圧縮時のAMQP 0-9-1メッセージボディ長（バイト単位）。64バイト以下のペイロードはローカルのErlangプロセスヒープ内に直接割り当てられ、コピー方式のガベージコレクション（GC）の対象となります。64バイトを超えるペイロードはErlangのグローバルな参照カウント方式バイナリアロケータ（refcバイナリ）を使用し、AMQP fanoutエクスチェンジを介した複数サブスクライバー間でのゼロコピーメモリ共有を実現します。
コンシューマーチャネルごとに設定するAMQP basic.qosのプリフェッチ上限数。プリフェッチによって配信されたメッセージは、ack（確認応答）が完了するまでページアウト不可能なErlang RAM上に固定（ピン留め）されます。プリフェッチを0（無制限）に設定すると、バックログ急増時に深刻なRAM枯渇を引き起こします。メモリ飽和を防ぎつつ安定したネットワークスループットを維持するための推奨ベンチマーク値は50〜200です。
アクティブなbasic.consumeタグを保持する並行ワーカーチャネルの総数。consumerQosPrefetchCountおよびaverageMessagePayloadBytesと直接乗算され、ページアウト不可能な総インフライトメモリ割り当て量を算出します：M_inflight = コンシューマー数 × プリフェッチ数 × (ペイロードバイト数 + 120B BEAMフレームメタデータ)。
持続的なメッセージ受信スループット（秒間メッセージ数）。vm_memory_high_watermark（ホストRAMのデフォルト0.40）およびdisk_free_limitに照らし合わせて評価されます。受信レートがコンシューマーのackレートを超過した場合、純バックログ蓄積速度によってメモリ高水準アラーム到達までの猶予時間が決定されます：t_breach = (M_watermark - M_current) / (R_backlog × メッセージあたりオーバーヘッド)。
64バイトを超えるAMQPメッセージは、Erlangのグローバルな参照カウント方式バイナリヒープ（refcバイナリ）に常駐します。コンシューマーやブローカープラグインが1MBのペイロードから極小のヘッダースライスのみを切り出した場合、Erlang BEAMランタイムはその極小サブバイナリがGCされるまで、1MB全体の物理RAM割り当てを保持し続けます。高スループットなルーティングパイプラインでは、明示的にバイナリのコピーや文字列の再エンコードを行い、背後にある巨大なrefc参照を切り離してファントムメモリの肥大化を防止してください。
クォーラムキューは、追記専用のRaft先行書き込みログ（WAL）をfsync()システムコールによってディスクへフラッシュします。書き込みレイテンシが変動しやすいクラウドブロックストレージ（AWS EBS gp2のバースト枯渇など）では、CPUコア数に余裕があってもIOPSスロットリングによりキュースループットが200 msg/s程度に制限される危険性があります。raft.wal_max_batch_sizeを4096に調整し、/var/lib/rabbitmqを10,000以上の持続書き込みIOPSを備えた高性能NVMe SSD上に配置することで、クォーラムキューあたり毎秒30,000メッセージ超へのスケールアウトが可能になります。
確立されたTCP接続はそれぞれ、カーネルソケットメモリ（rmem/wmemで64KB〜256KB）およびErlangリーダープロセスのオーバーヘッド（約40KB）を消費します。単一のTCP接続上で数百ものアクティブチャネルを過剰に多重化すると、シングルスレッドで動作するErlangソケットリーダーでHead-of-Line（HoL）ブロッキングが発生します。TCP接続1本あたり10〜50程度のアクティブチャネルを保持するバランスの取れた接続プールを設計することで、ソケットファイル記述子を浪費することなく、マルチコアBEAMスケジューラーの性能を最大限に引き出せます。
キューサイジングおよびバックログドレイン予測のすべての計算は、決定論的なO(1)閉形式代数方程式とインメモリWeb Workerを用いて、完全にクライアントサイド（ブラウザ内）で実行されます。クラスタトポロジのメトリクス、キュー滞留深度の統計、ペイロードサイズ設定などのパラメータがローカルブラウザのサンドボックス外に送信されたり、外部ネットワークエンドポイントに到達したりすることは一切ありません。エンタープライズインフラの機密監査においても完全な情報漏洩防止（Zero-Exfiltration）が保証されます。
'rabbitmq-diagnostics memory_breakdown'を実行し、vm_memory_high_watermark（デフォルト0.40）のアラームが作動していないか確認してください。RabbitMQはパブリッシャーのTCPソケットからの読み取りを一時停止することでバックプレッシャー（背圧）を適用するため、クライアント側のソケットバッファが満杯になり、AMQPプロトコル例外をスローすることなくパブリッシャースレッドが停止します。安易にウォーターマークを0.50以上に引き上げてはなりません。コンシューマーのbasic.qosプリフェッチを100以下に絞って未確認メッセージを解放するか、コンシューマーを水平スケールするか、休眠状態のデッドレターキュー（DLQ）をパージしてメモリを回復してください。
未確認メッセージのリーク、またはアトムテーブルの枯渇を確認してください。まず 'rabbitmqctl list_queues name messages_unacknowledged consumers' を実行します。messages_unacknowledged が異常に高い場合、コンシューマーがackの返却を漏らしており、メッセージがRAM内に永続固定されています。さらに、カスタムAMQPルーティングヘッダーを検査し、パブリッシャーが動的に生成した一意の文字列ヘッダーがErlangアトムに変換されていないか確認してください。BEAMのアトムテーブルには1,048,576個の厳格な上限があり、枯渇するとブローカーが即座にクラッシュします。
クォーラムキューのスライディングウィンドウキャッシュ設定である 'quorum_commands_soft_limit'（デフォルト32,768メッセージ）を確認してください。クォーラムキューはコンシューマーへの低遅延配信を実現するため、直近でコミットされたメッセージをメモリキャッシュ上に保持します。パブリッシャーが高速でコンシューマーが低速なためバックログが深くなっている環境では、'quorum_commands_soft_limit = 1000' に設定した上で 'x-max-in-memory-length' ポリシーを適用し、Raftの永続性を損なうことなくディスクへの積極的なインメモリエビクション（追い出し）を強制してください。
総キューメモリ使用量は「M_total = M_payload + M_metadata + M_inflight + M_socket」で算出されます。ここで、M_payloadはRAM上に常駐するメッセージ本文、M_metadataはBEAMプロセスのインデックスオーバーヘッド（クラシックキューv2で約32B、クラシックキューv1で約140B、クォーラムキューで約384B）、M_inflight = コンシューマー数 × basic.qosプリフェッチ数 × (ペイロード + メタデータ)、M_socketはTCP接続ごとに割り当てられる64KB〜256KBです。例えば、プリフェッチ100のコンシューマー50台が4KBのメッセージを処理する場合、50 × 100 × 4.12KB = 20.6MBがページアウト不可能なインフライトRAMとして単独で固定されます。
本番環境におけるvm_memory_high_watermarkの推奨値は0.40〜0.45（システム総RAMの40%〜45%）です。残りの55%〜60%は、OSのファイルシステムページキャッシュ、ソケットバッファ、およびErlang BEAMのガベージコレクション（コンパクションスイープ）用領域として確保します。ウォーターマークを0.55以上に設定すると、ErlangのコピーGCがメモリ圧縮中にプロセスのヒープサイズを瞬間的に最大2倍に膨張させ、アラームによるパブリッシュ抑制が間に合わずにLinuxのOOM Killerが発動する重大なリスクが生じます。
アクティブなインメモリメッセージに関して、クォーラムキューはRaftコンセンサス追跡メタデータ（任期/term、インデックス、コマンドメタデータ：メッセージあたり約384B vs 約32B）が必要となるため、クラシックキューv2（CQv2）と比較してメッセージあたり約30%〜40%多いメモリを消費します。しかし、クォーラムキューはログセグメントを直接ディスクに永続化し、エビクションキャッシュウィンドウを維持するため、旧来のミラーリングされたクラシックキュー（HA同期）を悩ませていた深刻なErlangヒープの断片化やクラスタ全体の同期停止ストールを完全に排除できます。
Erlangの総メモリ使用量がvm_memory_high_watermarkを超過すると、RabbitMQはクラスタ全体のアラームを直ちに発火させ、プロデューサー（パブリッシャー）のTCPソケットからの読み取りを停止してbasic.publishの処理を一時中断します。プロデューサーはAMQPエラーを受信することなくローカルのTCPソケット書き込みバッファでブロックされますが、コンシューマー側の処理はブロックされず継続します。コンシューマーによるメッセージ消費とBEAMのGCによって常駐メモリがウォーターマークを下回ると、RabbitMQはアラームを解除し、パブリッシャーのソケットポーリングを自動的に再開します。
basic.qosプリフェッチ設定は、RabbitMQがbasic.ackを待つ間にコンシューマーへプッシュ配信できる未確認メッセージの最大数を規定します。配信されたメッセージはErlangプロセスメモリ内に固定（ピン留め）され、どれだけメモリ圧迫が生じてもディスクにページアウトできません。例えば50台のコンシューマーが10KBのメッセージをプリフェッチ1,000で処理した場合、50 × 1,000 × 10KB = 500MBものページアウト不可なインフライトRAMが拘束されます。プリフェッチを50〜100に制限することで、ネットワーク飽和状態の高スループットを維持しながら、インフライトRAMを50MB未満に抑えられます。
バックログのドレイン時間は次の数式で算出されます：「ドレイン時間（秒） = 滞留メッセージ数 / (全コンシューマーの総ドレインレート msg/s - 受信パブリッシュレート msg/s)」。例えば、20台のコンシューマーがそれぞれ150 msg/s（合計3,000 msg/s）でackを返し、受信パブリッシュレートが1,000 msg/sの場合、正味のドレイン速度は2,000 msg/sとなります。500,000件のバックログであれば、500,000 / 2,000 = 250秒（4分10秒）で完全に解消されます。コンシューマーの処理レートがパブリッシュレート以下の場合、ドレイン時間は無限大となり、キューが肥大化し続けていることを示します。
クラシックキューv1（CQv1）はキューインデックスをErlangプロセス辞書構造内に保持するため、ペイロード本文がディスクにページアウトされた後もメッセージあたり120B〜140BのRAMを消費し続けます。これに対し、クラシックキューv2（CQv2）はメッセージとインデックスを32MBの不変ディスクセグメントファイルに格納することで、ページアウトされたメッセージのインメモリオーバーヘッドを75%以上削減し、メッセージあたり約32Bに抑え込みます。1,000万件のメッセージバックログにおいて、CQv1は約1.4GBものErlangヒープインデックスメモリを常駐させますが、CQv2であればわずか約320MBで済みます。
PostgreSQLのメモリ設定計算およびPGTuneに基づくpostgresql.confパラメータを自動生成。shared_buffers、work_mem、effective_cache_size、max_connectionsを最適化します。
RAID 0/1/5/6/10/50/60およびZFS（RAIDZ1/Z2/Z3）構成の実効容量を十進法TB・二進法TiBで正確に計算。パリティ損失、URE（回復不能読み取りエラー）によるリビルド失敗リスク、再構築所要時間、ドライブベイ配置の可視化に対応した高精度ストレージ設計ツールです。
A/Bテストに必要なサンプルサイズ、統計的検定力、所要期間を高精度に計算。最小検出効果（MDE）の逆算、売上等の連続値指標、多群ボンフェローニ補正、サンプル比率の不整合（SRM）検証に対応。
ルートフォントサイズを基準にPXとREMを即座に相互変換。CSS clamp()流体タイポグラフィ、Tailwindクラス、対照表を自動生成します。
HTTPステータスコードの確認、リダイレクトチェーン（多段転送）の追跡、レスポンスヘッダーの解析をリアルタイム実行。1xx〜5xxのエラー原因、RFC仕様、SEO検索評価への影響、復旧手順をブラウザ完結で診断します。
正規表現のパターン一致、キャプチャグループ、構文トークン解説、置換処理をリアルタイムに検証・デバッグ・最適化します。