Это старая версия документа!
1 Вопросы администрирования
- как узнать текущий релиз (ССС)?
fastdpi -re
- как узнать текущую версию?
fastdpi -ve
- как откатиться на предыдущую версию?
пример отката с 2.7 версии на 2.6: yum downgrade fastdpi-2.6
- В логе нашел ошибку "error loading DSCP settings, res=-4"
Ошибка: выводится из-за отсутствия dscp по автономным системам. Можно проигнорировать.
- Как посмотреть загрузку по ядрам и почему они загружены неравномерно
Для просмотра загрузки процессора по ядрам в утилите top нажмите 1 Для просмотра загрузки по задачам dpi выполните команду ps -p `pidof fastdpi` H -o %cpu,lwp,pri,psr,comm Пример вывода: %CPU LWP PRI PSR COMMAND 0.0 23141 41 0 fastdpi_main 0.0 23146 41 0 fastdpi_dl 0.3 23147 41 0 fastdpi_ctrl 35.8 23148 41 0 fastdpi_ajb 32.7 23152 41 1 fastdpi_rx_1 34.1 23165 41 2 fastdpi_wrk0 34.1 23170 41 3 fastdpi_wrk1 В dpi задачи COMMAND функционально разделены по ядрам PSR, чтобы не мешать работе друг друга: потоки wrk выполняют анализ данных в сетевых пакетах поток rx ответственен за транзит данных между сетевыми портами остальные потоки выполняют прикладные и вспомогательные задачи (генерация netflow, прием управляющих команд, загрузка списков, запись pcap и т.п.) и могут создавать пиковые нагрузки на CPU, поэтому вынесены на отдельное ядро
- Получили ошибку в fastdpi_alert.log, что делать ?: [CRITICAL][2017/10/06-16:36:44:616019][0x7fdb297ac700] metadata_storage : Can't allocate memory [repeat 1], cntr=188889, allocated=188889
Данная ошибка означает, что не удалось собрать пакет из фрагментов. Обычно является признаком ddos, можно просто игнорировать. Уровень критикал для этого сообщения ошибочен, поставим в сл.версиях warning.
- Получили ошибку в fastdpi_alert.log, что делать ? [CRITICAL][2017/10/06-16:36:44:616019][0x7fdb297ac700] metadata_storage : Can't allocate memory [repeat 1], cntr=188889, allocated=188889
в DPI все предварительно аллоцировано, по умолчанию на данное к-во абонентов. Это регулируется параметром в конфигурации, mem_ip_metadata_recs. Например для увеличения до 500000 абонентов поставьте в конфигурации /etc/dpi/fastdpi.conf: mem_ip_metadata_recs=500000 потребуется рестарт service fastdpi restart
- Какие файлы рекомендуете архивировать ?
cp /etc/pf_ring/ /BACKUPDIR/pf_ring cp /etc/dpi /BACKUPDIR/etc/ mdb_copy /var/db/dpi /BACKUPDIR/db/ (с mdb_copy можно делать бекап при работающем fastdpi)
- ipmi ест 100% cpu, мешает работе dpi
echo 100 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us чтобы настройка не потерялась при перезагрузке сервера эту команду можно добавить в /etc/rc.local
- Ошибка в алерт логе [ERROR ] bpm : thread #1 - does not change self-monitoring counters, и dpi рестартовал и образовалась корка (или перешел в bypass)
dpi в процессе работы производит самодиагностику и если один рабочих потоков завис и больше не может проводить обработку трафика, то dpi детектирует это состояние и перезапускается с генерацией корки по сигналу Abort Важно: trace и dbg настройки в fastdpi.conf предназначены для диагностики и отладки, а не для постоянной работы, в частности: если запись на диск заблокирована другим процессом (например ротацией логов, которая обычно происходит в период с 3 до 4 утра ), то при включенной трассировке может произойти блокировка рабочего потока на записи в диагностический (slave) лог и переход dpi в bypass или его рестарт, поэтому после завершения диагностики не забудьте эти настройки отключить. Проблема проявляется только на некоторых серверах и если ваш сервер попал в это число, то рекомендуем изменение стандартного дискового планировщика на deadline:
echo deadline > /sys/block/sda/queue/scheduler echo deadline > /sys/block/sdb/queue/scheduler
- почему в процессе работы растет память, потребляемая процессом
dpi выделяет память статически: при старте процесса и в момент создания некоторых профилей услуг (таких как NAT, черные и белые списки), в процессе работы дополнительная память не выделяется почему же тогда растет потребление? ОС Linux различает резидентную (обозначена в top как RES) и виртуальную (обозначена в top VIRT) память процесса, особенность в том, что пока память не инициализирована (фактически инициализирована нулем), то она не записывается linux в резидентную и перемещается туда по мере ее инициализации Настройкой mem_preset=1 в /etc/dpi/fastdpi.conf можно указать, чтобы dpi инициализировал всю выделенную память (точнее почти всю), тогда размер резидентной части не будет расти по мере работы, но этот вариант замедляет старт и хорош когда физической оперативной памяти достаточно, поэтому лучше просто учитывать этот фактор и следить отдельно за расходом виртуальной памяти (VIRT) и резидентной (RES).
- можете подсказать, на одном из скатов много зомби процессов с именами wd_*, только рестарт поможет?\
166206 ? Z 0:00 \_ [wd_fastdpi.sh] <defunct> 166219 ? Z 0:00 \_ [wd_fastpcrf.sh] <defunct>
достаточно перезапустить watchdog service watchdog restart