Re: ZMailer scheduler stuffing up severely...

[Matti Aarnio <mea@nic.funet.fi>]

On Mon, Oct 08, 2001 at 02:06:15PM -0700, Michael Loftis wrote:
>
> OK my system is doing deliveries but not at what it is capable of.
> The routers seem to be picking up from the router dir plenty fast
> enough, but scheduler fallls *massively* behind in processing queue.
> If I stop zmailer, then restart it (witht he synchronous start option)
> it reads in the queue and *FLIES* just fine.
> But during normal operations the damned thing just stuffs up.
> Whats the deal?


   Which version of ZMailer ?  At what kind of system ?
   ( UNIX version, and hardware, amount of RAM. )

   I think I have seen this jamming phenomena once or twice awhile ago.

   Ah! Recollection hits!  I guess the bug is due to crash of "timeserver".
   But why it crashes/stops ?  And why won't it recover ?  Can you tell
   me more about your system ? (Hardware, amount of memory, UNIX version ...)

   ZMailer scheduler contains a shared-segment subprocess which ticks
   2-3 times a second, and updates gettimeofday() data in that segment.
   The main scheduler reads this data.    (The thing could also be done
   with couple other ways which use interval timer to kick the time
   reading, and not using subprocess.    When I did the current system,
   I had previously done one server where a statistics summarizer / clock
   ticker is shared in between few hundred parallel running customer
   instantiated server processes.)

   Reason for this kind of thing has been a need to lower the amount of
   syscalls done by the scheduler in different systems -- the most common
   thing asked by the scheduler is refreshing the time information -- often!
   ( I mean like 100 000 times a second in some cases when scanning a very
     large queue.  Indeed the speed of gettimeofday() is limiting system
     performance at those moments.  )

> Note that these messages don't even show up in mailq stats for
> the most part.

   Does the  'mailq -QQQ' show the timer ticking ?
   If it isn't progressing, it is clear that the ticker is dead, but why ?

   If it isn't ticking, can you produce a full process listing with
   relationship data, and all status flags.  'ps FFFF' -- with
   system dependent set of flags...

> When left to it's own zmailer just does not keep up, when I go
> in and kick (zmailer stop, zmailer start -- scheduler in
> 'synchronous' start mode) it it cranks up and fills a 10Mbit
> pipe with ease.

   'zmailer scheduler'  will restart it, no need to restart
   all subsystems at the same time.

> Whats the catch here?

   Death of timeserver ?

-- 
/Matti Aarnio	<mea@nic.funet.fi>
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi