форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: Решение проблемы с потерей пакетов ..."		+/–
Сообщение от auto_tips (ok) on 22-Фев-09, 02:48
При записи пакетов используя tcpdump на больших скоростях возможна потеря пакетов. Для 1 гигабита помогли такие изменения в /etc/sysctl.conf:    net.core.rmem_default = 33554432    net.core.rmem_max = 33554432    net.core.netdev_max_backlog = 16384 URL: http://catap.ru/blog/2009/02/19/karma-tcpdump-i-gigabit/ Обсуждается: http://www.opennet.dev/tips/info/1956.shtml
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Решение проблемы с потерей пакетов в tcpdump в Linux"		+/–
Сообщение от pavlinux (ok) on 22-Фев-09, 02:48
Надо юзать libpcap с поддержкой MMAP или Device pooling http://public.lanl.gov/cpw/ http://labs.ee.psu.edu/faculty/kesidis/EMIST/TCPDUMP%20... (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
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Решение проблемы с потерей пакетов в tcpdump в Linux"		+/–
Сообщение от zerot (??) on 24-Фев-09, 12:43
про патченный вариант не скажу ничего, а вот стандартных пакеты теряет лихо ... как и ULOG. По моим экспериментам потери на чистом pcap доходили до 20% под нагрузкой, у ULOG - до 60% !!! Что не теряет пакеты - libipq Но может замедлять работу ... и требует повозиться с настройкой
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Решение проблемы с потерей пакетов в tcpdump в Linux"		+/–
	Сообщение от Аноним (??) on 24-Фев-09, 12:49
	Из-за потерь приходится выкручиваться, переводить детализированные данные в процентное отношение, относительно суммы. Затем брать тарфик посчитанный на интерфейсе и уже к нему применять посчитанные проценты для получения конечных данных. Так как теряются пакеты равномерно и только в пиках, то погрешность получается вполне допустимой.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "Решение проблемы с потерей пакетов в tcpdump в Linux"		+/–
	Сообщение от pavlinux (ok) on 25-Фев-09, 00:48
	>Из-за потерь приходится выкручиваться, переводить детализированные данные в процентное отношение, относительно суммы. >Затем брать тарфик посчитанный на интерфейсе и уже к нему применять >посчитанные проценты для получения конечных данных. Так как теряются пакеты равномерно >и только в пиках, то погрешность получается вполне допустимой. Попрбуйте патченый pcap - результаты удивят, как никак, а чувак из Los Alamos National Laboratory - а там ламеров уж точно не держат :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Решение проблемы с потерей пакетов в tcpdump в Linux"		+/–
	Сообщение от Василий (??) on 26-Фев-09, 17:15
	ulog пакеты не теряет. Точка. Лечите кривые руки.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Решение проблемы с потерей пакетов в tcpdump в Linux"		+/–
	Сообщение от zerot (ok) on 23-Мрт-09, 22:16
	независимый опыт нескольких специалистов в UNIX со стажем более 15 лет каждого (в т.ч. мой) говорит, что пакеты под нагрузкой теряются. Результат поддаётся моделированию и обладает повторяемостью - разворачиваете ULOG (с журналированием всего траффика) на относительно слабой машине, например celeron 1700, копируете несколько файлов по несколько гигабайт и получаете такую вот картинку - до 60% потерь в статистике при корректно переданном файле из тюнинга пробовались - варианты вывода (больше потери при запись напрямую в базу, меньше - в файл, ограничение учитываемой порции данных не всем пакетом, а достаточной для выборки интересующих данных начальным куском, игрались с размерами кэшей) допускаю, что где-то что-то есть в виде тайных знаний или best practice, но на текущий момент результат таков, как я описал. Да, на нагрузке сети до 10мбит траффик не теряется
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Решение проблемы с потерей пакетов в tcpdump в Linux"		+/–
	Сообщение от emp (??) on 24-Мрт-09, 20:29
	>независимый опыт нескольких специалистов в UNIX со стажем более 15 лет каждого (в т.ч. мой) говорит, что пакеты под нагрузкой теряются. попробуйте -j ULOG --ulog-cprange 100 --ulog-qthreshold 30
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Решение проблемы с потерей пакетов в tcpdump в Linux"		+/–
	Сообщение от zerot (ok) on 28-Мрт-09, 14:19
	>>независимый опыт нескольких специалистов в UNIX со стажем более 15 лет каждого (в т.ч. мой) говорит, что пакеты под нагрузкой теряются. > >попробуйте -j ULOG --ulog-cprange 100 --ulog-qthreshold 30 Это все, что вы знаете в части тюнинга ULOG ? Ну, во первых cprange может быть и меньше гораздо (достаточно, чтобы влезали заголовки IP и TCP/UDP), если вы не анализируете тунели, а очередь можно сделать и побольше. Да, это несколько снижает потери ... Конфигурации, похожие на ваши используются в моих решениях давно (года 4 точно), но этого, к сожалению, явно мало - траффик таки теряется. Так что решение - под конкретные условия
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Решение проблемы с потерей пакетов в tcpdump в Linux"		+/–
	Сообщение от zerot (ok) on 23-Май-09, 00:21
	Дабы осталось сохраненным нужно отметить >ulog пакеты не теряет. полностью согласен. Как технология - не теряет. А вот как конкретное решение - реализация с конкретным демоном статистики ulogd, предлагаемым именно на сайте www.netfilter.ru - траффик вполне теряется, как я и описывал выше
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]