Linux の高並列性とパフォーマンス最適化の落とし穴の紹介

序文

Linux オペレーティング システムは、現在サーバーに好まれているオペレーティング システムです。Linux のデフォルトのシステム パラメータでは、Linux は高い同時実行性を十分にサポートしていません。編集者は長年 Linux でのアプリケーション開発に携わってきました。Linux システムでの高並行性に関して、編集者は落とし穴とその解決方法を熟知しています。再び落とし穴に陥らないようにするための参考となるポイントをいくつか紹介します。

Linux アプリケーション実行中に開いているファイルが多すぎる問題の分析と解決

このプロンプトが表示される理由は、プログラムによって開かれたファイル ソケット接続の数がシステム設定値を超えているためです。

各ユーザーが開くことができるファイルの最大数を確認する

ulimit -a

オープン ファイル (-n) 1024 は、各ユーザーが開くことができるファイルの最大数が 1024 であることを示します。

現在のシステム内のファイル ハンドルの最大数。これは表示のみに使用され、設定または変更することはできません。

cat /proc/sys/fs/ファイル最大

プロセスのオープンファイル制限を表示する

cat /proc/10446(pid)/limits

開いているファイルの数値方式を設定する

制限 -n 65535

この設定方法は再起動後にデフォルト値に戻ります。

永久設置方法：

vim /etc/security/limits.conf

最後に追加

* ソフトノーファイル 65535

* ハードnofile 65535

有効にするにはシステムを再起動する必要があります

この修正により、問題は効果的に解決されました。

Linux における高同時実行時の過剰な time_wait 問題の分析と解決

この現象は、同時実行性の高いシナリオでは、サーバーがアプリケーションを遅延して実行するというものです。

トラブルシューティング方法: サーバーの構成を確認します。

netstat -ant|awk '/^tcp/ {++S[$NF]} END {for(a in S) print (a,S[a])}'

time_wait エントリが数万個と多すぎることが判明しました。これは、TIME_WAIT 状態のソケットが多数あることを意味します。クライアントの同時使用率が引き続き高い場合、一部のクライアントは接続できないと表示されます。
TCP 接続ステータスの説明:

CLOSED: アクティブまたは進行中の接続はありません。 LISTEN: サーバーは着信を待機しています。 SYN_RECV: 接続要求が到着し、確認を待機しています。 SYN_SENT: アプリケーションが起動し、接続を開いています。 ESTABLISHED: 通常のデータ転送状態です。 FIN_WAIT1: アプリケーションは完了したと報告しています。 FIN_WAIT2: 相手側が解放に同意しました。 ITMED_WAIT: すべてのパケットが終了するのを待っています。 CLOSING: 両側が同時に閉じようとしています。 TIME_WAIT: 相手側が解放を開始しました。 LAST_ACK: すべてのパケットが終了するのを待っています。

TIME_WAIT が長すぎると危険

ネットワーク状態が良くない場合、アクティブ側が TIME_WAIT を待たずに、以前の接続を閉じた後、アクティブ側とパッシブ側が新しい TCP 接続を確立します。このとき、パッシブ側によって再送または遅延された FIN パケットは、新しい TCP 接続に直接影響します。
同様に、ネットワーク状態が悪く、TIME_WAIT 待機がない場合、接続が閉じられた後に新しい接続は確立されません。受動側から再送または遅延された FIN パケットを受信すると、受動側に RST パケットが返され、受動側の他のサービス接続に影響を及ぼす可能性があります。

TIME_WAIT が多すぎる問題を解決する方法の答えは次のとおりです。

カーネル ファイル /etc/sysctl.conf を編集し、次の内容を追加します。

net.ipv4.tcp_syncookies = 1 #SYN Cookie を有効にすることを示します。 SYN 待機キューがオーバーフローした場合、Cookie を有効にして処理することで、少量の SYN 攻撃を防ぐことができます。デフォルト値は 0 で、閉じていることを意味します。
net.ipv4.tcp_tw_reuse = 1 #再利用を有効にすることを示します。 TIME-WAIT ソケットを新しい TCP 接続に再利用できるようにします。デフォルト値は 0 で、閉じていることを意味します。
net.ipv4.tcp_tw_recycle = 1 #TCP 接続で TIME-WAIT ソケットの高速リサイクルをオンにすることを示します。デフォルト値は 0 で、閉じていることを意味します。
net.ipv4.tcp_fin_timeout =30#デフォルトのTIMEOUT時間を変更する

次に、/sbin/sysctl -p を実行してパラメータを有効にします。

簡単に言えば、システムの TIMEWAIT 再利用と高速リサイクルをオンにします。

Linuxのパフォーマンスのさらなる最適化

システムにすでに多数の接続があり、上記の構成のチューニング後もパフォーマンスが理想的でない場合は、使用可能な TCP ポート範囲を最適化して、サーバーの同時実行機能をさらに向上させることができます。 /etc/sysctl.conf ファイルに次の設定を追加します。

vi /etc/sysctl.conf
#キープアライブが有効な場合に TCP がキープアライブ メッセージを送信する頻度を示します。デフォルトは 2 時間ですが、20 分に変更します。
ネット.ipv4.tcp_keepalive_time = 1200 
# は、送信接続に使用されるポート範囲を示します。デフォルトは非常に小さいです: 32768 ～ 61000 ですが、1024 ～ 65000 に変更されました。
net.ipv4.ip_local_port_range = 1024 65000 
#SYN キューの長さを示します。デフォルトは 1024 です。キューの長さを 8192 に増やすと、接続を待機しているネットワーク接続の数を増やすことができます。
ネット.ipv4.tcp_max_syn_backlog = 8192 
#システムが同時に維持する TIME_WAIT ソケットの最大数を示します。この数を超えると、TIME_WAIT ソケットは直ちにクリアされ、警告メッセージが出力されます。デフォルト値は 180000 です。これを 5000 に変更します。 Apache や Nginx などのサーバーの場合、前の数行のパラメータによって TIME_WAIT ソケットの数を効果的に減らすことができますが、Squid の場合、その効果は大きくありません。このパラメータは、TIME_WAIT ソケットの最大数を制御して、Squid サーバーが多数の TIME_WAIT ソケットによってブロックされるのを防ぐことができます。
ネット.ipv4.tcp_max_tw_buckets = 5000 

Linuxカーネルパラメータの最適化手順の詳細

vim /etc/sysctl.conf

1. net.ipv4.tcp_max_syn_backlog = 65536

クライアントからの確認応答をまだ受信していない記録された接続要求の最大数。 128M を超えるメモリを搭載したシステムの場合、デフォルト値は 1024 です。128M 未満のメモリを搭載したシステムの場合、デフォルト値は 128 です。

SYN フラッド攻撃は、TCP プロトコルのハンドシェイクの欠陥を悪用し、偽の送信元 IP アドレスを偽造して、大量の TCP-SYN 半オープン接続をターゲット システムに送信し、最終的にターゲット システムのソケット キュー リソースを使い果たして、新しい接続を受け入れられなくします。この種の攻撃に対処するために、最近の Unix システムでは通常、複数の接続キュー処理を使用して、この種の攻撃をバッファリングします (解決するのではなく)。 1 つの基本キューは、通常の完全接続アプリケーション (Connect() および Accept()) を処理するために使用され、もう 1 つのキューは、半オープン接続を個別に保存するために使用されます。

このデュアル キュー処理方式を他のシステム カーネル対策 (Syn-Cookie/Cache など) と組み合わせて使用​​すると、小規模な SYN フラッド攻撃 (1000p/s 未満であることが証明されています) を効果的に軽減できます。SYN キューの長さを増やすと、接続を待機しているネットワーク接続の数を増やすことができます。通常、SYN フラッド攻撃を受ける Web サイトには多数の SYN_RECV 状態があるため、tcp_max_syn_backlog 値を増やすと、SYN 攻撃に抵抗する能力を高めることができます。

2. net.core.netdev_max_backlog = 32768

各ネットワーク インターフェイスがカーネルが処理できる速度よりも速くパケットを受信した場合、キューに送信できるパケットの最大数。

3. ネット.コア.somaxconn = 32768

システムによって開始される同時 TCP 接続の数を調整します。突然の大量の着信接続要求に対処するには、接続予約値を増やす必要がある場合があります。大きな値を使用すると、サポートされる保留中の接続の数が増え、多数の接続要求が同時に受信された場合に接続失敗の数を減らすことができます。大きなリッスン キューは、DDoS 攻撃の防止にも役立ちます。保留中のリクエストの最大数はデフォルトで 128 です。

リアルタイムカーネルパケット損失コマンドを表示します。

ネットスタット -su

場所: /proc/sys/

4. net.core.wmem_default = 8388608

このパラメータは、送信ソケット バッファ サイズのデフォルト値 (バイト単位) を指定します。

5. net.core.rmem_default = 8388608

このパラメータは、受信ソケット バッファ サイズのデフォルト値 (バイト単位) を指定します。

6. ネットコアのrmem_max = 16777216

このパラメータは、受信ソケット バッファの最大サイズ (バイト単位) を指定します。

7. ネットコアのwmem_max = 16777216

このパラメータは、送信ソケット バッファの最大サイズ (バイト単位) を指定します。

8. net.ipv4.tcp_timestamps = 0

タイムスタンプは偽造されたシーケンス番号を防ぐことができます。 1G ブロードバンド回線では、アウトオブライン値を持つ古いシーケンス番号が再度発生する可能性があります (最後に生成されたときからのものの場合)。タイムスタンプにより、カーネルはそのような「異常な」パケットを受け入れることができます。パフォーマンスを向上させるにはこれをオフにする必要があります。

9. net.ipv4.tcp_synack_retries = 2

リモート接続要求 SYN の場合、カーネルは SYN+ACK データグラムを送信して、以前の SYN 接続要求パケットの受信を確認します。これは、いわゆる 3 ウェイ ハンドシェイク メカニズムの 2 番目のステップです。これは、接続を放棄する前にカーネルが送信する SYN+ACK の数を決定します。 255 より大きくしないでください。デフォルト値は 5 で、これは約 180 秒に相当します。 (この値はtcp_syn_retriesに基づいて決定できます)

10. net.ipv4.tcp_syn_retries = 2

新しい接続の場合、カーネルは諦める前に一定数の SYN 接続要求を送信する必要があります。 255 より大きくしないでください。デフォルト値は 5 で、これは約 180 秒に相当します。 (負荷が高く、物理的な通信が良好なネットワークの場合、この値は高すぎるため、2 に変更できます。この値は送信接続のみに適用されます。受信接続の場合は、tcp_retries1 によって決定されます)

#net.ipv4.tcp_tw_len = 1

11. net.ipv4.tcp_tw_reuse = 1

再利用を有効にして、TIME-WAIT ソケットを新しい TCP 接続に再利用できるようにします。デフォルト値は 0 で、シャットダウンを示します。これは特定のサービスをすばやく再起動するのに非常に役立ちますが、再起動後にポートがすでに使用中であるというメッセージが表示されます。

12. ネット.ipv4.tcp_mem = 94500000 915000000 927000000

tcp_mem には 3 つの INTEGER 変数があります: low、pressure、high

low: TCP がこの値より少ないメモリ ページを使用する場合、TCP はメモリ圧迫がなく、メモリの解放を検討しません。 （理想的には、この値はtcp_wmemに指定された2番目の値と一致する必要があります。この2番目の値は、最大ページサイズに同時要求の最大数を掛け、ページサイズで割った値（131072*300/4096）を示します。

pressure: TCP がこの値を超えるメモリ ページを使用すると、TCP はメモリ使用量を安定させようとし、pressure モードに入ります。メモリ消費量が下限値を下回ると、pressure 状態は終了します。 （理想的には、この値はTCPが使用できる合計バッファサイズの最大値（204800*300/4096）である必要があります）

高: すべての TCP ソケットがデータグラムをキューに入れてバッファリングできるページ数。この値を超えると TCP 接続が拒否されるため、あまり控えめな値 (512000*300/4096) に設定することはお勧めできません。この場合、提供される価値は非常に大きく、予想よりも 2.5 倍多くの接続を処理できるようになり、既存の接続で 2.5 倍のデータを伝送できるようになります。

通常、これらの値はシステムメモリの量に基づいてシステムの起動時に計算されます。

13. net.ipv4.tcp_max_orphans = 3276800

システムが処理できる、どのプロセスにも所有されていない TCP ソケットの最大数。この数を超えると、どのプロセスにも属さない接続は直ちにリセットされ、警告メッセージが表示されます。この制限を設定する理由は、単純な DoS 攻撃から保護するためだけです。これに依存したり、この制限を人為的に下げたりしないでください。

14. net.ipv4.tcp_fin_timeout = 30

ソケットがローカル側によって閉じられた場合、このパラメータによって FIN-WAIT-2 状態のままになる時間が決まります。ピアがミスを犯して接続を閉じなかったり、予期せずクラッシュしたりする可能性があります。デフォルト値は 60 秒です。 2.2 カーネルの通常の値は 180 秒です。この値を設定することはできますが、マシンが低負荷の Web サーバーであっても、多数のデッド ソケットが原因でメモリ オーバーフローが発生するリスクがあることに注意してください。FIN-WAIT-2 は、消費するメモリが最大 1.5K であるため、FIN-WAIT-1 よりも危険性は低くなりますが、有効期間は長くなります。

15. net.ipv4.ip_conntrack_max = 10000

追跡される TCP 接続数のシステムの最大制限を設定します (CentOS 5.6 にはこのパラメータはありません)

また、TCP 輻輳アルゴリズムの問​​題も関係しています。以下のコマンドを使用して、このマシンが提供する輻輳アルゴリズム制御モジュールを表示できます。

sysctlnet.ipv4.tcp_available_congestion_control

いくつかのアルゴリズムの分析の詳細については、TCP 輻輳制御アルゴリズムの長所と短所、適用可能な環境、パフォーマンス分析を参照してください。たとえば、高遅延の場合は hybla を試し、中遅延の場合は htcp アルゴリズムを試すことができます。

TCP輻輳アルゴリズムをhyblaに設定する場合

#TCP輻輳アルゴリズムを設定する net.ipv4.tcp_congestion_control=hybla

カーネルバージョン 3.7.1 以降では、tcp_fastopen を有効にすることができます。

# tcp_fastopenを有効にする
ネット.ipv4.tcp_fastopen = 3

Iptables関連

必要ない場合は、iptables ファイアウォールをオフにするかアンインストールし、カーネルが iptables モジュールをロードしないようにします。これらのモジュールは同時実行パフォーマンスに影響します。

IOイベント割り当てメカニズム

Linux で高同時 TCP 接続を有効にするには、アプリケーションが適切なネットワーク I/O テクノロジと I/O イベント ディスパッチ メカニズムを使用していることを確認する必要があります。利用可能な I/O テクノロジーは、同期 I/O、非ブロッキング同期 I/O、および非同期 I/O です。 TCP の同時実行性が高い場合、同期 I/O を使用すると、各 TCP 接続の I/O に対してスレッドが作成されない限り、プログラムの動作が深刻にブロックされます。ただし、スレッドが多すぎると、システムのスレッドのスケジュール設定により、大きなオーバーヘッドが発生します。したがって、TCP の同時実行性が高い場合は、同期 I/O を使用することはお勧めできません。この場合は、非ブロッキング同期 I/O または非同期 I/O の使用を検討してください。非ブロッキング同期 I/O テクニックには、select()、poll()、epoll などのメカニズムの使用が含まれます。非同期 I/O の技術は AIO を使用することです。

I/O イベントディスパッチメカニズムの観点からは、サポートされる同時接続数が制限されている (通常は 1024 以内) ため、select() を使用することは不適切です。パフォーマンスを考慮すると、poll() も適していません。TCP 同時実行数の増加をサポートできますが、「ポーリング」メカニズムを使用します。同時実行数が多いと、動作効率が非常に低くなり、I/O イベントの分散が不均一になり、一部の TCP 接続で I/O が「不足」する可能性があります。 epoll または AIO を使用すると、このような問題は発生しません (初期の Linux カーネルの AIO テクノロジは、I/O 要求ごとにカーネル内にスレッドを作成することで実装されていました。この実装メカニズムは、実際には、同時実行性の高い TCP 接続の場合に使用すると、深刻なパフォーマンス上の問題が生じます。ただし、最新の Linux カーネルでは、AIO の実装が改善されています)。

まとめ

要約すると、高同時 TCP 接続をサポートする Linux アプリケーションを開発する場合、同時 TCP 接続で I/O 制御を実装するために epoll または AIO テクノロジを使用するようにしてください。これにより、高同時 TCP 接続に対するプログラムのサポートを改善するための効果的な I/O 保証が提供されます。

上記の最適化構成を実行すると、サーバーの TCP 同時処理能力が大幅に向上します。上記の構成は参考用です。実稼働環境で使用する場合は、ご自身の開発システム展開の実情に合わせて調整・観察してください。

Linux の高同時実行性とパフォーマンス最適化の落とし穴に関するこの記事はこれで終わりです。Linux の高同時実行性とパフォーマンス最適化に関する関連コンテンツについては、123WORDPRESS.COM で以前の記事を検索するか、以下の関連記事を引き続き参照してください。皆様が今後も 123WORDPRESS.COM を応援していただければ幸いです。