Zitat von Silas Boyd-Wickizer <s...@mit.edu>:
Why do you believe that this should use 100% of ALL Cpus?
If you look at your synthetic test then you will likely find that
there are at any point in time only a few mail receiving processes
and mail delivering processes, and that these processes will all
be waiting for kernel system calls to complete.
With this synthetic test you really have only a low-concurrency load.
Yes, there are only a few mail delivering processes (virtual).
Why is this a function of my load? There are many messages
waiting for delivery, so why doesn't postfix run more virtuals
to increase concurrency?
I'm not sure what you mean by "waiting for kernel system calls to
complete". Do you mean "executing kernel system calls" (reading
from a pipe), or "blocked on kernel system calls" (i.e. waiting
on a pipe)?
As far as i understand all mail must "pass" (by means of decide what
to do with) the qmgr which is a single process and therefore limited
to one CPU. As you have show it is able to manage around 3000 mail/sec
(which means around 10 mio. a hour btw) on a low cost CPU core.
In practice you will never be able to push mail that fast to any
permanent storage available today...
If you will be able to do so in the far future one CPU core will be
even faster and therefore qmgr will still not be the bottleneck in any
real mailsystem.
This is why your "benchmark" is only useful to see qmgr working hard
because in any real-world scenario it is nearly idle waiting for the
disk I/O.
Be aware that this is a "naive" explantation and the internal details
are more complex than this.
Regards
Andreas
