ワードプレス

Redis が予想以上に低速になる理由：よくある設定ミスとそれを回避する方法

Redis は、構成、インフラストラクチャ、またはアクセスパターンが適切でない場合、動作が遅くなることがよくあります。まさにここで redisのチューニング 。具体的に、どの設定ミスが遅延の原因になっているのか、そしてそれを体系的に回避する方法を説明します。.

中心点

スワッピング レイテンシを解消：RAMのボトルネックは、すぐにハードディスクへのアクセスにつながります。.
フォークラグ RDB/AOF による：スナップショットと書き換えは、短くて厳しい中断を引き起こします。.
AOF/ストレージ 遅延：ディスクの速度が遅い場合や fsync が積極的に動作している場合、応答時間が長くなります。.
遅いコマンド：大規模な構造と高価なコマンドは CPU に負担をかけます。.
ネットワークパス 考慮すべき点：距離、コンテナオーバーヘッド、プロキシはレイテンシーを増加させます。.

負荷がかかるとRedisの動作が遅くなる理由

Redis は非常に短い応答時間を実現しますが、現実また、実験室と実環境では状況が大きく異なります。仮想レイヤー、共有ホスト、追加のネットワークオーバーヘッドは、特に負荷のピーク時に、ミリ秒単位で負荷を増加させます。コンテナオーバーレイ、サイドカープロキシ、リモートゾーンによって、実際のインメモリ速度が隠されている設定をよく目にします。さらに、透過的な巨大ページや積極的なスワッピングなど、オペレーティングシステムの特性も遅延をさらに悪化させています。基盤が整っていないと、エンジンは高速で動作し、データベース以外の部分にボトルネックがあるにもかかわらず、Redis が突然遅く感じられます。.

スワッピングの回避：RAM、maxmemory、およびエヴィクション戦略

オペレーティングシステムが Redis メモリをディスクにスワップすると、 レイテンシー. そのため、私は常に十分な RAM を確保し、その使用状況を継続的に監視しています。 maxmemory と適切なエヴィクションポリシーを設定して、インスタンスがスワップに滑り込む代わりに、タイムリーにデータを置換するようにします。メモリを大量に消費するプロセスは Redis ホストから切り離してください。競合するワークロードはリスクを増大させるからです。これらの基本ルールが守られないと、他の対策では実際の問題を解決できず、リクエストごとに突然数百ミリ秒の時間がかかってしまう可能性があります。.

RDB スナップショットと AOF リライトによるフォークのレイテンシーを抑制

RDBスナップショットとAOFリライトは、フォークによってバックグラウンドプロセスを起動します。これは、大規模なインスタンスでは顕著な休憩生成します。Linux システムでは、コピーオンライトのコストを増加させ、ラグを長引かせるため、透過的な巨大ページを無効にします。また、フォークの頻度を制限するために、スナップショット間隔と AOF リライトのしきい値を調整します。大規模なモノリシックインスタンスは、個々のフォークの影響を軽減するために、複数の小さなシャードに分割しています。これを無視すると、それまではすべてが高速に動作していたにもかかわらず、バックアップの瞬間にクラッシュが発生することがよくあります。.

AOF、ストレージ、fsync 戦略を正しく選択する

AOF は耐久性を高めますが、ディスクの速度低下や fsync の過度な実行を引き起こします。 応答時間 上へ。私は Redis データを高速 SSD に保存し、バックアップやデータベースの I/O から分離して、書き換えが渋滞しないようにしています。多くのワークロードでは、everysec と no-appendfsync-on-rewrite yes を組み合わせることで、ピークを平準化することができます。反射的に「fsync always」を有効にするのではなく、RDB と AOF の組み合わせが要件に適しているかどうかを定期的に確認してください。ハードウェアに注意を払い、戦略を慎重に選択することで、レイテンシを制御することができます。.

遅いコマンドとデータモデルを緩和する

大規模な構造物では、特定のコマンドは多くのコストがかかります。 CPU, 、たとえば SORT、ZINTERSTORE、または大規模な LRANGE などです。私はスローログを積極的に活用し、コマンドタイプ、データサイズ、キーごとに外れ値を分析しています。大きな構造は、より小さなセグメントに分割するか、アクセスパターンにより適した代替データタイプを選択します。必要に応じて、CPU を大量に消費する評価は、ホットパスが高速なまま維持されるように、レプリカまたは専用インスタンスに移します。これにより、クエリは、散発的に数秒を消費する代わりに、再び計画可能になります。.

ネットワーク、コンテナ、距離を最小限に抑える

多くのレイテンシの問題は、実際には 輸送時間 Redis の問題ではありません。アプリケーションと Redis を同じゾーンに保持し、不要なプロキシを避け、MTU および TLS オーバーヘッドを確認します。Kubernetes セットアップでは、オーバーレイネットワークと CNI プラグインの潜在的なボトルネックに注意します。ホップ数が少ないほど、95/99 パーセンタイルのばらつきは小さくなります。予測可能なミリ秒単位の応答時間を求めるなら、Redis をデータセンター全体ではなく、コードにできるだけ近づけて設置するんだ。.

サイジング、シングルスレッド、シャーディングへの実用的なアプローチ

Redisインスタンスはメインスレッドでコマンドを処理するため、制限があります。 CPUコア およびコマンドレートが実際のパフォーマンスです。十分な vCPU を選択し、マシンから外部サービスの負荷を軽減し、複数のインスタンスに責任を分散します。純粋なキャッシュの使用事例については、時折、代替案を比較します。 Redis と Memcached の比較決定を下すのに役立ちます。シャーディングは負荷を分散し、個々のラグの影響を軽減します。すべてを 1 つのインスタンスに詰め込むと、ピーク時の負荷によるボトルネックや応答時間の遅延が発生するリスクがあります。.

モニタリング、メトリクス、トラブルシューティング

測定値がなければ、最適化は ブラインドフライト. 。コマンドごとのレイテンシ、95/99 パーセンタイル、メモリ使用量、断片化、クライアント数、BGSAVE/AOF イベントを監視しています。INFO、スローログ、インフラストラクチャのモニタリングにより、RAM、CPU、I/O、ネットワークのいずれが制限要因であるかを迅速に把握できます。重要なのは、フォーク、リライト、デプロイメントとラグを関連付けるために、期間を一貫して監視することです。また、平均値を見るのではなく、ビジネスニーズに合ったしきい値に基づいてアラームを設定してください。.

キャッシュ戦略とキー設計、ヒット率を向上させる

キーとTTLが 恣意的 設定されています。ヒット率の傾向が上昇するように、キャッシュアサイドや一貫性のある、意味のあるキーなどの明確なパターンを採用しています。TTL は、データが十分に最新の状態を保ちながら、常に再計算される必要がないように選択しています。TTL、タグベースのアプローチ、Pub/Sub 信号などを使用して、無効化を明示的に計画してください。実践的な手順については、以下のガイドが参考になります。キャッシュの設定そして、正確に測定する。.

設定チェック：合理的なデフォルト設定と迅速な進捗

すぐに効果を見たいなら、まず信頼性の高い デフォルト そして、負荷をかけてテストします。スワッピングは厳密に排除し、maxmemory でメモリを調整し、RDB と適度な AOF で永続性を調整しています。THP は無効にし、データを SSD に、他の I/O ジョブとは別々に配置しています。ネットワーク側では、経路を短くし、不要なプロキシを削減するようにしています。以下の表は、典型的なエラーと実用的な設定を含む、主要な調整項目をまとめたものです。.

トピック	測定マーク	誤設定	推薦	ヒント
RAM/スワップ	高いレイテンシのピーク	最大メモリなし	maxmemory + エヴィクション	スワップは絶対に避ける
永続性	フォークラグ	頻繁な BGSAVE	間隔を空ける	インスタンスを小さくカットする
AOF/fsync	IOピーク	fsync always	everysec + オプション	SSDと分離ディスク
THP	長いフォーク	THP アクティブ	THPから	カーネル設定の確認
コマンド	高いCPU	SORT/STORE 大	スローログを使用する	データモデルを調整する
ネットワーク	輸送が支配的	遠隔地	地域密着	ホップとMTUをチェックする

アーキテクチャパターンとキャッシュ階層

優れた建築は、最短の経路で問い合わせを誘導します。パス回答へ。Edge、App、Redisキャッシュを組み合わせて、高価なオリジンリクエストを減らし、Redis自体の負荷を軽減しています。これにより、読み取りアクセスが分散され、Redisは高速で動的なキーを処理します。適切な段階の概要は、独自のプラットフォームに合わせて調整するのに役立ちます。キャッシュ階層最大の効果のある要素を優先して取り組みましょう。アーキテクチャと構成を一緒に考えることで、個別の調整よりも持続的にレイテンシの問題を解決することができます。.

クライアント接続、パイプライン、プール

多くのミリ秒が失われる握手 Redis ではなく、Connection Pooling による長寿命の TCP/TLS 接続を採用しています。これにより、RTT が短縮されるだけでなく、TLS ハンドシェイクや証明書チェックも削減されます。パイプライン処理により、多くの小さなコマンドが 1 つの RTT にまとめられるため、応答が厳密に順番に必要とされない限り、スループットが大幅に向上します。アトミックシーケンスには MULTI/EXEC を意図的に使用しますが、ホットパスでトランザクションを無差別に混合することはありません。タイムアウトは厳格かつ現実的な値に設定し、 tcp-keepalive デッドコネクションを確実に検出するために有効にしてください。また、 maxclients設定にはulimit（ファイルなし）を使用して、記述子の欠如によってピークが失敗しないようにします。また、Nagle のアルゴリズムは Redis には役立ちません。サーバーとクライアントの両方が TCP_NODELAY 回答がすぐに流れ出るように活用してください。.

I/OスレッドとTLSオーバーヘッドを効果的に活用する

Redis はコマンド実行のために残ります シングルスレッド, 、ただしネットワーク I/O は ioスレッド 負荷を軽減します。TLS の負荷が高い場合やペイロードが大きい場合は、適度な設定（例：2～4 スレッド）を有効にして、 io-threads-do-reads yes. これにより、コマンドの CPU 作業ではなく、読み取り/書き込みが高速化されます。その際、システム負荷とレイテンシのパーセンタイルを監視しています。スレッドが多すぎるとコンテキストスイッチが増加し、そのメリットが相殺されてしまうからです。TLS を使用せず、小さな応答で作業している場合は、ほとんどメリットがありませんが、TLS を使用すると、確実に ネットワーク遅延.

有効期限、TTLストーム、レイジーフリー

同期して終了する TTL エクスパイアスパイクを発生させます。TTL にジッターを付与し、プロセスを分散させ、アクティブなエクスパイア負荷を低く抑えます。大規模な削除はメインスレッドをブロックするため、私は UNLINK DEL の代わりに大きなキーを使用し、 lazyfreeオプション（例：. lazyfree-lazy-eviction, lazyfree-lazy-expire, lazyfree-lazy-server-del）。これにより、コストのかかるフリー操作はバックグラウンドスレッドに移行します。さらに、INFO で Expire 統計を監視しています。増加 期限切れキー そして evicted_keys 同時に強い場合、データモデルが大きすぎるか、TTL戦略のバランスが悪いかのどちらかです。.

メモリの断片化とアクティブデフラグ

高い メモリ断片化率 INFO は断片化またはスワップ圧力を示しています。私は activedefrag そしてサイクルを調整する（active-defrag-cycle-min/max）を使用して、メインスレッドに過大な負荷をかけることなく、段階的にメモリを回復します。これは、中規模のオブジェクトの更新や削除が多いワークロードで特に有効です。同時に、 エンコーディング 小さな構造体。誤って設定されたパック境界（リスト、ハッシュ、セット）はオーバーヘッドと CPU を増加させるためです。目標はバランスです。効率性を確保するのに十分なパックでありながら、更新のコストを高めるほど大きなパック構造体ではないことです。また、大きな「オール・オア・ナッシング」のワークロードを避け、削除を 1 日を通して分散することで、断片化を解決しています。.

クラスタ、シャーディング、ホットスポットを管理

シャーディングは、ホットキーがすべて同じシャーディングに属している場合を除き、レイテンシーを低減します。私は ハッシュタグ, 関連キーをまとめて保持し、頻繁に使用されるキーは意図的に分散させます。マルチキーコマンドは、クラスタ内ではスロット内でしか機能しません。私は、これらの操作がスロットを横断する必要がないようにデータモデルを設計しています。リシャーディングでは、トラフィックの谷を生成しないようにスムーズな移動に注意し、 MOVED/ASKクライアントのレート。純粋に読み取り負荷を軽減するためにレプリカを利用しますが、一貫性の要件にも注意を払います。計画なしにシャーディングを行うと、ローカルラグが分散された、見つけにくいレイテンシのピークに置き換わります。.

レプリケーション、バックログ、フェイルオーバー

安定したレプリケーションにより、完全な再同期やレイテンシのピークが発生しません。私はサイズを決定します。 repl-backlog-size PSYNC によって、短いネットワーク中断後のレプリカが追いつくように、余裕を持たせてください。. ディスクレスレプリケーション (repl-diskless-sync yes）は同期中にI/Oを節約しますが、ネットワーク要件は低下しません。帯域幅は適切である必要があります。. クライアント出力バッファ制限 レプリカおよびパブ/サブクライアントについては、低速のリーダーがインスタンスをブロックしないように設定します。 min-replicas-to-write 耐久性と可用性のバランスをとります。一部のワークロードでは有効ですが、レイテンシーが重要なパスでは有効ではありません。重要：実際のデータ量で定期的にフェイルオーバーを練習し、タイムアウトを調整して、実際の障害がレイテンシーの賭け事にならないようにしてください。.

クライアントバックプレッシャーと出力バッファ

クライアントが Redis が生成するデータよりも遅い速度でデータを消費する場合、データは増加します。 出力バッファ. 私は明確な境界線を設定します（クライアント出力バッファ制限 通常、pubsub、レプリカ）とログのドロップを監視して、問題のある候補を見つけます。Pub/Subファンアウトについては、「オールチャンネル」よりも、より小さなメッセージとテーマ別チャンネルを好みます。キースペース通知は、範囲が広すぎるため、特定の目的でのみ有効にします。 notify-keyspace-events CPU のコストが顕著に増加します。バックプレッシャーはアーキテクチャの問題として扱います。個々のサブスクライバーに過大な負荷をかける 1 つの大きなストリームよりも、複数の特殊化されたストリーム/チャネルの方が望ましいです。.

オペレーティングシステムのチューニング：ソケット、ファイル、VM

THP に加えて、カーネルのデフォルト設定も レイテンシー はっきり。私は増額します。 somaxconn およびバックログの値、適合 fs.file-max および ulimit (ファイルなし) を押して、 tcp_keepalive_time ハンガーを避けるのに十分なほど低い。. vm.swappiness 私は非常に深く、多くの場合 1 に近く設定します。 vm.overcommit_memory 1に設定して、フォークの通過を高速化します。CPUガバナーを「パフォーマンス」に設定すると、負荷変動時の周波数スロットリングを防止できます。ストレージ側では、可能であれば「ノイズの多い隣人」を排除し、バックアップジョブからデータを分離します。これらはすべて、小さな調整要素ですが、組み合わせることで ジッター 99パーセンタイルに達する。.

現実的なベンチマーク、好況時の数字ではなく

redis-ベンチマーク 有用な傾向を提供しますが、実際のワークロードは異なります：コマンドミックス、ペイロードサイズ、, パイプライン処理, 、接続数、TLS、ネットワーク経路。私は、生産クライアントを使用してシミュレーションを行い、 -c （同時実行性）および -P （パイプライン）と、長期間にわたるレイテンシのパーセンタイルを測定します。キャッシュ、JIT、TCP ウィンドウが現実的に機能するためには、コールドフェーズとウォームフェーズが重要です。ネットワークパスについては、ゾーン変更を評価するために、人工的な RTT/ジッター注入を時折使用しています。重要なのは、ベストケースの数値ではなく、その安定性です。 95/99パーセンタイル 負荷がかかったままの状態を維持する。.

診断ツールを的を絞って活用する

INFO と Slow Log のほかに、私は以下を使用しています。 レイテンシードクター, 体系的なスパイクを検出するため、および レイテンシーグラフ/履歴 時間的な位置付けのために。. メモリ統計/ドクター メモリが無駄になっている箇所を表示します。MONITOR は短期間かつ孤立したインスタンスでのみ使用しています。オーバーヘッドは現実的な問題です。ホストでは、 iostat, vmstat, pidstat そして ss, I/O 待機、ランキュー、ソケットの状態を確認します。目標は、仮説に基づくトラブルシューティングです。メトリック → 疑わしい点 → 反証。これにより、盲目的な調整を避け、レイテンシーを測定可能に低減する対策を取ることができます。.

簡単にまとめると：Redis の高速性を維持する方法

私は、次の方法で Redis の速度低下を防ぎます。 スワップ シャットダウンし、メモリを厳密に管理し、適切な判断で永続性を設定します。THP をオフにし、SSD をオンにし、フォークの頻度を減らすことで、ほとんどのピークは解消されます。高価なコマンドはスローログで認識し、データモデルを調整して、ホットパスをスリムに保ちます。Redis をアプリケーションの近くに配置し、CPU を適切にサイズ設定し、負荷を複数のインスタンスに分散します。一貫したモニタリングにより、トレンドを早期に認識し、「redis slow hosting」の影響も永続的に抑制します。.