Hi Chip Sorry to take so long in replying to you . You hit the nail on the head !!!
I have switched around the partitions containing /var/spool/mail and /var/spool/mqueue and /var/log and /var/squid_cache. In addition , we were running a mail virus filter that wrote its own logs to var/mail-filter and rejected files to /var/mail-rejects !!!!!!!!!!!!! Cheers Jay Chip Old wrote: > On Sat, 27 Oct 2001, Jay Banda wrote: > > > Unfortunately , over the past 2 days , I seem to be having a problem > > with my mail server. We are runing Slackware 7.1 , with sendmail > > 8.11.4 , procmail 3.22 and qpopper 4.0.3. > > > > What we are seeing is that when sendmail tries to deliver mail to all > > our users at once ( when we issue a blanket email to our subscirbers > > ), it will deliver half of the messages , and then give up with the > > message > > > > "timeout waiting for input from local during Draining Input" > > That is a Sendmail issue. See > http://www.sendmail.org/~ca/email/smenhanced.html a brief explanation of > the "Draining Input" syslog message. It may or may not apply to your > situation. > > How many addresses are on the recipient list for these mass mailings? > What distribution mechanism do you use? > > If you're using mailing list management software (Majordomo, Listproc, or > similar), this shouldn't happen. However it can easily happen if you are > using a plain alias list (in /etc/mail/aliases or your local equivalent) > to deliver to your subscribers, and if your subscriber list is fairly > large. I used to see it occasionally under a certain combination of > circumstances: When sending to a group of nested alias lists totalling > about 800 addresses *AND* cpu usage was already high *AND* there was a lot > of disk I/O occurring on the disk that contains the mail spool. > Switching my large lists to Majordomo control solved the problem. I use a > majordomo mailing list comprised of almost 9000 local addresses to send > info to my users, and I never see a "Draining Input" message resulting > from it. > > Alternately, if all your users use POP clients to read their mail, why not > use QPopper's "POP Bulletin" feature instead of a mailing list? This > writes the message to the user's mailbox only when he/she makes a POP > connection, so the load is spread out over a much greater time period. > > > Meanwhile , qpopper sessions for the mailboxes that have NOT received > > the mailing yet begin to go into a "dead" state, and do not allow > > anyone to login. These sessions cannot be killed, and they increase as > > each person tries to pickup mail , until the cpu load average reported > > by the system causes the MTA to begin rejecting connections ( > > approximately 10 mins ) > > > > When the server gets to this state , it is nearly impossible to > > list the files in the mail spool directories ( it is still possible to > > move around the rest of the file system ). > > It's difficult to tell without more information, but I suspect you're > running into a disk I/O bottleneck situation. Consider this: It's common > in a traditional UNIX file system layout for logging, mailbox storage, and > Sendmail spooling to occur on the same disk (in /var/log/syslog, /var/mail > & /var/spool/mqueue, for example). If you add QPopper and use the same > disk (let's say /var/spool/poptmp) for its temp files, you've added > another potentially I/O intensive activity to the same disk. > > If your setup is like that, when you send your mass mailing, your MTA > (sendmail) is probably writing it to and then reading it from > /var/spool/mqueue, and logging each action to /var/log/syslog. Your MDA > (procmail) is writing each copy of the message to /var/mail/<username>. > At the same time, for each connected POP client, QPopper is reading from > /var/mail/<username> and writing to /var/spool/poptmp/.<username>.pop. > If your subscriber list is large, that's a lot of disk I/O concentrated > into a relatively small amout of time. > > Do you have a version of "top" that shows how much processor time is spent > waiting for disk I/O? If when you send one of your mass mailings the > processor idle time drops to near zero and the I/O Wait percentage goes > very high, then you've got a disk I/O bottleneck. > > How you solve the disk I/O bottleneck depends on what your current disk > setup is like. If you have slow disks and a slow disk controller, then an > upgrade to faster hardware might help. Alternately, rearrange your disk > space (and mount points) so /var/spool and /var/mail (or the equivalents > on your machine) are on separate disks from the reast of /var (and if > possible, separate disk controllers). That's what I did, and it made a > tremendous difference in mail system performance in general and QPopper > performance specifically. > > Or, as mentioned above, switch to QPopper's "POP Bulletin" method to > spread out the load. Unfortunately that isn't practical on my system > because it doesn't work for IMAP users, or for those who use Pine, Elm, > etc in the UNIX shell. > > -- > Chip Old (Francis E. Old) E-Mail: [EMAIL PROTECTED] > Manager, BCPL Network Services Phone: 410-887-6180 > Manager, BCPL.NET Internet Services FAX: 410-887-2091 > 320 York Road > Towson, MD 21204 USA
