web-dev-qa-db-ja.com

高いTCP CentOSLinuxでのリセットとパケットドロップ数

私は、CiscoACEロードバランサーの背後でCentOS6上でApache2.2.15を実行し、PHP/JSベースのWebポータルにサービスを提供するWebサーバー（HPProliantおよびIBMx、Broadcom Corporation NetXtreme II BCM5 NICを使用）の小さなファームを持っています。このファームは、スプラッシュページ（そこからインデックスページに移動するため）にアクセスしようとして、毎日多くの要求を受け取ります（小さな国全体にサービスを提供します）。

私は次の問題に苦しんでいます：

  • Webへの要求は、（クライアントの観点から）応答するのにかなり「長い」時間を遅らせることがあり、まったく応答しないこともあります（Webクライアント側でのタイムアウト）。後者では、Apacheログでリクエストを見ることさえありません。

  • また、netstatが送信されるTCPリセットの量が増加していることを報告していることにも気づきました（netstat -st | grep 'resets sent'）

  • また、dropwatch -l kasは、ドロップされているパケットが多いことを示しています。

Kallsyms dbdropwatchの初期化>監視の有効化の開始...カーネル監視がアクティブ化されました。 Ctrl-Cを発行して、tcp_v4_md5_hash_skb + 248（0xffffffff8149fa08）で53滴の監視を停止します。tcp_rcv_established+ 926（0xffffffff814981b6）で26滴0xffffffff8149fa08）+ tcp_rcv_established 926（0xffffffff814981b6）tcp_v4_md5_hash_skb + 248でtcp_v4_reqsk_destructor + FA（0xffffffff814a104a）51滴（0xffffffff8149fa08）tcp_rcv_established + 926（0xffffffff814981b6）tcp_v4_reqsk_destructor + FA（0xffffffff814a104a）1滴ATで2滴の32滴で4滴の29滴tcp_v4_destroy_sock + 115でip_rcv_finish + 199（0xffffffff8147ea49）1滴（0xffffffff814a0cf5）tcp_v4_md5_hash_skb + 248に+ tcp_rcv_established 926（0xffffffff814981b6）36滴（0xffffffff8149fa08）tcp_v4_reqsk_destructor + FA（0xffffffff814a104aで2滴でtcp_v4_reqsk_destructor + FA（0xffffffff814a104a）22滴で1滴）tcp_v4_md5_hash_skb + 248で49ドロップ（0xffffffff8149fa08）29 tcp_rcv_established + 926（0xffffffff814981b6）でドロップ26 tcp_rcv_established + 926（0xffffffff814981b6）でドロップ

サーバーに記載されている症状の一部は見られませんが、RH（ Red Hat Enterprise Linuxネットワークパフォーマンスチューニングガイド ）の推奨事項に従っています。要するに：

  • NICリングバッファを最大に増やしました。
  • 私はいくつかのカーネルパラメータ（tcp_syncookies、netdev_budget、tcp_timestamps、tcp_window_scaling、tcp_rmem、dev_weight、tcp_tw_reuse ...）をいじりました（増加または変更しました）。
  • Webから抽出されたいくつかの「Apache最適化ガイド」に従ってApache構成を変更しました（Apache統計のアイドルワーカーが存在し、現在も存在している場合でも）
  • 不要なシステムサービス/デーモンを停止/無効にしました（基本的に残っているのはsshd、httpd、snmpdだけです）

上記のすべては運がありません。

すべてのNICは速度：1000Mb/sで動作しており、CPUとディスクの使用率は低く、netstatもethtoolもエラーを示していません。

他に何ができるかアイデアはありますか？

linuxapache-2.2centospacketlossreset
2
Dõùĝ Díäz

TCPリセットは、TCP接続の即時終了です。これにより、前の接続に割り当てられたリソースが解放され、システム。

rST生成の原因

確認、リセット

  1. synへの応答として送信されます。 Synフレームに応答して送信されるAckリセットは、フレームの受信を確認するために送信されますが、サーバーがそのポートでの接続を許可できないことをクライアントに通知します。 Ackの理由には、リセットがあります。

    a。接続されているノードは、クライアントノードが接続しようとしているポートをリッスンしていません。

    b。サーバーノードがそのポートで接続を完了できない理由がいくつかあります。たとえば、サーバーのリソースが不足しているため、接続を許可するために必要なリソースを割り当てることができません。

[〜＃〜] rst [〜＃〜]

  1. 接続が同期されていない状態（LISTEN、SYN-SENT、SYN-RECEIVED）にあり、着信セグメントがまだ送信されていないものを確認した場合（セグメントは受け入れられないACKを伝送します）、リセットが送信されます。

  2. 次のリセットはTCPリセットで、ネットワークフレームが応答なしで6回送信された場合（これは元のフレームとフレームの5回の再送信になります）に発生します。その結果、送信ノードは接続をリセットします。

さまざまなカーネルチューニングパラメータを使用してみたので、カーネルのtcpcookiesオプションを使用してみてください

TCP SYNcookie保護を有効にする

Edit the file /etc/sysctl.conf, run:
# vi /etc/sysctl.conf

Append the following entry:

net.ipv4.tcp_syncookies = 1

Save and close the file. To reload the change, type:
# sysctl -p

解決策はログを分析することによってのみ与えることができ、IPtablesも役立ちます

3
8zero2.ops