☰

輻輳アルゴリズムが成功したかテスト

tag-icon • tag-icon networking linux-kernel performance
輻輳アルゴリズムが成功したかテスト

特定の輻輳アルゴリズムがあなたに適しているかどうかをテストする方法は？ほとんどのアルゴリズムの代表的なワークロードを簡単に再現できないようで、この質問をします。

現在検討中の2つのことがありますが、より多くの提案を受けたいと思います。

  • 出力の「再送信されたセグメント」netstat -s

現在の私の考えは、輻輳のために一定の割合でパケットがドロップされる可能性があることです。したがって、破棄されたパケットと輻輳イベントの通知を受け取るサーバーとの間に1：1の関係がない可能性がありますが、緩い相関関係がある可能性があります。アルゴリズムに切り替えると、パケット損失が減少します。

グラフには、輻輳によって再送信されるセグメントが表示されますか、それとも損失のあるリンクに制限されていますか？もしそれが本当なら（私の考えではそうかもしれません）、状況はおそらくこれが非常に良い尺度ではないほど混乱しているでしょう。

  • TCP接続の平均寿命を測定するために使用できる指標はありますか？

私の考えでは、TCP接続が早く完了した場合（エラーの急増やパケットの削除なし）、データが短い待ち時間でプッシュされていることを示すことができます。

答え1

グラフには、輻輳によって再送信されるセグメントが表示されますか、それとも損失のあるリンクに制限されていますか？もしそれが本当なら（私の考えではそうかもしれません）、状況はおそらくこれが非常に良い尺度ではないほど混乱しているでしょう。

segments retransmittednetstat -sあなたの質問にリストされているものを含め、何らかの理由ですべてのカーネルTCP再送信を含めます。この理由には、次のものも含まれる場合があります。

  • リンクエラー
  • イーサネットスイッチの輻輳
  • Qosまたはリソースの枯渇により、ローカルホストがオフラインになりました。
  • リモートホストがオフラインになります（リモートホストのqos /リソース枯渇が原因である可能性があります）。

パフォーマンステストエンジニアは通常、これらすべての変数を処理し、適切に測定できることを確認します。最初に実行する必要があるテストの1つは、ケーブル/ネットワークが関連するパケットサイズとトラフィックレートで正しく実行されていることを確認することです。これは通常、イクシアやスピレントの機器などの特別なテスト機器を使用して行われます。

ネットワークパフォーマンス基準を設定したら、必要なテストを実行できます。ネットワークテストがきれいであっても、ホストTCPテスト中にスイッチインターフェイスのエラー/削除を監視し、結果が歪んでいないことを確認する必要があります。

輻輳条件を作成することを考えると、TCPトラフィックを実行する前に、qosクラスキューのしきい値のすぐ下にiperf UDPバックグラウンドトラフィックを意図的に生成することが役立ちます。既存のリンクを飽和させることができない場合は、NICを1GEまたは100Mに下げることも役立ちます。

これらすべてが複雑に聞こえるかもしれませんし、ある意味ではそうです。ただし、すべてのシステムコンポーネントに対する適切な注意と理解により、QoSテストは完全に可能です。

答え2

簡潔なバージョン：

@ninjaljが指摘したように、ワークロードアプリケーションは、特定の調整がワークロードのパフォーマンスに役立つかどうかについての権威のあるソースと見なすべきです。要件がレイテンシであるかシステム全体のスループットであるかによって、動作の変更がパフォーマンス要件をよりよく満たすかどうかを判断できます。

この場合、変更を行い、httpd全体の待ち時間が低下するかどうかを観察します。

具体的な例を含むより長いバージョン：

詳しく説明するため、文脈に合わせて説明します。 Apacheを見てみましょうhttpd。およびディレクティブを使用して、LogFormat要求を完了するのにかかる時間（マイクロ秒）と各要求のサイズを記録できますCustomLog。たとえば、

LogFormat "%h %m %D %b" perflog
CustomLog /var/log/httpd/performance.log perflog

次のような出力が生成されます。

xxx.xxx.28.20 GET 41140 86
xxx.xxx.28.20 GET 34468 28
xxx.xxx.28.20 GET 47612 1434
xxx.xxx.28.20 GET 54860 868
xxx.xxx.28.20 POST 97055 6283
xxx.xxx.28.20 GET 33754 53
xxx.xxx.28.20 GET 68964 8416
xxx.xxx.28.20 GET 1143827 11528
xxx.xxx.28.20 GET 38055 61
xxx.xxx.64.208 HEAD 6255 -
xxx.xxx.28.20 GET 36922 142
xxx.xxx.28.20 GET 51871 5581

私はGET次の要求にのみ興味があります。

root@xxxxxxvlp14 /tmp $ grep GET /var/log/httpd/performance.log > work.log
root@xxxxxxvlp14 /tmp $ sed -i 's/-$/0/g' work.log
root@xxxxxvlp14 /tmp $

（何らかの理由でhttpd整数0の代わりにハイフンを提供します。）

その後、プログラムで分離できます。

#!/bin/bash

totalRequests=$(cat /tmp/work.log | wc -l )

totalTime=$(awk 'BEGIN{ count=0 } {count = count + $3} END { print count }' /tmp/work.log)
averageTime=$( printf "%.2f" $(bc -l <<< "$totalTime / $totalRequests "))
minTime=$(sort -nk 3 work.log | head -1 | awk '{print $3}')
maxTime=$(sort -rnk 3 work.log | head -1 | awk '{print $3}')

totalBytes=$(awk 'BEGIN{ count=0 } {count = count + $4} END { print count }' /tmp/work.log)
minBytes=$(sort -nk 4 work.log | head -1 | awk '{print $4}')
maxBytes=$(sort -rnk 4 work.log | head -1 | awk '{print $4}')

echo "Total Requests In Sample: $totalRequests"

echo

echo "Total Time Taken: $totalTime ms (average: $averageTime ms)"
echo "Longest Request: $maxTime ms"
echo "Shortest Request: $minTime ms"

echo

echo "Total Data Moved: $totalBytes bytes"
echo "Largest Request: $maxBytes bytes"
echo "Smallest Request: $minBytes bytes"

スクリプトについて言及しないでください。効率よりも明確にするために書かれています。上記の結果は次のとおりです。

Total Requests In Sample: 207

Total Time Taken: 15138613 ms (average: 73133.40 ms)
Longest Request: 1143827 ms
Shortest Request: 1788 ms

Total Data Moved: 409825 bytes
Largest Request: 20476 bytes
Smallest Request: 0 bytes

上記は、長いサンプルを得ることがなぜ重要であるかを明らかに示しています。ただし、数字は正確です（この1分30秒の要求は、誰かが好奇心を満たすために画像/チャートを含むWord形式でレポートを生成するように要求しました）。

したがって、Apacheは通常のアクティビティの長いサンプル（おそらく1日間）を提供するように誘導し、変更し、ログを回転させ、再びログ収集を開始します（24時間待機など）。

各サービス（NFS、その他のHTTPサーバー、Samba、FTPサーバーなど）には固有の情報収集方法がありますが、通常は次の方法があります。一部時間とスループットを記録する方法。

関連情報