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

Множество сброшенных пакетов при tcpdumping на занятом интерфейсе

Мой вызов

Мне нужно выполнить 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 на диск. Это только уменьшило количество очень немного, но достаточно, чтобы быть заметным - даже несмотря на то, что все тесты и тесты производительности диска показывают, что диск не должен быть узким местом. Думаю, здесь очень важно время доступа.

Отключение гиперпоточности также сделало больше, чем вы думали.