Метод / Инструменты для временного анализа полос с коллапсом
Я проверил свой сервер с помощью 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 секунд и не видите своего корыта, но затем скопируете фактические данные на диск и все еще видите их, тогда вы можете перейти к поиску и устранению неисправностей вашего диска. Если вы попробуете разные размеры буфера / сокета и все еще увидите уменьшение, то моим следующим шагом будет захват пакета.
На Вхосте:
tcpdump -i <interface> -vvv -nn -s0 port 12865 -w /desiredDir/troughTest.cap
netserver
- От клиента:
netperf -H <serverIP> -f M -l 300 -- -s 4194304
Дайте этому поработать какое-то время, затем нажмите Ctrl-C или убейте его, когда вы думаете, что у вас достаточно пакетов. Наконец, ctrl-c ваш tcpdump, перенесите файл /desiredDir/troughTest.cap на ваш ноутбук / рабочую станцию, установите wireshark, если вы этого еще не сделали, проанализируйте пакеты