Submit a ticketCall us

Training Class Getting Started with SolarWinds Backup - February 28

This course offers customers an introduction to SolarWinds Backup, focusing on configuring the backup technology, taking backups, data restoration and data security. It is a great primer and will get you up to speed quickly on SolarWinds Backup.
Register for class.

Home > Success Center > Archive > 2017December18 - Deletes > Inbound message limit to stop packet loss

Inbound message limit to stop packet loss

Table of contents
This article is slated for Deletion. Do not update this article. If you have questions please send a message to

Created by Norsolihati Selamat, last modified by Jessica Solis on Dec 18, 2017

Views: 489 Votes: 0 Revisions: 4


This article describes the inbound message limit to stop packet loss.


All Kiwi Syslog versions


The inbound message limit to stop packet loss is a message buffer. As messages are received via the inputs (UDP, TCP, SNMP, Keep Alive), the messages are placed in an internal queue. The messages are then taken from the queue and processed in the order they arrived (FIFO). If a burst of messages arrive while the processing engine is busy, the messages are queued. This ensures messages are not lost under times of heavy load. 

Each message that is queued uses a small amount of memory. In most situations, buffering up to 20,000 messages is sufficient. You may want to increase the buffer size in situations where messages are arriving in large bursts. The buffering will smooth the message flow and allow the processing engine to catch up when it can. 

Messages are stored in Unicode which uses 2 bytes for each character. Therefore, if each message is 100 characters, it will occupy 200 bytes of memory. Messages can vary in size based on their content. 20,000 messages of 100 characters each will use 4,000,000 bytes (4MB) of memory. If each message was 200 characters long, it would use 8MB of memory. Memory is only used when the messages are being queued. Under normal traffic loads, the processing engine will be able to keep up with message flow and no messages will need to be queued. 




Last modified