tencent cloud

PrevNext

フィードバック

キーワードで検索してください

Recent Pages

ドキュメント
Cloud Virtual Machine
    ドキュメント
    Download PDF

    CVMネットワークアクセスパケット損失

    最終更新日:2022-05-06 11:46:50
    PDFファイルをダウンロード
      このテキストでは、主にCVMアクセスパケット損失の問題を引き起こす可能性のある主な理由と、対応するトラブルシューティングと対処方法を紹介します。

      考えられる原因

      CVMネットワークアクセスパケット損失の問題について考えられる理由は次のとおりです：
      速度制限のトリガーによるTCP パケット損失
      速度制限のトリガーによるUDP パケット損失
      ソフトウェア割り込みのトリガーによるパケット損失
      UDP 送信バッファがフル
      UDP 受信バッファがフル
      TCP すべての接続キューがフル
      TCP リクエストのオーバーフロー
      接続数が上限に到達
      iptables policy 関連ルールの設定

      前提条件

      問題を特定し対処する前にインスタンスにログインする必要があります。詳細は、 Linuxインスタンスにログイン および Windowsインスタンスにログイン をご参照ください。

      トラブルシューティング

      速度制限のトリガーによるTCP パケット損失

      CVMインスタンスには複数の仕様があり、仕様ごとにネットワーク性能が異なります。インスタンスの帯域幅やパケットがインスタンス仕様に対応する基準を超過した場合、プラットフォーム側の速度制限がトリガーされ、パケット損失を引き起こすことがあります。トラブルシューティングと対処手順は次のとおりです：
      1. インスタンスの帯域幅とパケットを確認します。 Linux インスタンスでは、sar -n DEV 2 コマンドを実行して帯域幅とパケットを確認することができます。rxpck/sとtxpck/s 指標は送受信パケット、rxkB/sとtxkB/s 指標は送受信帯域幅です。
      2. 取得した帯域幅とパケットデータを使用して インスタンス仕様 を比較し、インスタンス仕様の性能ボトルネックに達していないかどうかを確認します。
      ボトルネックに達している場合は、インスタンス仕様をアップグレードするか、または業務量を調整する必要があります。
      インスタンス仕様の性能ボトルネックに達していない場合は、チケットを提出 し、問題をさらに特定し対処することができます。

      速度制限のトリガーによるUDP パケット損失

      速度制限のトリガーによるTCP パケット損失 手順を参考に、インスタンス仕様の性能ボトルネックによるパケット損失かどうかを判断します。
      ボトルネックに達している場合は、インスタンス仕様をアップグレードするか、または業務量を調整する必要があります。
      インスタンス仕様の性能ボトルネックに達していない場合は、プラットフォームのDNSリクエストに対する追加的な頻度制限が原因である可能性があります。インスタンス全体の帯域幅やパケットがインスタンス仕様の性能ボトルネックに達している場合は、DNSリクエストの速度制限がトリガーされ、UDPパケット損失が発生する可能性があります。チケットを提出 して処理を更に特定することができます。

      ソフトウェア割り込みのトリガーによるパケット損失

      オペレーティングシステムが /proc/net/softnet_statの二列目のカウント値の増加を検出した場合は、「ソフトウェア割り込みによるパケット損失」と判断することができます。インスタンスがソフトウェアの割り込みをトリガーしパケット損失が引き起こされた場合は、次の手順でトラブルシューティングを行い、対処することができます： RPSが有効化されているかどうかを確認する：
      有効化されている場合は、カーネルパラメータ net.core.netdev_max_backlogが小さすぎるとパケット損失が引き起こされることから、大きくする必要があります。カーネルパラメータの詳細情報については、 Linuxインスタンスで一般的に使用されるカーネルパラメータの説明 をご参照ください。
      有効化されていない場合は、 CPU シングルコアのソフトウェア割り込み負荷が高いことによって、データが速やかに送受信できない事象が引き起こされていないかどうかを確認します。もしそうであれば：
      RPSの有効化を選択し、ソフトウェア割り込みの割り当てをより均衡にします。
      業務プロセスがソフトウェア割り込みの不均衡を引き起こしているかどうかを確認します。

      UDP 送信バッファがフル

      インスタンスが UDP バッファ不足によりパケット損失を引き起こしている場合は、次の手順でトラブルシューティングを行い対処することができます：
      1. ss -nump コマンドを使用して UDP 送信バッファがフルかどうかを確認します。
      2. フルである場合は、カーネルパラメータ net.core.wmem_max と net.core.wmem_defaultを大きくし、UDP プログラムを再起動して有効にします。カーネルパラメータの詳細情報については、 Linux インスタンスで一般的に使用されるカーネルパラメータの説明 をご参照ください。
      3. それでもパケット損失の問題が解消されない場合は、ss -nump コマンドを使用して送信バッファが期待どおりに増大していないことを確認できます。この場合は、ビジネスコードがsetsockoptを介してSO_SNDBUFを設定しているかどうかを確認する必要があり、そうであれば、コードを変更して SO_SNDBUFを増大させてください。

      UDP 受信バッファがフル

      インスタンスが UDP バッファ不足によりパケット損失を引き起こしている場合は、次の手順で対処することができます：
      1. ss -nump コマンドを使用して UDP 受信バッファがフルかどうかを確認します。
      1. フルである場合は、カーネルパラメータ net.core.rmem_max と net.core.rmem_defaultを大きくし、UDP プログラムを再起動して有効にします。カーネルパラメータの詳細情報については、 Linux インスタンスで一般的に使用されるカーネルパラメータの説明 をご参照ください。
      2. それでもパケット損失の問題が解消されない場合は、ss -nump コマンドを使用して受信バッファが期待どおりに増大していないことを確認できます。この場合は、ビジネスコードがsetsockoptを介して SO_RCVBUFを設定しているかどうかを確認する必要があり、そうであれば、コードを変更して SO_RCVBUFを増大させてください。

      TCP すべての接続キューがフル

      TCP すべての接続キューの長さは net.core.somaxconnおよび業務プロセスが listen を呼び出す時に渡される backlog パラメータの内の小さい方の値となります。インスタンスに TCP すべての接続キューがフルであることによるパケット損失が発生した場合は、次の手順で対処することができます：
      1. カーネルパラメータ net.core.somaxconnを大きくします。カーネルパラメータの詳細情報については、Linux インスタンスで一般的に使用されるカーネルパラメータの説明 をご参照ください。
      2. 業務プロセスが backlog パラメータを渡したかどうかを確認します。渡している場合は、 backlog パラメータを相応に大きくします。

      TCP リクエストのオーバーフロー

      TCPのデータ受信時に、socket が user によってロックされている場合、データは backlog キューに送信されます。 このプロセスに失敗すると、TCPリクエストのオーバーフローが引き起こされパケット損失が発生します。 通常は、業務プログラムのパフォーマンスが正常であると想定されることから、次の方法を参照して、システムレベルからトラブルシューティングを行い対処することができます：
      業務プログラムが setsockopt を介して buffer サイズを自動的に設定しているかどうかを確認する：
      設定しており、かつその値が小さい場合は、業務プログラムを修正し、さらに大きな値を指定するか、または setsockopt を介させずにサイズを指定することができます。
      説明：
      setsockopt の値はカーネルパラメータ net.core.rmem_max と net.core.wmem_maxによって制限されます。業務プログラムを調整すると同時に、 net.core.rmem_max と net.core.wmem_maxを同期的に調整することができます。調整後に業務プログラムを再起動し、設定を有効にします。
      設定していない場合は、 カーネルパラメータ net.ipv4.tcp_mem、net.ipv4.tcp_rmemおよび net.ipv4.tcp_wmemを大きくすることで TCP socket のレベルを調整することができます。 カーネルパラメータの修正については、 Linux インスタンスで一般的に使用されるカーネルパラメータの説明 をご参照ください。

      接続数が上限に到達

      CVMインスタンスには複数の仕様があり、仕様ごとに接続数性能指標が異なります。インスタンスの接続数がインスタンス仕様に対応する基準を超過した場合、プラットフォームの速度制限がトリガーされ、パケット損失を引き起こすことがあります。対処手順は次のとおりです：
      説明：
      接続数とはホストに保存されるCVMインスタンスのセッション数であり、 TCP、UDPとICMPが含まれます。この数値はCVMインスタンスでssやnetstatコマンドを介して取得されたネットワーク接続数よりも大きくなります。
      インスタンスの接続数を確認して、 インスタンス仕様 を比較し、インスタンス仕様の性能ボトルネックに達していないかどうかを確認します。
      ボトルネックに達している場合は、インスタンス仕様をアップグレードするか、または業務量を調整する必要があります。
      インスタンス仕様の性能ボトルネックに達していない場合は、チケットを提出 して処理を更に特定することができます。

      iptables policy関連ルールの設定

      CVMのiptablesに関連ルールを設定していない場合、iptables policy関連ルールを設定するとCVMに到達したパケットがすべて破棄される可能性があります。処理手順は以下のとおりです。
      1. 以下のコマンドを実行し、iptables policy ルールを確認します。
      iptables -L | grep policy
      iptables policyルールはデフォルトではACCEPTです。INPUTチェーンpolicyがACCEPTでない場合、サーバーに到達したパケットがすべて破棄されます。例えば、以下の結果がリターンされた場合、CVMへのパケットがすべて破棄されたことを意味します。
      Chain INPUT (policy DROP)
      Chain FORWARD (policy ACCEPT)
      Chain OUTPUT (policy ACCEPT)
      2. 以下のコマンドを実行し、必要に応じて -P の後ろの値を変更します。
      iptables -P INPUT ACCEPT
      変更後、手順1 のコマンドを再度実行して確認できます。以下の結果がリターンされるはずです。
      Chain INPUT (policy ACCEPT)
      Chain FORWARD (policy ACCEPT)
      Chain OUTPUT (policy ACCEPT)
      
      お問い合わせ

      カスタマーサービスをご提供できるため、ぜひお気軽にお問い合わせくださいませ。

      お問い合わせ
      テクニカルサポート

      さらにサポートが必要な場合は、サポートチケットを送信して弊社サポートチームにお問い合わせください。24時間365日のサポートをご提供します。

      チケットを送信
      電話サポート（24 時間365日対応）
      Copyright © 2013-2024 Tencent Cloud. All Rights Reserved.
      個人情報保護方針利用規約クッキーポリシー