問題点Nginxがリクエストの破棄を開始し、エラーログに could not allocate new entry in shm zone "mylimit" while logging request が大量に出力される場合、共有メモリ（shm）ゾーンが枯渇していることを意味します。これは通常、Nginxのレート制限モジュールが、割り当てられたメモリで処理できる以上のユニークなIPアドレスを追跡している高トラフィックなサイトで発生します。
基本的に、Nginxは着信リクエストの状態を保存するためのスロットを使い果たしており、新しいIPを制限すべきかどうかを追跡できないため、デフォルトでエントリを拒否するか、予期しない動作をします。
ログに出力されるエラー```
2024/05/28 10:15:30 [error] 1234#0: *5678 could not allocate new entry in shm zone "mylimit" while logging request, client: 192.168.1.1, server: example.com, request: "GET /api/v1/resource HTTP/1.1", host: "example.com"
## 即時の解決策：ゾーンサイズの拡張最も直接的な修正方法は、Nginxの設定で共有メモリゾーンのサイズを増やすことです。Nginxは起動時に、各レート制限ゾーンに対して一定量のメモリを割り当てます。
- Nginxの設定ファイル（通常は `/etc/nginx/nginx.conf` または `/etc/nginx/conf.d/` 内の特定のファイル）を開きます。- `limit_req_zone` ディレクティブを探します。- サイズパラメータを増やします（例：`10m` から `50m` または `100m` へ）。### 設定例変更前：
http { # 10MBで約160,000の状態を保持可能 limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s; }
変更後：
http { # 100MBで約160万の状態を保持可能 limit_req_zone $binary_remote_addr zone=mylimit:100m rate=10r/s; }
## 発生理由：計算上の根拠Nginxは共有メモリを使用して、`$binary_remote_addr`（または使用している任意のキー）の状態を保存します。64ビットシステムの場合：
- 1つの状態エントリは通常、**128バイト**を消費します。- **1MB**のゾーンには、アーキテクチャやキーの長さに応じて、約**8,000〜16,000**のエントリを保存できます。- **10MB**のゾーン（多くのチュートリアルの標準的なデフォルト）では、約**160,000**のユニークなIPを処理できます。トラフィックの急増、DDoS攻撃、あるいは単に非常に人気のあるサイトで短時間に数十万のユニークユーザーが訪れる場合、10MBの制限にはすぐに達してしまいます。
## 最適化：バイナリリモートアドレスの使用現在 `$remote_addr` を使用している場合は、`$binary_remote_addr` に切り替えてください。これはメモリ使用量において重要な最適化です。
- `$remote_addr`: IPを文字列（例："192.168.1.1"）として保存し、1エントリあたり7〜15バイトを消費します。- `$binary_remote_addr`: IPをバイナリ形式で保存します（IPv4の場合は4バイト、IPv6の場合は16バイト）。バイナリ版を使用すると、`shm` ゾーン内の各エントリのフットプリントが大幅に削減され、同じメモリ量でより多くの状態を保存できるようになります。
レート制限には常に binary_remote_addr を推奨
limit_req_zone $binary_remote_addr zone=mylimit:20m rate=5r/s;
## 修正の確認方法設定を更新した後、構文をテストしてNginxをリロードする必要があります：
構文エラーのチェック
sudo nginx -t
成功した場合はサービスをリロード
sudo systemctl reload nginx
エラーが解消されたことを確認するために、サイトに負荷がかかっている間にエラーログをリアルタイムで監視します：
tail -f /var/log/nginx/error.log | grep "shm zone"
エラーが表示されなくなれば、新しいメモリ割り当てで十分です。すぐに再発する場合は、分散攻撃を受けているか、トラフィック量に対してさらに大きなゾーン（例：200mや500m）が必要な可能性があります。
## よくある落とし穴### 1. 過度に厳格なレート制限`rate` が低すぎ（例：`1r/s`）に設定されている場合、Nginxはクライアントが制限内に収まるように状態をより長くメモリに保持します。これによりゾーンがより早く満杯になります。レート制限が正当なユーザー層に対して厳しすぎないか評価してください。
### 2. 不適切な変数の追跡`$http_user_agent` をキーとして使用し、数千のユニークな（または偽装された）ユーザーエージェントがアクセスしてきた場合、メモリはほぼ瞬時に満杯になります。特別なユースケースがない限り、`$binary_remote_addr` を使用してください。
### 3. サーバーのメモリ制限サーバーに1GBのRAMしかないのに、単に `zone=mylimit:2g` と設定しないでください。OSから要求された共有メモリを割り当てられない場合、Nginxは起動に失敗します。
## 教訓- **容量の事前計算：** 分あたりのピークユニーク訪問者数を見積もり、予想される同時ユニークIP 10,000件につき少なくとも1MBを割り当てます。- **RAMの監視：** 共有メモリゾーンは起動時に割り当てられます。大きなゾーンを収容するのに十分な空き物理RAMがシステムにあることを確認してください。- **バイナリの使用：** 1MBあたりのエントリ数を最大化するために、常に `$binary_remote_addr` を使用してください。- **クリーンアップ：** Nginxはゾーンが満杯になると古いエントリを自動的に削除しますが、新しいIPの流入がLRU（Least Recently Used）の期限切れよりも早い場合は追いつきません。大きなゾーンは必要なバッファを提供します。