> >So, I looked at top and slocate was eating cpu. I killed slocate, > > Hmm... wonder why it was eating CPU. trying to index 75,000 x 8 message files, I bet. > >and restarted qmail. > > Why? It was going real slow. I was being irrational. > >Its been running for 20 minutes now, at 100% cpu > >utilization. > > Funny that qmail-send is now doing what slocate was doing. You're > seeing this behavior on two systems? If it was just one, I'd suspect a > h/w problem. Indeed. Two systems, the one finished munging after about 40 minutes of continuous processing. The huge queue was moved aside on the other server, and its now processing new incoming messages. I think I'll set up a secondary queue to transmit these queued messages in the meantime. > >I disabled tcpserver so that more messages won't interfere with the > >processing of the current queue. > > Watch out for local injections, too, via qmail-inject. Not an issue - these servers don't have any users. > >These systems have fast disks and fast CPUs. Should I let it continue > >munging on the data and hope it cranks through, or should I do something > >else... > > Don't do anything else until you figure out what the problem > is. Randomly trying things like restarting qmail will only make the > problem worse. Just too much data at once, Apparently. > >The log file shows nothing since restart at this time.... > > Hmm... What qmail processes are running? 2297 pts/1 D 44:30 qmail-send 2299 pts/1 S 0:00 splogger qmail 2300 pts/1 S 0:00 qmail-lspawn ./Mailbox 2301 pts/1 D 0:00 qmail-rspawn 2302 pts/1 S 0:14 qmail-clean Nothing out of the ordinary there. > >CPU states: 0.1% user, 99.8% system, 0.0% nice, 0.0% idle > > Ouch. 99.8% system is pretty extreme. Try strace'ing qmail-send to see > what it's doing. Accessing queue directories I can only imagine. Just doing an ls on a subdirectory of a directory like info takes about 10 seconds in this state. Even WITHOUT any programs eating CPU time. > > 403 root 0 0 216 168 116 S 0 0.0 0.0 544:12 syslogd > > Consider multilog instead. And svc to manage the processes too, yes. I'm seriously contemplating that. syslog doesn't seem to be a performance problem at this point, but it pays to be streamlined. David David Ihnen Integration Engineer myCIO 503-670-4018
