Различия
Показаны различия между двумя версиями страницы.
| Предыдущая версия справа и слеваПредыдущая версияСледующая версия | Предыдущая версия | ||
| dpi:faq:dpi_functionality:admin_faq:start [2019/10/25 09:27] – ↷ Страница перемещена из dpi:dpi_components:platform:dpi_admin:admin_faq:start в dpi:faq:dpi_functionality:admin_faq:start lexx26 | dpi:faq:dpi_functionality:admin_faq:start [2021/02/26 08:40] (текущий) – удалено kkatanov | ||
|---|---|---|---|
| Строка 1: | Строка 1: | ||
| - | ====== 3 FAQ ====== | ||
| - | {{indexmenu_n> | ||
| - | * как узнать текущий релиз (ССС)? | ||
| - | fastdpi -re | ||
| - | |||
| - | * как узнать текущую версию? | ||
| - | |||
| - | fastdpi -ve | ||
| - | |||
| - | * как откатиться на предыдущую версию? | ||
| - | |||
| - | пример отката с 2.7 версии на 2.6: | ||
| - | yum downgrade fastdpi-2.6 | ||
| - | |||
| - | * В логе нашел ошибку "error loading DSCP settings, res=-4" | ||
| - | |||
| - | * [[admin_faq_fdpi_ctrl_reqs| Не всегда все команды обрабатываются и выдается ошибка ERROR : Can't connect to 127.0.0.1: | ||
| - | Autodetected fastdpi params : dev=' | ||
| - | connecting 127.0.0.1: | ||
| - | |||
| - | * [[http:// | ||
| - | |||
| - | * Как посмотреть загрузку по ядрам и почему они загружены неравномерно | ||
| - | |||
| - | Для просмотра загрузки процессора по ядрам в утилите top нажмите 1 | ||
| - | Для просмотра загрузки по задачам dpi выполните команду | ||
| - | ps -p `pidof fastdpi` H -o %cpu, | ||
| - | Пример вывода: | ||
| - | %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, чтобы не мешать работе друг друга: | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | и могут создавать пиковые нагрузки на CPU, поэтому вынесены на отдельное ядро | ||
| - | |||
| - | * Получили ошибку в fastdpi_alert.log, | ||
| - | |||
| - | | ||
| - | | ||
| - | |||
| - | * Получили ошибку в fastdpi_alert.log, | ||
| - | |||
| - | в DPI все предварительно аллоцировано, | ||
| - | Это регулируется параметром в конфигурации, | ||
| - | Например для увеличения до 500000 абонентов поставьте в конфигурации / | ||
| - | mem_ip_metadata_recs=500000 | ||
| - | потребуется рестарт | ||
| - | service fastdpi restart | ||
| - | |||
| - | * Какие файлы рекомендуете архивировать ? | ||
| - | |||
| - | cp / | ||
| - | cp /etc/dpi / | ||
| - | mdb_copy /var/db/dpi / | ||
| - | (с mdb_copy можно делать бекап при работающем fastdpi) | ||
| - | |||
| - | * ipmi ест 100% cpu, мешает работе dpi | ||
| - | |||
| - | echo 100 > / | ||
| - | чтобы настройка не потерялась при перезагрузке сервера эту команду можно добавить в / | ||
| - | |||
| - | * Ошибка в алерт логе [ERROR | ||
| - | |||
| - | dpi в процессе работы производит самодиагностику и если один рабочих потоков завис и больше не может проводить обработку трафика, | ||
| - | то dpi детектирует это состояние и перезапускается с генерацией корки по сигналу Abort | ||
| - | Важно: trace и dbg настройки в fastdpi.conf предназначены для диагностики и отладки, | ||
| - | если запись на диск заблокирована другим процессом (например ротацией логов, которая обычно происходит в период с 3 до 4 утра ), | ||
| - | то при включенной трассировке может произойти блокировка рабочего потока на записи в диагностический (slave) лог и | ||
| - | переход dpi в bypass или его рестарт, | ||
| - | Проблема проявляется только на некоторых серверах и если ваш сервер попал в это число, то | ||
| - | рекомендуем изменение стандартного дискового планировщика на deadline: | ||
| - | < | ||
| - | echo deadline > / | ||
| - | |||
| - | * почему в процессе работы растет память, | ||
| - | |||
| - | dpi выделяет память статически: | ||
| - | в процессе работы дополнительная память не выделяется | ||
| - | почему же тогда растет потребление? | ||
| - | ОС Linux различает резидентную (обозначена в top как RES) и виртуальную (обозначена в top VIRT) память процесса, | ||
| - | особенность в том, что пока память не инициализирована (фактически инициализирована нулем), | ||
| - | то она не записывается linux в резидентную и перемещается туда по мере ее инициализации | ||
| - | Настройкой mem_preset=1 в / | ||
| - | тогда размер резидентной части не будет расти по мере работы, | ||
| - | поэтому лучше просто учитывать этот фактор и следить отдельно за расходом виртуальной памяти (VIRT) и резидентной (RES). | ||
| - | |||
| - | * можете подсказать, | ||
| - | < | ||
| - | 166206 ? Z 0:00 \_ [wd_fastdpi.sh] < | ||
| - | 166219 ? Z 0:00 \_ [wd_fastpcrf.sh] < | ||
| - | </ | ||
| - | достаточно перезапустить watchdog | ||
| - | service watchdog restart | ||
| - | |||
| - | |||
| - | | ||