On Sun, 24 Jan 2016, Andre wrote:

Hi there,

After a while trying to get rsyslog to perform to my liking (what great
tool but how can so many Linux distro's ship with such an  undercooked
config???)  I decided to tune DynaFileCacheSize from its default to a
higher value and voila... seems like performance got to the point I wanted.

Question that I have is:

Other than evicted counter how does one knows DynaFileCacheSize needs
tuning?

most of the time you have a fairly good idea of how many files you will be creating at once, make the cachesize comfortably larger than the number of files that you expect to be creating.

In the past Rainer stated[1]:

"I remember one case where processing rate got up from few thousand to
several hundered thousand messages."

So far so good. But shouldn't the statistics counters reflect this
deficiency instead of requiring the log messages to be manually reconciled
during testing?

I explain:

I did some synthetic tests using multiple UDP sources, with a bunch of
nodes spoofing IP messages from 400 "hosts". And although I could see
messages were lost during the streams(by performing wc -l on resulting
files vs. the sources), both netstat and rsyslog's stats didn't show any
sign of packet loss that I could clearly see (other than omfile evictions).

Only when I decided to play with DynaFileCacheSize I could see the loss
ceasing but to my surprise despite the sharp decrease in evictions nothing
else changed.

Am I missing something?

Would anyone know what sort of extra symptoms a low DynaFileCacheSize value
displays?

a low size will result in a lot of system calls to close/open files, which will result in a lot of cpu time and low throughput.

this is frequently the first problem, but not always the only problem

the pstats output is going to be key to tracking down what is going on.

one common source of loss with udp is DNS lookups, try disabling DNS (this will make fromhost be the same as fromhost-ip), and see what happens.

look at the udp input stats and see if it's receiving everything that you expect it to be getting.

we can then go from there.

David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 
THAT.

Reply via email to