Назад | Перейти на главную страницу

Метод / инструменты для анализа временного падения пропускной способности

Я протестировал свой сервер с портом на Python для Mechanize - мультимеханизировать. Я провел несколько довольно простых тестов, но всегда получаю падение пропускной способности с 10 до нескольких килобайт. И я не знаю почему.


Бегу я 3,15 или 30 минут - не имеет значения. Там есть всегда полоса пропускания падает почти до нуля между 110 и 120, как вы можете видеть в приведенном ниже анализе. Я выбрал небольшой пробег, так что падение легче заметить.

Проверка htop ничего особенного не показывает, ядра бегают от 2 до 7%.
использование памяти всегда составляет около 1000 МБ (+ -100) из 2048 МБ гарантированной памяти.

Когда я проверяю iftop, нет ничего особенного, кроме падения загрузки с 10 Мбит до нескольких килобайт в течение ~ 10 секунд (110-120 с)

Все cronjobs / ненужные задачи отключены. Доступны все страницы (лицевые / случайные). На каждый запрос отвечает HTTP-код ответа 200. Журналы ошибок Apache и MySQL пусты.

Поскольку я администратор, который учится на практике, я не уверен, есть ли более актуальная информация. Актуальны ли загруженные моды apache? Надеюсь, я упомянул все важные факты.

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())




Какие инструменты / методы я могу использовать, чтобы сузить причину возникновения этого желоба?


Обновить

Как упоминал @linuxdevops, я пытался загружать файлы с помощью scp и ftp. Мои тесты включали файл размером 10 МБ и папку моего сайта - это означает, что много файлов размером от 1 до 1xx. Не было никакого отказа от передачи или какого-либо заметного отставание. Я не уверен, есть ли более профессиональные способы определения последовательность передачи FTP / SCP.

¹ спецификации vhost

Лучше всего начать с такого инструмента, как netperf. Google, чтобы найти это

  • Запустите двоичный файл netserver на своем виртуальном хосте
  • Из вашего клиента запустите netperf: netperf -H <serverIP> -f M -l 240 -- -s 4194304

    • -f M (показать вывод в МБ / с)
    • -l (длина в секундах)
    • -- (варианты указаны после двух тире)
    • -s (размер гнезда)

Это простой способ подобрать подходящий размер сокета / буфера. Например, размер сокета по умолчанию в Windows составляет всего 8192. Копия с использованием перетаскивания будет использовать этот размер по умолчанию, и вы получите максимум около 22 МБ / с. Как только вы увеличите его до 64 КБ, вы начнете видеть свои 100–120 МБ / с. Большинство программ в наши дни позволяют это изменить или жестко запрограммируют проверенные точки наилучшего восприятия. Поэтому, если вы используете winscp, или filezilla, или любую другую утилиту для передачи файлов, вам нужно будет проверить свои буферы TCP в Linux и буферы winsock в Windows.

Пример Linux: /etc/sysctl.conf

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

Windows: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters

  • DefaultReceiveWindow = 65536
  • DefaultSendWindow = 65536

перезагрузка

Если вы можете запустить netperf более 120 секунд и не видите желоба, но затем скопируете фактические данные на диск и все равно увидите их, тогда вы можете перейти к поиску и устранению неисправностей на диске. Если вы попробуете различные размеры буфера / сокета и по-прежнему увидите уменьшение, следующим шагом будет захват пакетов.

На vhost:

  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 или убейте его, когда вы думаете, что у вас достаточно пакетов. Наконец, ctrl-c ваш tcpdump, перенесите файл /desiredDir/troughTest.cap на свой ноутбук / рабочую станцию, установите wirehark, если вы еще этого не сделали, проанализируйте пакеты