Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| en:dpi:faq:dpi_functionality:admin_faq:start [2019/10/25 13:30] – ↷ Page moved from en:dpi:dpi_components:platform:dpi_admin:admin_faq:start to en:dpi:faq:dpi_functionality:admin_faq:start lexx26 | en:dpi:faq:dpi_functionality:admin_faq:start [2024/07/29 12:36] (current) – removed elena.krasnobryzh | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== 3 FAQ ====== | ||
| - | {{indexmenu_n> | ||
| - | * How to check the curent release (ССС)? | ||
| - | fastdpi -re | ||
| - | |||
| - | * How to check the curen version? | ||
| - | |||
| - | fastdpi -ve | ||
| - | |||
| - | * How to roll back to a previous verion? | ||
| - | |||
| - | rollback example, from 2.7 to 2.6 version: | ||
| - | yum downgrade fastdpi-2.6 | ||
| - | |||
| - | * There is an error in the log: "error loading DSCP settings, res=-4" | ||
| - | |||
| - | * [[..: | ||
| - | |||
| - | * [[admin_faq_fdpi_ctrl_reqs| Commands aren't always processed and the following error is displayed, "ERROR : Can't connect to 127.0.0.1: | ||
| - | Autodetected fastdpi params : dev=' | ||
| - | connecting 127.0.0.1: | ||
| - | |||
| - | * [[http:// | ||
| - | |||
| - | * How to check CPU core usage between available CPU cores | ||
| - | |||
| - | In order to view the CPU usage between available CPU cores, please launch the " | ||
| - | To get the CPU usage of a fastdpi' | ||
| - | ps -p `pidof fastdpi` H -o %cpu, | ||
| - | Example output: | ||
| - | %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 | ||
| - | The dpi tasks are allocated to PSR cores in order to avoid interference with each other: | ||
| - | wrk thread is responsible for the network packet data analysis | ||
| - | rx thread is responsible for the data transfer over the network ports | ||
| - | the rest threads handle application and auxiliary tasks | ||
| - | | ||
| - | and may cause peak CPU loads, so they are set to run at specific core. | ||
| - | |||
| - | * Got an error in fastdpi_alert.log, | ||
| - | |||
| - | This error means, that fragmented packet cann't be reassembled. Usually it indicates a DDoS attack. | ||
| - | You can just ignore it. The " | ||
| - | |||
| - | * Got an error in fastdpi_alert.log, | ||
| - | |||
| - | DPI preallocates resourses before it gets started according to the given subscribers number by default. | ||
| - | Эit is adjusted by the " | ||
| - | So to increase the number of subscribers to 500000 " | ||
| - | mem_ip_metadata_recs=500000 | ||
| - | DPI restart is needed: | ||
| - | service fastdpi restart | ||
| - | |||
| - | * What files are suggested to be archived? | ||
| - | |||
| - | cp / | ||
| - | cp /etc/dpi / | ||
| - | mdb_copy /var/db/dpi / | ||
| - | |||
| - | * ipmi consume 100% CPU, so it disturb dpi operation | ||
| - | |||
| - | echo 100 > / | ||
| - | To make your changes persistent (to avoid this setting reset after the next server restart), you need to add the above command to the / | ||