web-dev-qa-db-ja.com

一時的に帯域幅の崩壊を分析する方法/ツール

サーバー¹をpython port of mechanize - multi-mechanize でテストしました。いくつかの非常に簡単なテストを実行しました-しかし、常に10MBからいくつかに低下しますアップロード帯域幅のkb。そして私は理由がわかりません。

3分15分でも30分でも、結果に違いはありません。以下の分析でわかるように、110秒から120秒の間に常に帯域幅がほぼゼロに低下します。私は短期間の選択をしたので、ドロップを見つけるのは簡単です。

Htopのチェックでは、特別なことは何も示されていません。コアは2〜7％で実行されています。
メモリ使用量は、常に2048mb保証メモリの約1000mb（+ -100）です。

トップをチェックすると、アップロードが10メガバイトから数キロバイトに約10秒間（110〜120秒）低下する以外に特別なことは何もありません。

すべてのcronジョブ/不要なタスクが無効になります。すべてのページ（フロント/ランダム）が利用可能です。各リクエストはhttpレスポンスコード200で応答されます。ApacheとMySQLのエラーログは空です。

私はやって学ぶ管理者なので、もっと関連性のある情報があるかどうかわかりません。ロードされたApachemodは関連していますか？私がすべての重要な事実に言及したことを望みます。

config.cfg

[global]
run_time = 180
rampup = 0
results_ts_interval = 10
progress_bar = on
console_logging = off
xml_report = off


[user_group-1]
threads = 10
script = frontpage.py

[user_group-2]
threads = 10
script = randompost.py

frontpage.py

import mechanize

class Transaction(object):
    def run(self):
        br = mechanize.Browser()
        br.set_handle_robots(False)

        resp = br.open('http://Host.domain.tld/')
        resp.read()

        assert (resp.code == 200), 'Bad Response: HTTP %s' % resp.code
        assert ('Example Web Page' in resp.get_data())

randompost.py

実際にはフロントページと同じですが、ランダムなページがあります

import mechanize
import random

pages = [
'...',
'...',
'...',
# ...
]

class Transaction(object):
    def run(self):
        br = mechanize.Browser()
        br.set_handle_robots(False)

        resp = br.open(random.choice(pages))
        resp.read()

        assert (resp.code == 200), 'Bad Response: HTTP %s' % resp.code
        assert ('Example Web Page' in resp.get_data())

elapsed time / response time (secs)elapsed time / response time (secs)elapsed time / tps




この谷の原因を絞り込むためにどのようなツール/方法を使用できますか？


更新

@linuxdevopsが述べたように、私はscpとftpでファイルをダウンロードしようとしました。私のテストには10​​MBのファイルと私のウェブサイトのフォルダが含まれていました-1-1xxkbからの多くのファイルを意味します。転送の悪用や目立ったラグはありませんでした。 FTP/SCP転送の一貫性を判断するためのより専門的な方法があるかどうかはわかりません。

¹仮想ホストの仕様

  • 3vcores1.5GHz
  • 2048 mb ram（保証付き、ダイナミックRAMなし）
  • 100メガビットの帯域幅
  • centOS 6.532ビット
  • Apache 2.2.15
apache-2.2bandwidthresponse-timebandwidth-measuring
5
Lucas

開始するのに適した場所は、netperfのようなツールを使用することです。それを見つけるためにグーグル

  • Vhostでnetserverバイナリを起動します

  • クライアントからnetperfを実行します：netperf -H <serverIP> -f M -l 240 -- -s 4194304

    • -f M（出力をMB /秒で表示）
    • -l（秒単位の長さ）
    • --（オプションは2つのダッシュの後に続きます）
    • -s（ソケットサイズ）

これは、適切なソケット/バッファサイズを見つける簡単な方法です。たとえば、Windowsのデフォルトのソケットサイズはわずか8192です。ドラッグアンドドロップを使用したコピーでは、このデフォルトのサイズが使用され、最大で約22MB /秒になります。これを64kに増やすと、100〜120 MB/sが表示されるようになります。最近のほとんどのソフトウェアでは、これを変更したり、テスト済みのスイートスポットをハードコーディングしたりできます。したがって、winscp、filezilla、またはこれらのファイル転送にユーティリティを使用している場合は、LinuxではTCPバッファ、Windowsではwinsockバッファを確認する必要があります。

Linuxの例：/etc/sysctl.conf

  • net.ipv4.tcp_rmem = 4194304 4194304 4194304
  • net.ipv4.tcp_wmem = 4194304 4194304 4194304

ウィンドウズ： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters

  • DefaultReceiveWindow = 65536
  • DefaultSendWindow = 65536

リブート

Netperfを120秒以上実行でき、トラフが表示されないが、実際のデータをディスクにコピーしても表示される場合は、ディスクのトラブルシューティングに進むことができます。さまざまなバッファ/ソケットサイズを試しても減少が見られる場合、次のステップはパケットキャプチャです。

仮想ホスト上：

  1. tcpdump -i <interface> -vvv -nn -s0 port 12865 -w /desiredDir/troughTest.cap
  2. netserver
  3. クライアントから：netperf -H <serverIP> -f M -l 300 -- -s 4194304

しばらく実行してからctrl-cを実行するか、十分なパケットがあると思われるときに強制終了します。最後に、tcpdumpをctrl-cし、/ desiredDir/troughTest.capファイルをラップトップ/ワークステーションに転送します。まだインストールしていない場合はwiresharkをインストールし、パケットを分析します。

1
Ryan Davies