en:dpi:faq:dpi_functionality:admin_faq:start [Документация VAS Experts]

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next 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 lexx26en:dpi:faq:dpi_functionality:admin_faq:start [2024/07/29 12:36] (current) – removed elena.krasnobryzh
Line 1: Line 1:
-====== 3 FAQ ====== 
-{{indexmenu_n>3}} 
-  * 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"\\ Error is displayed because of the lack of autonomous system dscp. It can be ignored. 
- 
-  * [[..:..:mon_stat:admin_stat_log_block|What are the lock counters stored in the statistics log?]] 
- 
-  * [[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:29000, errcode=99 : Cannot assign requested address 
-Autodetected fastdpi params : dev='lo', port=29000 
-connecting 127.0.0.1:29000 ..." We suspect that our way of subscribers loading to the VAS Experts DPI is not quite good enough. (we load each subscriber resulting in at least 50000 commands while initializing, that takes place in addition once a day just to be on the safe side)]] 
- 
-  * [[http://www.vasexperts.ru/upload/SCESM2СКАТ.zip| Migration scripts from SCE SM to VAS Experts DPI DB, the description is inside the archive]] 
- 
-  * How to check CPU core usage between available CPU cores  
- 
-  In order to view the CPU usage between available CPU cores, please launch the "top" utility from terminal and press "1" 
-  To get the CPU usage of a fastdpi's processes launch the following command: 
-  ps -p `pidof fastdpi` H -o %cpu,lwp,pri,psr,comm 
-  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 
-   (netflow generation, control commands reception, lists loading, pcap recording etc.)  
-   and may cause peak CPU loads, so they are set to run at specific core. 
- 
-  * Got an error in fastdpi_alert.log, what should we do?: [CRITICAL][2017/10/06-16:36:44:616019][0x7fdb297ac700] metadata_storage : Can't allocate memory [repeat 1], cntr=188889, allocated=188889  
- 
-   This error means, that fragmented packet cann't be reassembled. Usually it indicates a DDoS attack. 
-   You can just ignore it. The "CRITICAL" level of the error is inaccurate, it'll be changed to "WARNING" in future versions. 
- 
-  * Got an error in fastdpi_alert.log, what should we do? [CRITICAL][2017/10/06-16:36:44:616019][0x7fdb297ac700] metadata_storage : Can't allocate memory [repeat 1], cntr=188889, allocated=188889 
- 
-  DPI preallocates resourses before it gets started according to the given subscribers number by default.  
-  Эit is adjusted by the "mem_ip_metadata_recs" configuration option.  
-  So to increase the number of subscribers to 500000 "mem_ip_metadata_recs" opton should be edited in /etc/dpi/fastdpi.conf: 
-  mem_ip_metadata_recs=500000 
-  DPI restart is needed: 
-  service fastdpi restart 
- 
-  * What files are suggested to be archived? 
- 
-  cp /etc/pf_ring/ /BACKUPDIR/pf_ring  
-  cp /etc/dpi /BACKUPDIR/etc/ 
-  mdb_copy /var/db/dpi /BACKUPDIR/db/ 
- 
-  * ipmi consume 100% CPU, so it disturb dpi operation 
- 
-  echo 100 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us 
-  To make your changes persistent (to avoid this setting reset after the next server restart), you need to add the above command to the /etc/rc.local file.