Re: large todo queue - HELP!
On Wed, Jan 24, 2001 at 12:44:16PM +0100, Markus Stumpf wrote: > What I did once was to compile an identical copy of qmail but with > another location of the queue directory (however on the same physical > disk) and install it. > Compile a copy of qmail with big todo. > Stop all qmail services (also smtp) > > Now, rm -r the queue directory of the identical copy and "mv" the queue > directory of the original qmail there. > > Install qmail with big todo. > > start qmail-send for the bigtodo and the copy. > start smtpd for bigtodo only. > > With this procedure you get the queue "out of the way", have a new, > fresh one that will work (hopefully) fast and the old one will get > smaller with the time. Sounds similar to my current plan. What I'm gonna do: - compile a qmail with suitable conf-split, put it in /var/qmail2. - run smtpd 'n stuff from qmail2 - let /var/qmail/queue slowly empty (the original qmail-send runs too) - when /var/qmail/queue is empty, upgrade conf-split on /var/qmail/queue, switch services over to /var/qmail again - let /var/qmail2/queue empty - get rid of /var/qmail2 The main cause for this is that I have a dedicated queue disk so I can't move the queue around easily. The qmail2 will use a spare 4.5gb partition on the first disk. In the meantime a co-worker is building a second box to go alongside this one, to lighten the load forever (and to not be without if this one dies). Greetz, Peter.
Re: large todo queue - HELP!
On Wed, Jan 24, 2001 at 10:59:04AM +0100, Peter van Dijk wrote: > The todo-queue is *slowly* getting smaller (71288 now, compared to 71690 > when I started typing), but the complete queue is growing (100121 > now). What I did once was to compile an identical copy of qmail but with another location of the queue directory (however on the same physical disk) and install it. Compile a copy of qmail with big todo. Stop all qmail services (also smtp) Now, rm -r the queue directory of the identical copy and "mv" the queue directory of the original qmail there. Install qmail with big todo. start qmail-send for the bigtodo and the copy. start smtpd for bigtodo only. With this procedure you get the queue "out of the way", have a new, fresh one that will work (hopefully) fast and the old one will get smaller with the time. HTH, \Maex
Re: large todo queue - HELP!
Hi, Sorry can't help here but though would like to know how to setup the concurency levels in tcpserver which is discussed below. Regards Sumith - Original Message - From: Peter van Dijk <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 24, 2001 3:29 PM Subject: large todo queue - HELP! > One of my big qmail boxes is not keeping up with the flow of mail: > messages in queue: 98620 > messages in queue but not yet preprocessed: 71690 > > > It's a dual PIII with 1GB of RAM. > > concurrencylocal is 1024 (usage hardly ever goes above 3) > concurrencyremote is 256 (usage varies from 0 to about a 50 - remote > sites are slow) > smtpd concurrency (tcpserver -c) is 1024, usage 30-40 > pop3 concurrency is 1024, usage 20-30 > > All logging thru multilog. > > 10:51AM up 8 days, 20:33, 3 users, load averages: 2.23, 1.84, 1.47 > CPU states: 24.9% user, 0.0% nice, 35.8% system, 2.1% interrupt, 37.2% idle > > iostat shows heavy traffic on the queue disk (a seperate 9gb scsi > disk). > > My first idea is that the filesystem is not keeping up, and a bigger > queue-directory split would solve stuff. However, that's kinda hard to > implement now. > > So my question is: any tips for increasing performance without > throwing the queue away, or tricks for getting rid of a todo-queue > quickly. > > I am considering recompiling qmail for a bigger queuedir split, and > then applying queue-fix. Any objections or tips, or is this a bad > idea? > > As an interesting detail, virtual domains are handled through the > alias user and fastforward, and then reinjected into the queue. This > probably makes it worse. > > The todo-queue is *slowly* getting smaller (71288 now, compared to 71690 > when I started typing), but the complete queue is growing (100121 > now). > > 'Help!' > > Greetz, Peter. >
large todo queue - HELP!
One of my big qmail boxes is not keeping up with the flow of mail: messages in queue: 98620 messages in queue but not yet preprocessed: 71690 It's a dual PIII with 1GB of RAM. concurrencylocal is 1024 (usage hardly ever goes above 3) concurrencyremote is 256 (usage varies from 0 to about a 50 - remote sites are slow) smtpd concurrency (tcpserver -c) is 1024, usage 30-40 pop3 concurrency is 1024, usage 20-30 All logging thru multilog. 10:51AM up 8 days, 20:33, 3 users, load averages: 2.23, 1.84, 1.47 CPU states: 24.9% user, 0.0% nice, 35.8% system, 2.1% interrupt, 37.2% idle iostat shows heavy traffic on the queue disk (a seperate 9gb scsi disk). My first idea is that the filesystem is not keeping up, and a bigger queue-directory split would solve stuff. However, that's kinda hard to implement now. So my question is: any tips for increasing performance without throwing the queue away, or tricks for getting rid of a todo-queue quickly. I am considering recompiling qmail for a bigger queuedir split, and then applying queue-fix. Any objections or tips, or is this a bad idea? As an interesting detail, virtual domains are handled through the alias user and fastforward, and then reinjected into the queue. This probably makes it worse. The todo-queue is *slowly* getting smaller (71288 now, compared to 71690 when I started typing), but the complete queue is growing (100121 now). 'Help!' Greetz, Peter.
