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

Я проверил свой сервер с помощью python-порта Mechanize - Multi-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 Мб и папку на моем веб-сайте. Не было ни передачи, ни какой-либо заметной задержки. Я не уверен, есть ли более профессиональные способы определить последовательность передачи по FTP / SCP.

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

  • 3 vcores 1.5 ГГц
  • 2048 МБ оперативной памяти (гарантировано, без динамического оперативной памяти)
  • Пропускная способность 100 мбит
  • сентос 6,5 32бит
  • apache 2.2.15

1 ответ

Хорошее место для начала - инструмент наподобие netperf. Google, чтобы найти его

  • Запустите двоичный файл сетевого сервера на вашем хосте
  • С вашего клиента запустите 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

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

Другие вопросы по тегам