Мне нужно выполнить tcpdumping большого количества данных - фактически с двух интерфейсов, оставленных в беспорядочном режиме, которые могут видеть большой трафик.
Подвести итог
Сейчас я использую tcpdump вот так:
ifconfig ethX promisc
ifconfig ethX promisc
tcpdump -n -C 1000 -z /data/compress.sh -i any -w /data/livedump/capture.pcap $FILTER
В $FILTER
содержит фильтры src / dst, так что я могу использовать -i any
. Причина этого в том, что у меня два интерфейса, и я хотел бы запускать дамп в одном потоке, а не в двух.
compress.sh
заботится о назначении tar другому ядру ЦП, сжимает данные, присваивает ему разумное имя файла и перемещает его в место архива.
Я не могу указать два интерфейса, поэтому решил использовать фильтры и дамп из any
интерфейс.
Прямо сейчас я не занимаюсь уборкой, но я планирую контролировать диск, и когда у меня останется 100 ГБ, я начну стирать самые старые файлы - это должно быть нормально.
Я вижу отброшенные пакеты. Это из дампа, который работал в течение нескольких часов и собрал примерно 250 гигабайт файлов pcap:
430083369 packets captured
430115470 packets received by filter
32057 packets dropped by kernel <-- This is my concern
Как я могу избежать потери такого количества пакетов?
Изменено значение /proc/sys/net/core/rmem_max
и /proc/sys/net/core/rmem_default
что действительно помогло - фактически оно позаботилось только о половине отброшенных пакетов.
Я также посмотрел на глоток - проблема с gulp в том, что он не поддерживает несколько интерфейсов в одном процессе, и злится, если у интерфейса нет IP-адреса. К сожалению, в моем случае это нарушает условия сделки.
Следующая проблема заключается в том, что когда трафик проходит через канал, я не могу запустить автоматическую ротацию. Получение одного огромного файла размером 10 ТБ не очень эффективно, и у меня нет машины с 10 ТБ + ОЗУ, на которой я мог бы запустить wirehark, так что этого нет.
Есть ли у вас какие-либо предложения? Может быть, даже лучший способ вообще избавиться от траффика.
tcpdump хранит входящие данные в кольцевом буфере. Если буфер переполняется до того, как tcpdump обработает его содержимое, вы потеряете пакеты.
Размер кольцевого буфера по умолчанию, вероятно, 2048 (2 МБ).
Чтобы увеличить размер буфера, добавьте -B
вариант:
tcpdump -B 4096 ...
Вам также следует попробовать использовать более быстрое дисковое хранилище.
В итоге я нашел решение, с которым можно жить. Количество отброшенных пакетов уменьшилось с 0,0047% до 0,00013% - сначала это не кажется большим, но когда мы говорим о миллионах пакетов, это довольно много.
Решение состояло из нескольких вещей. Один из них - изменить размер кольцевого буфера, как предложил Майкл Хэмптон.
Кроме того, я создал ramfs и сделал для этого live-дамп, переписал мой скрипт сжатия, чтобы позаботиться о перемещении дампов из ramfs на диск. Это только уменьшило количество очень немного, но достаточно, чтобы быть заметным - даже несмотря на то, что все тесты и тесты производительности диска показывают, что диск не должен быть узким местом. Думаю, здесь очень важно время доступа.
Отключение гиперпоточности также сделало больше, чем вы думали.