Статьи

Измерение влияния tcpdump на очень занятые хосты

Ноябрь 24, 2017

[Эта статья была написана Джервином Реалом]

Несколько лет назад Дева писал о том, как использовать tcpdump на очень загруженных хостах. Этот пост  вызвал у меня интерес к изучению того, как измерить влияние tcpdump на очень загруженных хостах. В этом посте я хотел подчеркнуть, какое влияние на самом деле это имеет, и какие варианты у вас есть, чтобы повысить эффективность сбора запросов.

Некоторые вещи, которые вам нужно знать:

  • Тест представляет собой рабочую нагрузку sysbench только для чтения, 8 таблиц, 8 потоков, 1000000 строк каждая с 16 ГБ пула буферов. Набор данных полностью в памяти.
  • sysbench запускается на том же хосте, при соединении 1 Гбит / с, sysbench может насыщать сеть и, следовательно, влиять на мой сетевой тест с помощью netcat, поэтому я решил работать локально.
  • Есть 13 тестов, по 5 минут каждый с интервалом в 1 минуту, в зависимости от того, как записывается файл дампа.
    • Первый из них в качестве базового — журнал медленных запросов MySQL.
A: mysql -e 'set global long_query_time=0, slow_query_log=1; select sleep(300); set global long_query_time=1, slow_query_log=0;'
Second group is tcpdump with -w option, which means tcpdump itself is writing to the capture file.
B: $DUMPCMD -i any -G 300 -W 1 -Z root -w tcpdump.pcap port 3306
C: $DUMPCMD -i any -G 300 -W 1 -Z root -w tcpdump.pcap 'port 3306 and tcp[1] & 7 == 2 and tcp[3] & 7 == 2'
D: $DUMPCMD -i any -G 300 -W 1 -Z root -w tcpdump.pcap 'port 3306 and ( tcp[1] & 7 == 2 or tcp[3] & 7 == 2 )'
Third group, is using “packet-buffered” (-U option) to see if there will be improvement on response time.
E: $DUMPCMD -i any -G 300 -W 1 -Z root -U -w tcpdump.pcap port 3306
F: $DUMPCMD -i any -G 300 -W 1 -Z root -U -w tcpdump.pcap 'port 3306 and tcp[1] & 7 == 2 and tcp[3] & 7 == 2'
G: $DUMPCMD -i any -G 300 -W 1 -Z root -U -w tcpdump.pcap 'port 3306 and ( tcp[1] & 7 == 2 or tcp[3] & 7 == 2 )'
Next streams the backup to a remote location via netcat.
H: $DUMPCMD -i any -G 300 -W 1 -Z root -w - port 3306 | nc remote_ip 33061
I: $DUMPCMD -i any -G 300 -W 1 -Z root -U -w - port 3306 | nc remote_ip 33062
J: $DUMPCMD -i any -G 300 -W 1 -Z root -U -w - 'port 3306 and tcp[1] & 7 == 2 and tcp[3] & 7 == 2' | nc remote_ip 33063
The last group, the one most of us are probably accustomed with is piping the dumped packets to file.
K: timeout -s KILL 300 $DUMPCMD -i any port 3306 > tcpdump.pcap
L: timeout -s KILL 300 $DUMPCMD -i any 'port 3306 and tcp[1] & 7 == 2 and tcp[3] & 7 == 2' > tcpdump.pcap
M: timeout -s KILL 300 $DUMPCMD -i any 'port 3306 and ( tcp[1] & 7 == 2 or tcp[3] & 7 == 2 )' > tcpdump.pcap
$DUMPCMD  is defined as tcpdump -s 65535 -x -nn -q -tttt
  • В каждой группе есть варианты AND и OR в фильтрации портов. Я хотел посмотреть, сколько дополнительных выражений влияют на порт. И, как вы увидите ниже, они не оказывают существенного влияния на производительность, но на количество захваченных запросов.

Я собрал данные sysbench во время теста и пометил каждый тест для удобства сравнения на графиках.

Sysbench_TPS-легендаSysbench_Response_Time-legened


Конечно, я также сравнил размер получаемого захвата tcpdump и общее количество запросов, выявленных при запуске через pt-query-digest.
PCAP-Size-н-запросов-Count

Результаты

  • Мы видим, что передача данных pcap (K, L, M) в виде декодированных пакетов имеет значительные издержки с точки зрения количества захваченных запросов, времени ответа и завершенных запросов чтения.
  • При использовании медленного журнала время отклика возрастает примерно на 30%, а пропускная способность падает почти на 20%, но при этом регистрируется наибольшее количество запросов.
  • Запись перехваченных пакетов непосредственно в двоичный файл с использованием параметра -w имеет наименьшие накладные расходы во время ответа, около 10%. Пропускная способность падает в зависимости от степени фильтрации, хотя в то время как операционная система очищает кэш страниц, также происходят заметные задержки. Этот побочный эффект приводит к тому, что sysbench падает до 0 операций чтения или даже достигает времени отклика в несколько секунд!
  • Потоковая передача пакетов на работающий удаленный сервер с точки зрения пропускной способности сети, производительности ввода-вывода в сочетании с опцией -w для захвата двоичных данных приводит к дополнительным расходам времени отклика на 20-25%, снижению пропускной способности на 10-15%, без задержек и количества запросов, записанных как близко к медленному журналу запросов.

Резюме

Используйте параметр tcpdump -w во всех случаях и декодируйте позже. Если вы ищете общий вид ВСЕХ ваших запросов, потоковая передача данных tcpdump также является идеальной. Если у вас низкая пропускная способность, т. Е. 100 Мбит / с, этого может быть недостаточно, поскольку 5 минут двоичных данных tcpdump создают 31 ГБ файла. Это требование 105MBps! В этом случае рассмотрите возможность записи в отдельный раздел с достаточным количеством операций ввода-вывода.

Если вы используете Percona Server или MariaDB и хотите захватить только часть вашей рабочей нагрузки, например, сканирование таблиц, временную таблицу на диске или скорость, ограничивающую сбор, расширенная возможность ведения журнала медленных запросов в этих версиях также является отличным способом получения данные вам нужны.

40
Share: