Re: A bug in syslogd?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks Cameron,

Sorry to get back you late on this.   yes, so if it is just purely
just getting the message, and then discard, and then getting it
again....there are a few optimization possible (sorry, i did not look
at source, but just guessing):

a.   allocate a ring buffer, so as to be reused all the time, without
allocation.
b.   if the config file (syslogd.conf) say discard, then then there
should be ZERO copying of the messages generated by the printk() codes
originating from kernel source codes.   I instrumented the kernel
source to do printk()....but because the execution path is hot, as it
is traversed many times over, CPU activities really rises up very
high.....but in actual fact my /var/log/messages is ZERO content.
i am quite sure there is some under-optimization somewhere.

Thanks.


On Fri, Jan 23, 2009 at 6:30 PM, Cameron Simpson <cs@xxxxxxxxxx> wrote:
> On 23Jan2009 17:34, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote:
> | I did a simple thing - modified my syslog.conf:
> |
> | cat /etc/syslog.conf
> | mail.none;authpriv.none;cron.none               /var/log/messages
> |
> | So virtually, there is nothing to go to /var/log/messages, although my
> | dmesg's output did output a lot of other stuff....as I instrumented
> | the kernel to do printk()....something like every file traversal will
> | generate several entries in dmesg output.
> |
> | Nevertheless, since /var/log/messages to get, as I check, its content
> | is always zero (after I did an initial truncation) - why is syslogd
> | showing such a high performance:
> [...]
> | Over a period of time, I observed that klogd and syslogd is toggling
> | to be among the top few candidate all the time - toggling, meaning
> | switching between one and another.
> |
> | Can someone explained this behavior?   Shouldn't the syslogd be
> | consuming almost zero cpu % since there is zero output to
> | /var/log/messages?
>
> Not really. Your kernel logging is still _all_ going through syslogd,
> which is quietly deciding not to _copy_ it into the messages file. But
> it still has to consider and then discard) every kernel message.
>
> Cheers,
> --
> Cameron Simpson <cs@xxxxxxxxxx> DoD#743
> http://www.cskk.ezoshosting.com/cs/
>
> Anagram: Information superhighway <==> I'm on a huge wispy rhino fart.
>
> --
> fedora-list mailing list
> fedora-list@xxxxxxxxxx
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
> Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
>



-- 
Regards,
Peter Teoh

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux