Sniffer news

From VoIPmonitor.org
Revision as of 16:52, 22 July 2013 by Festr (talk | contribs)
Jump to navigation Jump to search

version 8 brings new internal buffering mechanism

Version 8 implements new way of buffering packets from kernel ringbuffer into dynamically allocated buffer which has now no memory limit. The old vmbuffer was allocated statically up to maximum 4GB memory but the new buffer grows dynamically up to desired memory. What is the buffer good for? In case storage disk is temporarily overloaded and the sniffer is storing all packets to disk the buffer is growing faster than the I/O rate. For some high network traffic 4GB buffer was not enough and can handle only few minutes under high pressure. The new buffer can also be compressed (~50% ratio) thus doubling the overall memory. If the memory buffer is completely filled disk buffer is used which is also new feature for those who wants to not loose any single packet in any situation. Storage for disk buffer is recommended dedicated which is not shared with pcap or mysql (so it can guarantee desired I/O throughput). The new buffer also reduces number of packet copies to only 1 instead of 3 reducing CPU by 10%.

With the new buffer mechanism we also implemented new mirroring option which sends compressed buffer over TCP socket to remote voipmonitor sniffer. This approach is now recommended way how to do software packet mirroring between two linux servers. Sometimes it is not desired to overload Linux based PBX/SBC by voipmonitor sniffer so the sniffer acts only as mirror. The mirroring can do auto-reconnect in case of connection failure and can use the new buffering mechanism - in memory and on disk with compression which means that the mirroring can be interrupted for as long as allocated memory or disk space.

With version 8 it is now possible to add capture rules with "skip" flag which completely skips processing certain calls based on IP or Tel. number rules.

New debug messages - if voipmonitor sniffer is running with at least "-v 1" you can watch several metrics:

calls[365][401] cdrqueue[0] heap[0.1%] heapoverruns[0] comp[41.3%] traffic[25.9Mb/s] t0CPU[6.3%] t1CPU[1.6%] t2CPU[1.4%]
calls[365][405] cdrqueue[0] heap[0.0%] heapoverruns[0] comp[41.3%] traffic[25.2Mb/s] t0CPU[6.4%] t1CPU[1.6%] t2CPU[1.5%]
calls[346][386] cdrqueue[0] heap[0.1%] heapoverruns[0] comp[41.3%] traffic[25.6Mb/s] t0CPU[6.3%] t1CPU[1.6%] t2CPU[1.5%]