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

Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd

On Sun, Aug 05, 2007 at 11:49:12PM +0200, SZALAY Attila wrote:
> Hi All!

  please don't CC me, I read the list, and my M-F-T specifically ask you
not to do so[0].

> On Sun, 2007-08-05 at 23:07 +0200, Pierre Habouzit wrote:
> >   Why ? Do you need 4 CPU to soak your hard drive ? There is usually one
> > partition for every logs on the machine, so you don't get a lot writing
> > many log files at a time. And if you're that concerned with performance,
> > then it's not multi-foo that you need, but aio's, and a big nice epoll
> > loop to dispatch /dev/log clients. And absolutely no multiple processes
> > that you will else have to deal with locking, especially locking of
> > output files, which would be a huge mistake.
> You are wrong because (and this is what I have said) aio and epoll
> couldn't gain anything from the second processor.

  You didn't answered, why is there any kind of gain to use another CPU
where 1/100 of one is enough ?

> You can prove this if you try. (I have tried.)

  I code daemons using epoll and such techniques (without threads or
even multiple processes of course) for a living.

> >   The syslog daemon shall not eat anymore than 0.01% of your CPU. Why
> > would you need to bloat it for god's sake ? It reminds me of so called
> > network monitors that are so huge, that they mostly measure their own
> > fat. A multi-foo syslog daemon is just plain silly.
> Yes, you are right in a Desktop. You are right in a server too. But if
> you want to collect log messages from some hundred machine is an other
> question. And it's more easy to put another CPU into the machine than
> double the clock rate.

  That's very blunt assertions, backed up with nothing. The bottleneck
in any application that has big flows of data to write somwhere, is the
hard drive (or you're a very crappy programmer). So please explain to me
how using more CPU will make you able to write faster to your hard
drive. I'm sure that would be enlightening.

Hint: For a hundred machines, even very busy ones, you don't need
multiple processes to collect the logs. And for a thoudand, you'll
merely need a setrlimit to overcome the 1024-file-descriptor-limit.

  [0] thanks Mister Ray not to start a new MFT flame.
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgpy01CgclA1i.pgp
Description: PGP signature

Reply to: