The DB mode (or Database mode) is special operating mode designed for large Network Multimeter systems for high traffic throughput. This mode optimizes the internal database management used for measured network data to be able to process a higher amount of network traffic. On smaller systems this method introduces an additional overhead so it is only available on selected models. There is however no difference in the measurement results.
The only side effect of the DB mode is that results might appear with an additional delay in the web interface. The DB mode uses separate CPU threads for databases management (instead of combined threads for both packet analysis and database management).
The DB mode is automatically enabled if the system is powerful enough. On some systems the mode can still enabled manually for special use cases. If the system supports the DB mode, additional configuration settings appear in the Global settings section under the Expert settings tab. There are two settings influencing the behavior of the DB mode.
- Queue multiplier: This setting configures the size of the message queue between packet analyzing threads and database threads.
- Usually the value does not need to be changed. If the system reports overload, the System Info Page should be checked. There is detailed load page when clicking on the load percentage. If any of packet analyzing threads show DB message lost counter, the queue size multiply might be increased.
- DB thread factor: This value configures how many packet analyzing threads are managed by a single DB thread.
- Setting this value to 0 disables the DB mode.
- Depending on the complexity of the network traffic, it can be beneficial to increase or decrease the value. The default value on most system is 4 (if the DB mode is available).
- The load graphs for each thread can be checked to decide if the value needs to be changed.
Possible reasons to modify the configuration values
Depending on the actual network, there can be situations where different configuration settings lead to better overall performance.
1. System overload and skipped packets.
- If packet drops appear, the packet analyzing threads might be overloaded. This can be checked in the load statistics.
- The current load percentage can be clicked to get detailed information about each system component. If the analyzing threads tend to have significantly more load than the DB threads, it is recommended to increase the DB thread factor in allocate less DB threads and use more analyzing threads.
2. System overload due to DB message lost.
- If DB message lost counters appear in the detailed load statistics (by clicking on the current load percentage), it means that the DB threads where not capable of processing the data created by the analyzing threads.
In this case it is beneficial to decrease the DB thread factor to use more DB threads and thus decrease the load per thread. Also, if the load graph shows only sporadic peaks to 100% load, it can help to increase the message queue size to buffer temporary overload. The Queue multiplier is an integer value which is used to multiply the queue size by this value. The value should be chosen carefully as a value of 10 already makes the queue ten times larger but also uses ten times more memory and can also increase the latency of the displayed measurement values by a factor of ten. If regular overload appears, a larger queue usually does not help much as it will just delay the message lost.