MonitorWare Knowledge Base

ah, the config is enlightning. I think I have explained the source for additional memory consumption (message object is larger than just the plain message text), but for the additional CPU there is an easy explanation (not easy to see for others, but me ): you use "if ... then" statements. Of course, that's what they are for, but the code that drives them is actually a preview of the full scripting engine (which I unfortunately could not yet implement). With the scripting engine, there is a real virtual machine started to evaluate the conditions. It's not as heavy as it sounds, but there is some overhead involved. Also, the VM code is not optimized currently. So things will probably improve as newer versions are released.

But the bottom line is that you can not do much against it currently. Restructuring the conf would be very complex, if at all possible.

• Custom written rsyslog.conf?
• Maintenance Contract?
• Installation support?

rgerhards wrote:Thinking about what you describe, the additional memory may be a result from the fact that rsyslog works with real properties, whereas the syslog-ng v2 (as far as Baszi wrote) does not work on properties but only on the message string itself.

Overall, I think I understand what you mean. To sum up in a simple way, you are looking in the "big" part of the paquet while syslog-ng is looking in the "small" part ?

What I don't understand is that for syslog-ng (v2), the word used for the regex (Alerts:, for example) is located in the msg (at least that's where the regex is done) while in rsyslog this word is in the property syslogtag and doesn't appear in the msg.

the source is the same, so the difference must be coming from the syslogs.

What if I did my regex on the msg instead ? If I can find something that corresponds to the tag in the message ? Would that improve the performances ?


Between, I tested the 4.1.4 devel, and the results are indeed better ^^(~10% gain in the 2nd used cpu).

syslog-ng does not really parse the message. rsyslog uses RFC compliant parsers (if I understood Baszi right, syslog-ng v3 seems to go into the same direction). In rsyslog, you can look at rawmsg, which is the unprocessed message. It seems not to be exactly the same as in syslog-ng, because (hearsay) syslog-ng seems to drop the PRI part of the message.

Exact reasoning for this you find in RFC3195, RFC3164 and the upcoming RFC 5424 (once it is published).

Rainer

I've read the RFC 3164 and I think I understand better the differences between syslog-ng and rsyslog.

I've made a test with rawmsg and there is a gain of ~5% cpu used in the 2nd cpu. I think I won't be able to gain much more

Anyway, thanks for your time and explanations about the scripting engine.