コンテンツにスキップ 
カーネル・チューニング Linuxホスティングでは、ネットワーク、メモリ、CPU、セキュリティのsysctlパラメータを特別に調整するため、測定可能なパフォーマンス向上をもたらします。再起動することなくプロファイルをロードし、ワークロード、同時実行、I/O動作の値を調整することで、Linuxホスティングのパフォーマンスを向上させることができます。 サーバー 負荷がかかっても素早く反応し、確実に機能する。.
中心点
- sysctl 実行時のカーネルの動作を制御する
- ネットワーク 最適化する：バックログ、ソケット、TCP
- メモリ トリムスワッピング、汚れたページ
- CPU 微調整：スケジューラ、PID
- セキュリティ オーバーヘッドなしで硬化
Linuxホスティングのsysctlとは何ですか？
と一緒に sysctl カーネルをコンパイルすることなく、実行時にカーネル・パラメーターを読み込んで変更する。値は/proc/sysディレクトリにnet/ipv4/tcp_max_syn_backlogなどのファイルとして保存され、ネットワーク、メモリ、セキュリティを制御する。多くの接続を持つワークロードをホスティングする場合、直接チューニングすることで、待ち時間のピークやタイムアウトを減らすことができる。sysctl -wで一時的な変更を行い、/etc/sysctl.d/*.confに恒久的なプロファイルを書き込みます。それから、sysctl -systemですべてをロードし、dmesgとジャーナルログをチェックして、設定ミスをすぐに認識できるようにしています。.
sysctlの安全な使い方
変更を加える前に プロフィール そして、いつでもロールバックできるように、sysctl -aで実際の値を記録する。私はまず、同等の負荷のステージングVMで新しい値をテストする。その後、パラメーターを段階的に増やし、メトリクスをモニターして再度調整します。こうしてOOMキル、ソケットドロップ、散発的な再送信を防いでいる。再現可能なセットアップのために、私は/etc/sysctl.d/99-hosting.confのような別のファイルを作成し、制御された方法でそれをロードする。.
#を一時的にテストする
sudo sysctl -w net.core.somaxconn=65535
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096
#を恒久的に設定する
sudo tee /etc/sysctl.d/99-hosting.conf >/dev/null <<'EOF'
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 4096
vm.swappiness = 10
vm.dirty_ratio = 20
EOF
sudo sysctl --system
ウェブ・サーバーを伝送するネットワーク・パラメータ
同時接続が多い場合は、次のように増やす。 somaxconn, NginxやApacheのリストバックログがオーバーフローしないようにするためだ。私はnet.ipv4.tcp_max_syn_backlogを使って、ハーフオープン接続のキューを増やしている。ウェブだけのセットアップでは、私は通常net.ipv4.ip_forwardをオフのままにしておきます。リバースプロキシやゲートウェイではオンに切り替えます。ss -sとnetstat -sでバックログドロップを確認し、アクセプトキューが空になっていないかチェックする。輻輳制御をより深く追求したいのであれば、CUBICやBBRのようなアルゴリズムを評価することもできる。 TCP輻輳制御.
# 頻度の高いウェブサーバーの値の例
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.ip_forward = 0
ホスティングワークロードのためのストレージとVMのチューニング
私は下がる スワップネス を10にすると、カーネルがRAMを使用する時間が長くなり、スワップが少なくなる。vm.dirty_ratioを15～20パーセントにして、ダーティページを制限し、書き込み負荷が長いフラッシュバーストにつながらないようにしている。多くのプロセスでは、アプリケーションを理解し、そのリザーブを理解していれば、vm.overcommit_memoryを1に設定する。また、キャッシュ効果を正しく解釈できるように、ページキャッシュのヒット数とIO待ち時間も監視している。キャッシュの動作については、この ページキャッシュ.
# ストレージとVMのプロファイル
vm.swappiness = 10
vm.dirty_ratio = 20
vm.overcommit_memory = 1
CPUとスケジューラの微調整
高い同時実行性では、私は持ち上げる カーネル.pid_max 多くのワーカープロセスがIDを受け取るように。CFS クォータについては、バースト的なサービスに対して短すぎるスライスを避けるために kernel.sched_cfs_bandwidth_slice_us を調整しています。特に共有ホストでは、ランキューの長さ、コンテキストスイッチ、スティール時間をチェックしています。CPUの分離が必要な場合は、タスクセットやcgroupsを使ってサービスをコアにバインドします。より深いカーネル最適化については、以下のコンパクトな入門書がある。 カーネル性能-ガイド.
# プロセスとスケジューラのパラメータ
カーネル.pid_max = 4194304
# CFSスライスを細かくする例
kernel.sched_cfs_bandwidth_slice_us = 5000
性能を損なうことのない安全パラメータ
起動させる dmesg_restrict, を使って、権限のないユーザーがカーネルログを読めないようにしている。kernel.kptr_restrictを使って、攻撃者のエクスプロイトに役立つアドレスを隠している。ネットワーク・レベルでは、IPスプーフィングを防ぐためにrp_filterをデフォルトでオンにしている。これらの設定はほとんどパフォーマンスを犠牲にせず、ホストのハードニングを大幅に強化する。同じsysctlファイルに制御された方法でロードするので、追跡は可能だ。.
sysctlによる#ハードニング
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
高いスループットを実現する拡張ネットワーク・バッファ
トラフィックの多いホストには TCPバッファ 高速な接続がウィンドウ制限でハングしないようにするためだ。net.core.optmem_maxとnet.core.netdev_max_backlogは、短いバーストをきれいに吸収するのに役立つ。さらに値を大きくする前に、再送、cwnd展開、バッファフィルレベルを監視している。これらのステップによって、スループットが向上し、最新の10Gリンクでの待ち時間の変動が顕著に減少します。.
#拡張ネットワークバッファ
net.core.optmem_max = 81920
net.core.netdev_max_backlog = 3000
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
実践：ベースラインから測定可能な利益へ
私はすべてのチューニングを ベースライン そしてP95のレイテンシー、スループット、エラー率などの主要な数値を記録する。その後、いくつかのパラメーターを変更し、プロファイルをロードして、ab、wrk、sysbenchで再度測定する。レイテンシが低下した場合はその変化を記録し、上昇した場合は元に戻します。こうして自分のアプリケーションに対応するホスティング・プロファイルを構築する。最後に、値を恒久的なものにする前に、本番負荷の下で再度検証します。.
# 実際のステータスを保存する
sysctl -a > /root/sysctl-baseline.txt
ネットワークパラメーターを表示する
sysctl -a | grep -E 'net.core|net.ipv4'
# プロファイルをリロードする
sysctl --system
比較表：標準プロファイルとホスティング・プロファイル
以下の通りである。 テーブル は、私がよく使う実用的な開始値を示している。値はワークロード、ネットワーク、ハードウェアによって異なります。私はこの値から始めて、メトリクスをチェックし、段階的に調整します。問題があれば、デフォルトの値に戻し、少しずつ値を上げていきます。こうすることで、リスクを最小限に抑え、一貫した結果を得ることができます。.
| パラメータ | スタンダード | ホスティング・プロフィール | ベネフィット |
|---|---|---|---|
| net.core.somaxconn | 128 | 65535 | より多くのコネクション |
| net.ipv4.tcp_max_syn_backlog | 1024 | 4096 | ピークを伴う落下が少ない |
| vm.swappiness | 60 | 10 | 負荷時のスワップが少ない |
| カーネル.pid_max | 32768 | 4194304 | より多くのプロセス／ワーカーが可能 |
| vm.dirty_ratio | 30 | 20 | より均等な文章 |
よくあるミスの回避とモニタリング
使用しない 極端な値, なぜなら、タイムアウトやOOMキル、パケットロスにつながる可能性があるからだ。私は段階的に変更をテストし、それぞれに明確な指標と短い観察フェーズを設けている。重要な指標は、アクセプトキューの長さ、TCP再送、P95レイテンシ、IO待ち、スワップイン/アウトです。監視には軽量なエージェントとダッシュボードを使い、トレンドを素早く認識できるようにしています。カーネルのアップデート後は、sysctlプロファイルがまだ有効かどうかをチェックし、必要であれば再ロードする。.
持続性、順序、分布
プロファイルの再現性を確保するため、私は/etc/sysctl.dの読み込み順序を観察している：ファイルは辞書順に処理される。自分のホスティング・プロファイルが他のデフォルトより優先されるように、60-...や99-...のような接頭辞を意図的に割り当てている。ディストリビューション間の違い（Debian/Ubuntu対RHEL/Alma）は通常、パスとデフォルト値にしか影響しない。sysctl -systemは常に/etc/sysctl.conf、/etc/sysctl.d/*.conf、および該当する場合はベンダーファイルをロードする。大きなシステムアップデートの後は、sysctl -system -o（バージョンによってはドライラン）でチェックするか、ロードされた有効なコンフィギュレーションを自分のテンプレートと比較して、驚かないようにしている。.
# 例: クリーンなシーケンスを確保する
sudo ls -1 /etc/sysctl.d
10-ベンダー.conf
50-defaults.conf
99-hosting.conf #はそれ以前の全てを上書きする。
#は読み込んだ値を効果的にdiffする
sysctl -a > /ルート/sysctl-after.txt
diff -u /root/sysctl-baseline.txt /root/sysctl-after.txt | less
TCPのライフサイクルとポート管理
高負荷がかかると、短命のコネクションがたくさんできる。私は ip_local_port_range プロキシなどからの）発信接続がエフェメラル・ポート制限に引っかからないようにするためである。. tcp_fin_timeout は、ソケットがFIN-WAIT-2に残っている時間をコントロールする。意味のある キープアライブ-パラメータを使うことで、積極的にコネクションを切断することなく、デッドセッションをより速く減らすことができる。TIME_WAITは正常であり、遅延パケットから保護するものである。. tcp_tw_reuse 主にクライアントホストで役立ちますが、純粋なサーバーでは通常はオフのままです。タイムスタンプとSACKはパフォーマンスと堅牢性を向上させるので、私はオンのままにしている。.
# ポート範囲とTCPライフサイクル
net.ipv4.ip_local_port_range = 10240 65535
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5
# tcp_tw_reuse での注意: 送信クライアントの負荷にのみ有効
# net.ipv4.tcp_tw_reuse = 1
IPv6と近隣テーブルを安定に保つ
今日、多くのホストがデュアルスタック・トラフィックを運んでいる。私はARP/NDテーブルを最適化し、特にプロキシや多数のピアを持つノードで „neighbor table overflow “メッセージが発生しないようにしている。そのため gc_thresh-接続マトリックスに合わせて閾値を定義しています。不要なルートが含まれないように、ICMPv6とルーター追加オプションはサーバー用に制限したままにしている。IPv4では、ARPのガベージコレクションにも注意を払い、エントリーのエージングのタイミングは適切だが、すぐに消えてしまわないようにしている。.
#近隣テーブル: より寛大なしきい値
net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 4096
net.ipv4.neigh.default.gc_thresh3 = 8192
net.ipv6.neigh.default.gc_thresh1 = 1024
net.ipv6.neigh.default.gc_thresh2 = 4096
net.ipv6.neigh.default.gc_thresh3 = 8192
# ARP/ND エージングは控えめ
net.ipv4.neigh.default.gc_stale_time = 60
ファイルディスクリプタとバックログを一緒に考える
ボトルネックになりやすいのは ファイル記述子. .アプリケーションが何千ものソケットを保持する場合、fs.file-max（システム全体）とulimit/nofile（サービスごと）は一緒に収まる。somaxconnはリストキューを増やすが、ウェブサーバー自体がより多くのFDを開くことを許可され、アクセプトレートが十分に高い場合にのみ役立つ。そうしないと、カーネルのバックログが „大きい “にもかかわらず、人為的なボトルネックが発生します。.
# システム全体でより多くのFDを許可する
fs.file-max = 2097152
# サービス側(systemdユニットの例)
# [サービス］
# LimitNOFILE=1048576
UDP/QUICワークロードの緩和
DNS、syslog、テレメトリー、QUIC（HTTP/3）を使用する。 UDP. .ここでは、グローバルソケットバッファとUDP固有のメモリ制限をスケーリングする。大規模でバースト的なUDP負荷（テレメトリゲートウェイなど）の場合、これで受信パスのドロップを防ぐことができる。ss -u -aとnetstat -suでエラーカウンターを監視し、徐々に最大値を調整する。QUICの場合、net.core.rmem_max/wmem_maxも関係する。ユーザー空間のスタックがsetsockopt経由でこれらの制限に達することがよくあるからだ。.
# UDPバッファと制限
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.ipv4.udp_mem = 98304 131072 262144
net.ipv4.udp_rmem_min = 8192
net.ipv4.udp_wmem_min = 8192
ダーティライトバックを指定する：パーセンテージの代わりにバイト数
RAMの容量が多いシステムでは、パーセンテージ値を使用すると、突然大量のフラッシュが発生する可能性がある。そのため、私は vm.dirty_background_bytes そして vm.dirty_bytes, で絶対的な上限を定義する。これにより、特にHDDや混合ワークロードの場合、書き込み速度が安定し、レイテンシが滑らかになる。また vm.min_free_kバイト カーネルがバースト割り当てのために十分な空きメモリを持つように、適度に。.
# 例: 絶対的なダーティ制限 (バックグラウンド約 1G、ハード約 4G)
vm.dirty_background_bytes = 1073741824
vm.dirty_bytes = 4294967296
vm.min_free_kbytes = 65536
RPS/RFSおよびネットワークIRQ負荷の分散
高いPPSレートでは、1つのCPUコアがNIC-IRQでハングすることがある。私は、受信パケット・ステアリング（RPS）と、必要に応じて受信フロー・ステアリング（RFS）を使って、複数のコアにパケット処理を分散させている。グローバルでは net.core.rps_sock_flow_entries, 実際の割り当ては、sysfsを介してキューごとに行われる。これにより、CPUのホットスポットが減少し、キャッシュの局所性が向上し、レイテンシのピークが減少する。net.core.netdev_max_backlogと組み合わせることで、より堅牢なパイプラインが実現される。.
# RPSのグローバルフローエントリ
net.core.rps_sock_flow_entries = 32768
# 注：/sys/class/net//queues/rx-*/rps_cpusを介したキューごとのチューニング。
# と rps_flow_cnt を使用します。NIC とキューの数に依存します。.
コンテナ、ネームスペース、VM
コンテナには多くの ネット-価値観 名前付き ネットワーク・ネームスペースごとに適用できます。そのため、私はホストとポッド/コンテナのどちらのネットワークをカスタマイズしているかを文書化しています。Kernel.pid_maxのような値はホスト側に残ります。VMでは、どの仮想NICとオフロードがアクティブか（virtio、ENA）をチェックする。オフロードとMTUはバッファ要件とcwnd開発に強い影響を与えるからだ。NUMAを多用するベアメタルホストでは、オフロードが有効でない方が有利です。 vm.zone_reclaim_mode と意図的なCPU/IRQアフィニティ・レイアウト。.
# NUMAの副作用を避ける
vm.zone_reclaim_mode = 0
コンントラックとステートフル・ファイアウォールの概要
ホストがNAT/ファイアウォールとして動作していたり、多数のコンテナをイグレスNATでホストしていたりする場合は、次のようにスケールします。 nf_conntrack-テーブル。ハッシュテーブルが小さすぎると、テーブルスキャン時にドロップが発生し、レイテンシが高くなる。私はnstatで利用率を測定し、„予想 “と „使用中 “を比較する。NATのない純粋なウェブサーバーでは、conntrackは重要視されないか、あるいは無効化されることが多い。.
# コンントラックサイズ (アクティブに使用されている場合のみ!)
net.netfilter.nf_conntrack_max = 1048576
攻撃や異常に対する堅牢性
ボットトラフィックとスキャンの支援 tcp_syncookies および保守的なICMP/リダイレクトオプションを使用する。Syncookieは、正当なトラフィックを過度にスロットリングすることなく、SYNキューがオーバーフローした場合にハンドシェイクをセーブする。私は、ルーティングすべきでないサーバーのリダイレクトとソースルートを無効にしています。これらの堅牢化対策は軽量で、上記の保護メカニズムを補完するものです。.
# SYNフラッド防御と保守的なルーティング動作
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
測定の実践を深める定期的にチェックしていること
再現性のある結果を得るために、変更前と変更後を一貫して測定している。ネットワーク側では、ss -s、ss -ti、nstat、netstat -sを使って、キューの長さ、再送、サックの統計を見る。メモリI/O側では、vmstat、iostat、pidstatを使用して、ダーティフラッシュ、コンテキストスイッチ、CPU待ち時間を分類している。負荷テストも見ている：
- アクセプトキュー（LISTEN）とSYNキュー：ドロップとオーバーフロー
- ペーシング/接続ごとのスループットとCwndの開発
- P95/99のレイテンシーをA/B比較。
- スワップイン・アウト率とページキャッシュヒット率
- CPUごとのIRQ負荷分散とランキューの長さ
# クイックステータスチェック
ss -s
netstat -s | egrep 'listen|SYN|retran|dropped'
vmstat 1 10
pidstat -w -u -r 1 5
例：統合ホスティング・プロファイル
まず、基本値と拡張値を1つのファイルにまとめる。その後、明確な測定ポイントを設けながら、少しずつ増やしていきます。以下の値は、多忙なウェブサーバーやプロキシにとって、保守的ではあるが高性能な出発点である。.
sudo tee /etc/sysctl.d/99-hosting.conf >/dev/null <<'EOF'
# ネットワークの基本
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 4096
net.core.netdev_max_backlog = 3000
net.core.optmem_max = 81920
# TCPバッファとポート
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.ip_local_port_range = 10240 65535
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5
# UDP/QUIC
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.ipv4.udp_mem = 98304 131072 262144
net.ipv4.udp_rmem_min = 8192
net.ipv4.udp_wmem_min = 8192
#ネイバーテーブル
net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 4096
net.ipv4.neigh.default.gc_thresh3 = 8192
net.ipv6.neigh.default.gc_thresh1 = 1024
net.ipv6.neigh.default.gc_thresh2 = 4096
net.ipv6.neigh.default.gc_thresh3 = 8192
net.ipv4.neigh.default.gc_stale_time = 60
#セキュリティ
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# メモリ/VM
vm.swappiness = 10
vm.dirty_ratio = 20
vm.dirty_background_bytes = 1073741824
vm.dirty_bytes = 4294967296
vm.min_free_kbytes = 65536
vm.overcommit_memory = 1
vm.zone_reclaim_mode = 0
# CPU/プロセス
カーネル.pid_max = 4194304
kernel.sched_cfs_bandwidth_slice_us = 5000
# RPS
net.core.rps_sock_flow_entries = 32768
# FD
fs.file-max = 2097152
EOF
sudo sysctl -システム
要約：反復プロセスとしてのチューニング
ターゲット カーネル・チューニング sysctlを使うことで、ホスティングにおいて明確な効果が得られる：レスポンスタイムの短縮、より高いスループット値、一定のサービス。somaxconnやtcp_max_syn_backlogのようなネットワークの基本から始めて、swappinessやdirty_ratioでメモリの面倒を見る。それからPIDやスケジューラを最適化し、dmesg_restrict、kptr_restrict、rp_filterでホストを固める。すべての変更を測定し、文書化し、メトリクスに目を光らせる。ステップバイステップで、ワークロードを効率的に処理し、トラフィックのピークに備えてリザーブを持つプロファイルを作成しています。.
