On Sun, Nov 05, 2000 at 06:48:38PM +0100, Markus Stumpf wrote:
>I think there shouldn't be one queue in the scheduler. There's IMHO no
>need to have the scheduler do both: insert new messages and schedule
>deliveries. the big-todo patch has nothing to do with it. it just
Unless you're running a file-system that doesn't do effectively a
linear scan of a directory for every insert and remove operation,
keeping the todo small is a very good idea. Otherwise you chew up
a lot of time in the kernel. That's why I said it's a good idea
to have a scheduler that gives precedence to the todo queue. Why
do you disagree?
>Sorry? No you can't, at least not with a lot of the bounces. If
>qmail-remote gets a permantent error, it signals back to qmail-send
>and a bounce is generated internally (i.e. injected into the queue).
>You can't avoid this happen locally.
Sorry? Yes you can. If it's important to you to do so, simply move
into place a qmail-queue which injects the messages into the other queue.
If you're still injecting into the main queue at this time, you'll need
to call qmail-queue directly. It all comes down to how important it
is to you to get better performance.
The images posted previously suggest that their biggest problem was with
remote bounces, however. If they were local bounces, I would expect to
have seen consistently lower performance, but the way it looked to me
was that delivery would pick up quite nicely and run for a while until
remote hosts started turning around a bunch of bounces. That was just
a guess, but it seemed not entirely an unreasonable one.
Sean
--
Hack the man.
VOTE! November 7, 2000
Sean Reifschneider, Inimitably Superfluous <[EMAIL PROTECTED]>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
