On Sun, Nov 07, 2004 at 09:15:19PM -0500, David F. Skoll wrote: > On Sun, 7 Nov 2004, Dave Close wrote: > > > 26534 ? S 0:03 /usr/bin/perl /usr/local/bin/mimedefang.pl -server > > 6158 ? D 0:02 /usr/bin/perl /usr/local/bin/mimedefang.pl -server > > 6265 ? D 0:01 /usr/bin/perl /usr/local/bin/mimedefang.pl -server > > 6266 ? D 0:02 /usr/bin/perl /usr/local/bin/mimedefang.pl -server > > 6326 ? D 0:01 /usr/bin/perl /usr/local/bin/mimedefang.pl -server > > 6327 ? D 0:01 /usr/bin/perl /usr/local/bin/mimedefang.pl -server > > 6334 ? D 0:01 /usr/bin/perl /usr/local/bin/mimedefang.pl -server > > 6446 ? D 0:00 /usr/bin/perl /usr/local/bin/mimedefang.pl -server > > 6476 ? D 0:00 /usr/bin/perl /usr/local/bin/mimedefang.pl -server > > 6477 ? D 0:00 /usr/bin/perl /usr/local/bin/mimedefang.pl -server > > It's hard to know why this is happening. Try using the embedded Perl > interpreter -- perhaps your machine is running out of memory and swapping. > It could also be a hardware problem. Our main server would periodically > lock up with load averages in the hundreds. It turned out to be a flaky > disk that would sometimes take orders of magnitude longer than usual to > perform I/O.
strace is your friend. It should tell you very quickly what FH it's blocking on and ls in /proc will resolve the FH for you. From there it should be pretty easy to decide what the problem is - if, for example, it's waiting on the spools and the disk as shown by iostat is at 100% utilization you know it's the disk causing the problem. -- Kelsey Cummings - [EMAIL PROTECTED] sonic.net, inc. System Administrator 2260 Apollo Way 707.522.1000 (Voice) Santa Rosa, CA 95407 707.547.2199 (Fax) http://www.sonic.net/ Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896 _______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
