Alibaba Cloud Linux 3 には、クラウドワークロード向けに最適化された、事前調整済みのカーネルパラメータセットが付属しています。このドキュメントでは、これらのデフォルト値と、特定のワークロードに合わせて調整が必要になる可能性のある一般的なパラメーターについて説明します。
重要
カーネルパラメータの調整は、変更を正当化する観測データがある場合にのみ行ってください。各パラメーターを変更する前にその機能を理解してください。パラメーターの動作は、カーネルのバージョンや環境の種類によって異なる場合があります。
Alibaba Cloud Linux 3 の最適化済み構成
これらのパラメーターは Alibaba Cloud Linux 3 で事前構成されています。記載されている値は、OS によって適用される最適化済みのデフォルト値です。
パフォーマンスの向上
| パラメーター | 値 | 説明 |
|---|---|---|
net.ipv4.tcp_timeout_init | 1000 | 初期 TCP 再送タイムアウト (ミリ秒単位)。最小値：2 HZ。 > 重要 これは Alibaba Cloud Linux 3 のカスタム機能です。長期的なメンテナンスは保証されません。Alibaba Cloud Linux 4 以降では非推奨です。 |
net.ipv4.tcp_synack_timeout_init | 1000 | SYN-ACK 再送の初期タイムアウト (ミリ秒単位)。最小値：2 HZ。最初の再送後、タイムアウトは倍になります。 > 重要 これは Alibaba Cloud Linux 3 のカスタム機能です。長期的なメンテナンスは保証されません。Alibaba Cloud Linux 4 以降では非推奨です。 |
net.ipv4.tcp_synack_timeout_max | 120000 | SYN-ACK 再送の最大タイムアウト (ミリ秒単位)。最小値：2 HZ。各再送で、タイムアウトは tcp_synack_timeout_init から始まり、この上限に達するまで倍になります。 > 重要 これは Alibaba Cloud Linux 3 のカスタム機能です。長期的なメンテナンスは保証されません。Alibaba Cloud Linux 4 以降では非推奨です。 |
net.ipv4.tcp_ato_min | 40 | 最小 ACK タイムアウト (ミリ秒単位)。有効値：4～200 ms。 > 重要 これは Alibaba Cloud Linux 3 のカスタム機能です。長期的なメンテナンスは保証されません。Alibaba Cloud Linux 4 以降では非推奨です。 |
net.ipv4.tcp_init_cwnd | 10 | 初期 TCP 輻輳ウィンドウサイズ。 > 重要 これは Alibaba Cloud Linux 3 のカスタム機能です。長期的なメンテナンスは保証されません。Alibaba Cloud Linux 4 以降では非推奨です。 |
net.ipv4.tcp_synack_retries | 2 | サーバーが最終 ACK を受信しない場合の SYN-ACK 再送回数。高品質なネットワークでは、3 回の再送で約 7 秒後に接続が切断されます。 |
net.ipv4.tcp_slow_start_after_idle | 0 | TCP 接続がアイドル状態になった後、スロースタートを再開するかどうかを制御します。0 は再開を無効にし、アイドル期間中も輻輳ウィンドウを維持します。1 は再開を有効にします。断続的なトラフィックバーストがある長期間の接続では、短いアイドル期間後のスループット低下を避けるために、これを 0 に設定します。 |
/sys/kernel/mm/transparent_hugepage/hugetext_enabled | 0 | Hugetext 機能を制御します。この機能は、ヒュージページを使用してバイナリおよび動的ライブラリのコードセグメントをマップし、iTLB ミスを削減します。有効値：0 = 無効、1 = バイナリおよび動的ライブラリのみにヒュージページを使用、2 = 実行可能な匿名ヒュージページのみ、3 = 両方。データベースや大規模アプリケーションなど、大きなコードセグメントを持つワークロードで Hugetext を有効にすると、iTLB ミスが減少し、パフォーマンスが向上します。 > 重要 これは Alibaba Cloud Linux 3 のカスタム機能です。長期的なメンテナンスは保証されません。 |
リソース使用率の向上
| パラメーター | 値 | 説明 |
|---|---|---|
net.ipv4.tcp_syn_retries | 4 | クライアントが SYN-ACK を受信しない場合の SYN 再送回数。初期再送タイムアウト (RTO) が 1 秒の場合、4 回の再送には約 15 秒かかり、接続は約 31 秒後にタイムアウトします。 |
net.ipv4.tcp_retries2 | 8 | ACK の受信を停止したアクティブな TCP 接続の最大再送回数。初期 RTO が 200 ms の場合、8 回の再送には約 51 秒かかり、最終的なタイムアウトは約 102 秒後に発生します。 |
net.ipv4.tcp_tw_timeout | 60 | TIME_WAIT 状態の TCP ソケットのタイムアウト (秒単位)。有効値：1～600 秒。詳細については、「TCP TIME-WAIT タイムアウト期間の変更」をご参照ください。 > 重要 これは Alibaba Cloud Linux 3 のカスタム機能です。長期的なメンテナンスは保証されません。Alibaba Cloud Linux 4 以降では非推奨です。 |
net.ipv4.tcp_max_tw_buckets | 5000 | TIME_WAIT 状態で同時に許可される TCP 接続の最大数。TIME_WAIT 接続が net.ipv4.ip_local_port_range で定義されたポート範囲を使い果たすと、新しい connect() 呼び出しは失敗します。TCP: time wait bucket table overflow エラーが表示される場合は、この値を増やしてください。詳細については、「Linux ECS インスタンスで「TCP: time wait bucket table overflow」エラーが多数発生するのはなぜですか？ |
ネットワークセキュリティ
| パラメーター | 値 | 説明 |
|---|---|---|
net.ipv4.conf.all.rp_filter | 0 | 現在のすべてのネットワークインターフェイスカード (NIC) に対するリバースパスフィルタリング。有効値：0 = 無効、1 = 厳密 (リバースパスが受信インターフェイスと一致しない場合、パケットを破棄)、2 = 緩やか (ソースアドレスがいずれのインターフェイス経由でも到達不能な場合のみ破棄)。 > 警告 これを |
net.ipv4.conf.default.rp_filter | 0 | 新しく追加された NIC に適用されるリバースパスフィルタリング。net.ipv4.conf.all.rp_filter と同じ有効値と警告が適用されます。 |
net.ipv4.conf.default.arp_announce | 2 | 新しく追加された NIC から送信される ARP リクエストのソース IP の選択。有効値：0 = いずれかのインターフェイス上の任意のローカルアドレス、1 = 送信先と同じサブネット内のソース IP を優先、2 = アウトバウンドインターフェイスの IP を使用する必要がある (適切なアドレスが存在しない場合、ARP は送信されない)。 |
net.ipv4.conf.all.arp_announce | 2 | 現在のすべての NIC から送信される ARP リクエストのソース IP の選択。net.ipv4.conf.default.arp_announce と同じ有効値が適用されます。 |
net.ipv4.tcp_syncookies | 1 | SYN フラッド保護。有効値：0 = 無効、1 = 有効 (SYN バックログが満杯の場合のみアクティブ化)、2 = 無条件で有効 (テストのみ)。 > 重要 SYN cookie はフォールバックメカニズムであり、過負荷サーバーのソリューションではありません。ログに SYN フラッドの警告が表示されても、ソースが攻撃ではなく正当なトラフィックである場合は、代わりに |
Alibaba Cloud Linux 3 のその他の一般的なシステム構成
これらのパラメーターは、アップストリームのデフォルト値で提供されます。パフォーマンスやリソースの問題を診断する際のリファレンスとして使用してください。変更を正当化する観測データがある場合にのみ調整してください。
パフォーマンスの向上
| パラメーター | デフォルト値 | 説明 |
|---|---|---|
net.ipv4.ip_local_port_range | 32768 60999 | アウトバウンド TCP/UDP 接続用のエフェメラルポート範囲。この範囲のほとんどのポートが使用中の場合、空きポートを探すカーネルの線形検索により CPU 使用率が増加します。ポートの枯渇による高い CPU 使用率が観測された場合、または connect() 呼び出しが EADDRNOTAVAIL を返し始めた場合は、この範囲を広げてください。 |
net.ipv4.tcp_rmem | 4096 131072 6291456 | TCP ソケットごとの受信バッファーサイズ (バイト単位)：最小値、デフォルト値、最大値。デフォルト値はインスタンスタイプに依存しません。持続的な高帯域幅接続を持つ高メモリインスタンスでは、これらの値を増やしてください。 > 重要 最大値を非常に大きく設定すると、大量のメモリを消費する可能性があります。各ソケットは最大値まで使用できるため、たとえば 100 万個のソケットがそれぞれ 6 MiB を使用すると、最大 6 TiB のバッファースペースが必要になる場合があります。 |
net.ipv4.tcp_wmem | 4096 16384 4194304 | TCP ソケットごとの送信バッファーサイズ (バイト単位)：最小値、デフォルト値、最大値。net.ipv4.tcp_rmem と同じ調整ガイダンスが適用されます。 |
net.core.netdev_max_backlog | 1000 | Receive Packet Steering (RPS) およびループバックまたは veth トラフィックに使用される CPU ごとのソケットバッファー (skb) キューの最大長。高スループットのループバックまたは veth インターフェイスでパケットドロップが見られる場合は、この値を増やしてください。 |
net.core.somaxconn | 4096 | ソケットごとの listen バックログキューの最大長。NGINX のように多数の短時間接続を処理するアプリケーションでは、この値を増やしてください。調整が必要かどうかを確認するには、ss -ntl を実行し、Recv-Q (現在のバックログ) と Send-Q (ソケットのバックログ制限) を比較します。Recv-Q が Send-Q に近づいた場合は、このパラメーターを増やしてください。 |
net.core.rmem_max | 212992 | 最大受信ソケットバッファーサイズ (バイト単位)。TCP の場合、この上限はアプリケーションが setsockopt(SO_RCVBUF) を明示的に呼び出した場合にのみ適用されます。それ以外の場合、net.ipv4.tcp_rmem が制限を制御します。単一ソケットで多数の接続を持つ UDP の場合は、この値を増やしてください。 |
net.core.wmem_max | 212992 | 最大送信ソケットバッファーサイズ (バイト単位)。TCP の場合、この上限はアプリケーションが setsockopt(SO_SNDBUF) を明示的に呼び出した場合にのみ適用されます。それ以外の場合、net.ipv4.tcp_rmem が制限を制御します。 |
/sys/block/<device>/queue/nomerges | 0 | デバイスの I/O マージ動作を制御します。有効値：0 = すべてのマージタイプが有効、1 = 単純なワンショットマージのみ (複雑なマージは無効)、2 = すべてのマージが無効。ほとんどのワークロードはマージの恩恵を受けます。マージ可能なリクエストの可能性が低い純粋なランダム I/O のワークロードでは、マージのチェックに費やされる CPU サイクルを節約するために 2 に設定します。 |
/sys/block/<device>/queue/read_ahead_kb | 4096 | シーケンシャル読み取りの先読みサイズ (KB 単位)。カーネルのデフォルトは 128 KB ですが、tuned サービスはこれを 4,096 KB に増やします。シーケンシャルなワークロード (大きなファイルの読み取り、ログ処理) では、この高い値を維持するか、さらに増やします。ランダム I/O のワークロードでは、使用されないデータをプリフェッチしないように 128 KB に減らします。 |
/sys/block/<device>/queue/rq_affinity | 1 | どの CPU が I/O 完了を処理するかを制御します。 |
rq_affinity の場合、値間のトレードオフは次のとおりです：
| 値 | 動作 | 最適な用途 |
|---|---|---|
0 | 完了処理は、割り込みをトリガーした CPU で実行されます | 割り込みが多いワークロードで最小のレイテンシー |
1 | 完了処理は、サブミッターと同じソケット内の任意の CPU で実行されます (キャッシュフレンドリーですが、グループ内の最初の CPU の負荷が高くなります) | ほとんどのワークロード — デフォルトであり推奨 |
2 | 完了処理は、I/O をサブミットしたまさにその CPU で実行されます (CPU 負荷は分散されますが、1 よりも効率がわずかに低くなります) | 多くのコアを持つ高同時実行ワークロード |
| パラメーター | デフォルト値 | 説明 |
|---|---|---|
/sys/block/<device>/queue/scheduler | mq-deadline (単一キュー) または none (複数キュー) | I/O スケジューラ。Alibaba Cloud Linux 3 は mq-deadline、kyber、bfq、および none をサポートします。blk-mq レイヤーは、単一キューのデバイスには mq-deadline を、複数キューのデバイスには none を選択します。低い読み取りレイテンシーが必要なワークロードでは、kyber に切り替えてターゲットレイテンシー値を設定します。 |
/sys/kernel/mm/pagecache_limit/enabled | 0 | システム全体で ページキャッシュ制限機能を有効または無効にします。0 = 無効、1 = 有効。 > 重要 これは Alibaba Cloud Linux 3 のカスタム機能です。長期的なメンテナンスは保証されません。 |
/sys/fs/cgroup/memory/memory.pagecache_limit.enable | 0 | 特定の memcg に対して ページキャッシュ制限機能を有効または無効にします。0 = この memcg では無効、1 = 有効。 |
/sys/fs/cgroup/memory/memory.pagecache_limit.size | 0 | 現在の memcg ツリーのページキャッシュ使用量の上限 (バイト単位)。有効値：0 から現在の memcg の memory.limit_in_bytes の値まで。0 に設定すると、グローバルまたは memcg ごとのスイッチに関係なく、この memcg の ページキャッシュ制限機能が無効になります。ゼロ以外の値は、memcg ツリーのページキャッシュ使用量の上限を設定します。 |
ネットワークセキュリティ
| パラメーター | デフォルト値 | 説明 |
|---|---|---|
net.ipv4.conf.all.arp_ignore | 0 | 現在のすべての NIC の ARP 応答動作を制御します。有効値：0 = どの NIC がリクエストを受信したかに関わらず、ループバックアドレスを含む任意のローカル IP への ARP リクエストに応答、1 = ターゲット IP が受信 NIC に設定されている場合にのみ応答、2 = ターゲット IP が受信 NIC にあり、かつソース IP が同じサブネット内にある場合にのみ応答。たとえば、eth0 が eth1 の IP に対する ARP リクエストを受信した場合：値が 0 の場合、eth0 は応答します。値が 1 または 2 の場合、応答しません。 |
net.ipv4.conf.default.arp_ignore | 0 | 新しく追加された NIC の ARP 応答動作。net.ipv4.conf.all.arp_ignore と同じ有効値と動作が適用されます。 |
net.ipv4.ip_forward | 0 | IPv4 パケット転送を有効または無効にします。0 = 無効、1 = 有効。インスタンスがルーターまたは NAT ゲートウェイとして機能する場合にこれを有効にします。 |
リソース使用率
| パラメーター | デフォルト値 | 説明 |
|---|---|---|
net.ipv4.tcp_fin_timeout | 60 | ローカル側がクローズを開始した後、TCP 接続が FIN_WAIT2 状態に留まる時間 (秒単位)。デフォルトの 60 秒はほとんどのワークロードに適しています。多数の FIN_WAIT2 接続が観測された場合 (netstat -ant | grep FIN_WAIT2 | wc -l で確認)、ポートをより速く解放するためにこの値を減らしてください。詳細については、「Linux ECS インスタンスで FIN_WAIT2 状態の TCP 接続が多数存在するのはなぜですか？ |
net.ipv4.tcp_tw_reuse | 2 | 新しい接続のために TIME_WAIT ソケットの再利用を制御します。0 = 無効、1 = グローバルに有効、2 = ループバックのみで有効。 |
net.ipv4.tcp_keepalive_time | 7200 | TCP キープアライブが有効な場合のキープアライブプローブの間隔 (秒単位)。キープアライブプローブは、アイドル状態の接続のリモート側がまだ到達可能であることを確認します。 |
システム制限
| パラメーター | デフォルト値 | 説明 |
|---|---|---|
fs.aio-max-nr | 65536 | システム全体での同時非同期 I/O (AIO) リクエストの最大数。カーネルは各 io_setup() 呼び出しの nr_events 引数を aio-nr に蓄積します。aio-nr + nr_events > aio-max-nr の場合、io_setup() は -EAGAIN を返します。Linux AIO に大きく依存するデータベースや検索ワークロードでは、この値を増やしてください。ご利用の環境に適した値を決定するために aio-nr をモニターしてください。 |
fs.file-max | ブート時に予約されたメモリに基づいて設定 | カーネルがシステム全体で許可するファイルハンドルの最大数。予約済みメモリの最大 10% をファイルハンドルに使用できます。最小値は 8,192 (NR_FILE の値) です。プロセスがシステムレベルで「too many open files」エラーで失敗する場合にのみ、この値を増やしてください。 |
fs.nr_open | 1048576 | プロセスごとのオープンファイルハンドルの最大数。ulimit -n (RLIMIT_NOFILE) によって設定されるプロセスごとの制限は、この値を超えることはできません。ulimit -n を 1,048,576 を超えて引き上げる前に、fs.nr_open を増やしてください。 |
モニタリング
| パラメーター | デフォルト値 | 説明 |
|---|---|---|
net.netfilter.nf_conntrack_max | 262144 | nf_conntrack ハッシュテーブル内のコネクション追跡エントリの最大数。4 × net.netfilter.nf_conntrack_buckets として計算されます。アプリケーションで断続的なパケット損失が発生し、カーネルログに nf_conntrack: table full, dropping packet と表示される場合は、この値を増やしてください。詳細については、「ECS インスタンス上のアプリケーションで時々パケット損失が発生し、カーネルログに「kernel: nf_conntrack: table full, dropping packet」エラーが含まれている場合はどうすればよいですか？ |
net.netfilter.nf_conntrack_tcp_timeout_time_wait | 120 | nf_conntrack が TIME_WAIT 状態の TCP 接続を追跡する時間 (秒単位)。 |
net.netfilter.nf_conntrack_tcp_timeout_established | 432000 | iptables が確立された TCP 接続を非アクティブのために閉じる前に追跡テーブルに保持する時間 (秒単位)。 |
fs.inotify.max_queued_events | 16384 | イベントがドロップされる前に inotify インスタンスにキューイングできるイベントの最大数。inotify は、ファイルとディレクトリのイベントをモニタリングするためのカーネルサブシステムです。アプリケーションがファイルイベントを大きなバッチで処理する場合を除き、デフォルトを使用してください。 |
fs.inotify.max_user_instances | 128 | ユーザーが作成できる inotify インスタンスの最大数。この制限は、暴走プロセスが多くのモニタリングインスタンスを作成して過剰なメモリを消費するのを防ぎます。アプリケーションがより多くのインスタンスを必要とする場合を除き、デフォルトを使用してください。 |
fs.inotify.max_user_watches | 8192 | ユーザーがすべての inotify インスタンスにわたって追加できるウォッチの最大数。ウォッチは、特定のファイルまたはディレクトリに対してどのイベントを報告するかを inotify に伝える (パス, イベントマスク) のペアです。アプリケーションが多数のファイルまたはディレクトリをモニタリングする場合は、この値を増やしてください。 |
/sys/block/<device>/queue/hang_threshold | 5000 | I/O ハング検出のしきい値 (ミリ秒単位)。カーネルは、この時間内に完了しない I/O 操作をハングとしてフラグ付けします。ご利用のストレージとワークロードの特性に基づいてこれを調整してください。詳細については、「ファイルシステムとブロックレイヤーでの I/O ハングの検出」をご参照ください。 > 重要 これは Alibaba Cloud Linux 3 のカスタム機能です。長期的なメンテナンスは保証されません。 |