tencent cloud

Cloud Virtual Machine

最新情報とお知らせ
製品情報
パブリックイメージの更新情報
OSの公式サポート終了計画
製品に関するお知らせ
製品概要
CVM概要
製品の強み
基本概念
リージョンとゾーン
初心者ガイド
Service Regions and Service Providers
製品の課金
課金概要
課金モデル
課金項目
課金モデルの変更
購入インスタンス
仕様変更の料金説明
料金未払いに関する説明
クイックスタート
カスタム設定によるLinuxインスタンスの購入
カスタム設定によるWindowsインスタンスの購入
ユーザーガイド
操作ガイド一覧
ご利用制限一覧
インスタンス
スポットインスタンス
リザーブドインスタンス
イメージ
ストレージ
バックアップと復元
ネットワーク
セキュリティ
パスワード/キー
監視とアラート
運用管理
便利な機能
サーバー移行
オンライン移行
オフライン移行
移行に関するご相談
トラブルシューティング
CVMインスタンスにログインできない原因や対処法
Windowsインスタンスのログインに関する障害
Linuxインスタンスのログインに関する障害
その他のインスタンスログインに関する障害
インスタンス実行時の障害
Linuxインスタンスのメモリに関する障害
ネットワーク障害
実践チュートリアル
CVMの選定ガイド
環境構築
ウェブサイトの構築
アプリケーションの構築
可視化ページの構築
ローカルファイルをCVMへアップロード
ネットワークパフォーマンステスト
その他の実践チュートリアル
API リファレンス
History
Introduction
API Category
Making API Requests
Region APIs
Instance APIs
Cloud Hosting Cluster APIs
Image APIs
Instance Launch Template APIs
Placement Group APIs
Key APIs
Security Group APIs
Network APIs
Data Types
Error Codes
セキュリティとコンプライアンス
Cloud Access Management（CAM）
ネットワーク
よくあるご質問
リージョンとアベイラビリティゾーンに関するご質問
課金クラス
インスタンスに関するご質問
ストレージに関するご質問
イメージに関するご質問
サーバー移行について
ネットワークに関するご質問
セキュリティに関するご質問
OSに関するご質問
運用と監視に関するご質問
CAMに関するご質問
NTPサービスに関するご質問
適用シナリオに関するご質問
Agreements
CVM Service Level Agreements
Red Hat Enterprise Linux Image Service Agreement
Public IP Service Level Agreement
用語集
ドキュメントCloud Virtual Machineトラブルシューティングネットワーク障害CVMネットワークアクセスでのパケットロス

CVMネットワークアクセスでのパケットロス

PDF
フォーカスモード
フォントサイズ
最終更新日: 2022-05-06 11:46:50
このテキストでは、主に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)

前の記事へ: ネットワークでのパケットロスまたは遅延が大きい次の記事へ: CVMインスタンスのIPアドレスにpingが通らない

ヘルプとサポート

この記事はお役に立ちましたか？

フィードバック