The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Решение проблемы с потерей пакетов в tcpdump в Linux
При записи пакетов используя tcpdump на больших скоростях возможна потеря пакетов.

Для 1 гигабита помогли такие изменения в /etc/sysctl.conf:

   net.core.rmem_default = 33554432
   net.core.rmem_max = 33554432
   net.core.netdev_max_backlog = 16384
 
20.02.2009 , Автор: Kirill Korinsky , Источник: http://catap.ru/blog/2009/02/19/kar...
Ключи: tcpdump, linux, sysctl
Раздел:    Корень / Администратору / Система / Linux специфика / Оптимизация и тюнинг в Linux

Обсуждение [ RSS ]
  • 1.1, pavlinux (ok), 02:48, 22/02/2009 [ответить]  
  • +/
    Надо юзать libpcap с поддержкой MMAP или Device pooling

    http://public.lanl.gov/cpw/
    http://labs.ee.psu.edu/faculty/kesidis/EMIST/TCPDUMP%20subsampling% (118Kb PDF)

    Improving Passive Packet Capture: Beyond Device Polling - http://luca.ntop.org/Ring.pdf
    High-Speed Dynamic Packet Filtering - http://luca.ntop.org/Blooms.pdf
    Как настроить PF_RING в линухе - http://www.ntop.org/PF_RING.html


    libpcap + PF_RING - svn co https://svn.ntop.org/svn/ntop/trunk/PF_RING


     
  • 1.2, zerot (??), 12:43, 24/02/2009 [ответить]  
  • +/
    про патченный вариант не скажу ничего, а вот стандартных пакеты теряет лихо ... как и ULOG. По моим экспериментам потери на чистом pcap доходили до 20% под нагрузкой, у ULOG - до 60% !!!

    Что не теряет пакеты - libipq Но может замедлять работу ... и требует повозиться с настройкой

     
     
  • 2.3, Аноним (-), 12:49, 24/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Из-за потерь приходится выкручиваться, переводить детализированные данные в процентное отношение, относительно суммы. Затем брать тарфик посчитанный на интерфейсе и уже к нему применять посчитанные проценты для получения конечных данных. Так как теряются пакеты равномерно и только в пиках, то погрешность получается вполне допустимой.
     
     
  • 3.4, pavlinux (ok), 00:48, 25/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Из-за потерь приходится выкручиваться, переводить детализированные данные в процентное отношение, относительно суммы.
    >Затем брать тарфик посчитанный на интерфейсе и уже к нему применять
    >посчитанные проценты для получения конечных данных. Так как теряются пакеты равномерно
    >и только в пиках, то погрешность получается вполне допустимой.

    Попрбуйте патченый pcap - результаты удивят, как никак, а чувак из Los Alamos National Laboratory - а там ламеров уж точно не держат :)


     
  • 2.5, Василий (??), 17:15, 26/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    ulog пакеты не теряет.

    Точка.

    Лечите кривые руки.

     
     
  • 3.6, zerot (ok), 22:16, 23/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    независимый опыт нескольких специалистов в UNIX со стажем более 15 лет каждого (в т.ч. мой) говорит, что пакеты под нагрузкой теряются. Результат поддаётся моделированию и обладает повторяемостью - разворачиваете ULOG (с журналированием всего траффика) на относительно слабой машине, например celeron 1700, копируете несколько файлов по несколько гигабайт и получаете такую вот картинку - до 60% потерь в статистике при корректно переданном файле

    из тюнинга пробовались - варианты вывода (больше потери при запись напрямую в базу, меньше - в файл, ограничение учитываемой порции данных не всем пакетом, а достаточной для выборки интересующих данных начальным куском, игрались с размерами кэшей)

    допускаю, что где-то что-то есть в виде тайных знаний или best practice, но на текущий момент результат таков, как я описал. Да, на нагрузке сети до 10мбит траффик не теряется

     
     
  • 4.7, emp (??), 20:29, 24/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >независимый опыт нескольких специалистов в UNIX со стажем более 15 лет каждого (в т.ч. мой) говорит, что пакеты под нагрузкой теряются.

    попробуйте -j ULOG --ulog-cprange 100 --ulog-qthreshold 30

     
     
  • 5.8, zerot (ok), 14:19, 28/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >>независимый опыт нескольких специалистов в UNIX со стажем более 15 лет каждого (в т.ч. мой) говорит, что пакеты под нагрузкой теряются.
    >
    >попробуйте -j ULOG --ulog-cprange 100 --ulog-qthreshold 30

    Это все, что вы знаете в части тюнинга ULOG ? Ну, во первых cprange может быть и меньше гораздо (достаточно, чтобы влезали заголовки IP и TCP/UDP), если вы не анализируете тунели, а очередь можно сделать и побольше. Да, это несколько снижает потери ... Конфигурации, похожие на ваши используются в моих решениях давно (года 4 точно), но этого, к сожалению, явно мало - траффик таки теряется. Так что решение - под конкретные условия

     
  • 3.9, zerot (ok), 00:21, 23/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Дабы осталось сохраненным нужно отметить

    >ulog пакеты не теряет.

    полностью согласен. Как технология - не теряет. А вот как конкретное решение - реализация с конкретным демоном статистики ulogd, предлагаемым именно на сайте www.netfilter.ru - траффик вполне теряется, как я и описывал выше

     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру