Различия

Показаны различия между двумя версиями страницы.

--- dpi:faq:dpi_functionality:admin_faq:start [2019/10/25 14:06] – lexx26
+++ dpi:faq:dpi_functionality:admin_faq:start [2021/02/26 08:40] (текущий) – удалено kkatanov
@@ Строка 1: / Строка 1: @@
-====== 1 Вопросы администрирования ======
-{{indexmenu_n>1}}
-  * как узнать текущий релиз (ССС)?
-  fastdpi -re
-  * как узнать текущую версию?
-  fastdpi -ve
-  * как откатиться на предыдущую версию?
-  пример отката с 2.7 версии на 2.6:
-  yum downgrade fastdpi-2.6
-  * В логе нашел ошибку "error loading DSCP settings, res=-4"\\ Ошибка: выводится из-за отсутствия dscp по автономным системам. Можно проигнорировать.
-  * [[admin_faq_fdpi_ctrl_reqs| Не всегда все команды обрабатываются и выдается ошибка ERROR : Can't connect to 127.0.0.1:29000, errcode=99 : Cannot assign requested address
-Autodetected fastdpi params : dev='lo', port=29000
-connecting 127.0.0.1:29000 ...Есть подозрение, что наш способ загрузки абонентов в скат не совсем для него хорош (мы загружаем отдельно каждого абонента, что приводит к >50000 команд при первичной инициализации, которую мы еще раз в сутки проводим на всякий случай)]]
-  * [[http://www.vasexperts.ru/upload/SCESM2СКАТ.zip|Cкрипты для миграции из SCE SM в БД СКАТ, описание внутри]]
-  * Как посмотреть загрузку по ядрам и почему они загружены неравномерно
- Для просмотра загрузки процессора по ядрам в утилите top нажмите 1
- Для просмотра загрузки по задачам dpi выполните команду
-  ps -p `pidof fastdpi` H -o %cpu,lwp,pri,psr,comm
-** Пример** вывода:
-<code bash>  %CPU   LWP PRI PSR COMMAND
-.0  23141  41   0 fastdpi_main
-.0  23146  41   0 fastdpi_dl
-.3  23147  41   0 fastdpi_ctrl
-.8 23148  41   0 fastdpi_ajb
-.7 23152  41   1 fastdpi_rx_1
-.1 23165  41   2 fastdpi_wrk0
-.1 23170  41   3 fastdpi_wrk1</code>
- В 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\\
-<note important>**Важно:** trace и dbg настройки в fastdpi.conf предназначены для диагностики и отладки, а не для постоянной работы, в частности:\\
- если запись на диск заблокирована другим процессом (например ротацией логов, которая обычно происходит в период с 3 до 4 утра ), то при включенной трассировке может произойти блокировка рабочего потока на записи в диагностический (slave) лог и переход dpi в bypass или его рестарт, поэтому после завершения диагностики не забудьте эти настройки отключить. </note>
- Проблема проявляется только на некоторых серверах и если ваш сервер попал в это число, то рекомендуем изменение стандартного дискового планировщика на deadline:
-<code bash>echo deadline > /sys/block/sda/queue/scheduler
-echo deadline > /sys/block/sdb/queue/scheduler</code>
-  * почему в процессе работы растет память, потребляемая процессом
- dpi выделяет память статически: при старте процесса и в момент создания некоторых профилей услуг (таких как NAT, черные и белые списки), в процессе работы дополнительная память не выделяется почему же тогда растет потребление?\\
- ОС Linux различает резидентную (обозначена в top как RES) и виртуальную (обозначена в top VIRT) память процесса, особенность в том, что пока память не инициализирована (фактически инициализирована нулем), то она не записывается linux в резидентную и перемещается туда по мере ее инициализации\\
- Настройкой mem_preset=1 в /etc/dpi/fastdpi.conf можно указать, чтобы dpi инициализировал всю выделенную память (точнее почти всю), тогда размер резидентной части не будет расти по мере работы, но этот вариант замедляет старт и хорош когда физической оперативной памяти достаточно, поэтому лучше просто учитывать этот фактор и следить отдельно за расходом виртуальной памяти (VIRT) и резидентной (RES).
-  * можете подсказать, на одном из скатов много зомби процессов с именами wd_*, только рестарт поможет?\
-<code bash>
-?        Z      0:00  \_ [wd_fastdpi.sh] <defunct>
-?        Z      0:00  \_ [wd_fastpcrf.sh] <defunct>
-</code>
- достаточно перезапустить watchdog
-  service watchdog restart

Аккаунт

Настройки

Различия