You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by le...@srs.gov on 2005/01/19 18:47:55 UTC
New to SA, problems with production speed
This is my first post here, and liable to be a doozie!
Running SA 3.0.2 with Sendmail 8.12.11, hooked in with spamass-milter
0.2.0, all under Solaris 9. I also have SPF-Milter installed from
spf.pobox.com. SPF is the first milter, SA is the second
in the sendmail.cf file.
Sendmail running only as MTA with user delivery responsibilities.
I was able to build and install SA and the milter on a test machine
(running same config, except Solaris 8). Test machine was loaded with gcc
3.3.2.
We are starting SA and the spamass-milter program using the following
script:
#!/sbin/sh
#
# From: skod@ises-llc.com (Scott Griffith, ISES-LLC)
# To: <cr...@stanfordalumni.org>,
<sp...@lists.sourceforge.net>
# Subject: Re: [Spamassassin-talk] SysV-style startup script
# Date: Sat, 24 Nov 2001 12:09:16 -0700
#
# In case there are any Solaris folks out there who aren't comfortable
# with their own rc scripts, here's what I've been using for Solaris 7
# from day 1 with no problems. Filename:
#
# /etc/rc2.d/S78spamd
#PATH=$PATH:/usr/bin:/usr/local/bin:/sbin:/bin:/usr/sbin
PATH=$PATH:/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin
DAEMON=/usr/local/sbin/spamass-milter
SOCKET=/var/run/spamass.sock
DESC="Sendmail milter plugin for SpamAssassin"
case "$1" in
'start')
if [ -x /usr/bin/spamd -o -x /usr/local/bin/spamd ]
then
spamd -d -m 20 -u <obscured> --syslog-socket=inet
--nouser-config
fi
$DAEMON -p $SOCKET -i 192.168.<obscured> &
;;
'stop')
/usr/bin/pkill -9 -x -u <obscured> '(spamd)'
/usr/bin/pkill -9 -x -u 0 'spamass-milter'
rm $SOCKET
;;
*)
echo "Usage: $0 { start | stop }"
exit 1
;;
esac
exit 0
I had good success passing occasional messages through SA to test mail
accounts and it seems to work just as expected. On the test machine, I
was able to change
/etc/mail/spamassassin/local.cf to match our needs and local
configuration. Our only intent is to let SA tag the X-Spam* headers,
providing no change to subject or body of the messages.
The problem I am having now is that under a production load (~30,000 SMTP
connections per day), it looks like spamd/spamc handoff is slowing to a
crawl and consuming great amounts of memory. The first 2-3 emails that
come in after starting process within 2-5 seconds each, and after about 20
messages, the time spamd takes to process gets up into 100+ seconds. With
a steady volume of mail coming in, everything eventually chokes down, as
sendmail itself starts backing up tremendously.
The only thing that I did "out of the ordinary" was that I compiled
everything on our test machine, tar'd up the directories that everything
was built into, untar'd on the production machine, and ran "make install".
I did it this way because in our situation, compiling on the production
sendmail machine is frowned upon. This very well could be the reason of
my slowdown problems, and before I go fight the "but I have to be able to
compile in production", I wanted to see if anyone had any ideas about what
could be causing the slowdowns.
I know it's a LONNG first post, and thanks to any/all that can muddle
through and reply.
Re: New to SA, problems with production speed
Posted by Martin Hepworth <ma...@solid-state-logic.com>.
Leonard
most odd - perhaps ask the people involved in that bug (ie create an
bugzilla acct and ask then how to debug so you can get the thing going).
There is a flag on the spamd startup that limits the number it will
span which achieves a similar effect to the patch,,
-m num, --max-children=num Allow maximum num children
--max-conn-per-child=num Maximum connections accepted
by child
try adjusting these and see if it works better using the standard 3.02
distribution.
--
Martin Hepworth
Snr Systems Administrator
Solid State Logic
Tel: +44 (0)1865 842300
leonard.gray@srs.gov wrote:
>
> Martin,
>
> I'm having a little problem with the patch, as I'm admittedly not
> extremely "perl savvy". Perhaps you can see what I might be doing wrong
> and steer me in the right direction.
>
> 1. Saving both patches as text files (named patch1 and patch2
> respectively) into the /Mail-SpamAssassin-3.0.1 directory (I've tried
> with /Mail-SpamAssassin-3.0.2 as well)
>
> 2. Change to the /Mail-SpamAssassin-3.0.1 directory
>
> 3. Run "patch < patch1"
>
> At this point, MANIFEST is updated correctly, but the files that
> SHOULD be created in lib/Mail/SpamAssassin (SpamdForkScaling.pm and
> SubProcBackChannel.pm) are created in the base directory that I'm
> running patch from.
> Also, when patch tries to apply to spamd/spamd.raw it stops saying
> it can't find the file, and I have to manually enter "spamd/spamd.raw"
> to get that patch to apply.
>
> 4. Run "patch < patch2" (this one works fine)
>
> 5. Since SpamdForkScaling.pm and SubProcBackChannel.pm are not in the
> proper directory, I manually copy those to lib/Mail/SpamAssassin
>
> 6. Run "make" followed by "make install". Once again, the
> SpamdForkScaling.pm and SubProcBackChannel.pm are not copied to the
> /usr/local/lib/perl5/site_perl/5.8.3/Mail/SpamAssassin directory, so I
> copy them manually
>
> 7. Start everything up using an rc script
>
> The /var/log/syslog output shows a couple of child processes starting
> up, then shows "prefork: select timeout failed! recovering". Anytime a
> piece of mail is sent through from this point on, the select timeout
> failed message repeats hundreds of times.
>
> FWIW, this is on a Solaris 8 system.
>
> Thanks in advance for any help you could provide.
>
>
>
> *Martin Hepworth <ma...@solid-state-logic.com>*
>
> 01/19/2005 01:02 PM
>
>
> To
> leonard.gray@srs.gov
> cc
> users@spamassassin.apache.org
> Subject
> Re: New to SA, problems with production speed
>
>
>
>
>
>
>
>
> Leonard
>
> know issue with sa 3.0x and spamc/spamd. Will ne Fixed with 3.10
>
> work around is lower number of children allowed or apply following patches..
>
> http://bugzilla.spamassassin.org/show_bug.cgi?id=3983
>
>
> --
> Martin Hepworth
> Snr Systems Administrator
> Solid State Logic
> Tel: +44 (0)1865 842300
>
>
> leonard.gray@srs.gov wrote:
> >
> >
> > This is my first post here, and liable to be a doozie!
> >
> > Running SA 3.0.2 with Sendmail 8.12.11, hooked in with spamass-milter
> > 0.2.0, all under Solaris 9. I also have SPF-Milter installed from
> > spf.pobox.com. SPF is the first milter, SA is the second
> > in the sendmail.cf file.
> >
> > Sendmail running only as MTA with user delivery responsibilities.
> >
> > I was able to build and install SA and the milter on a test machine
> > (running same config, except Solaris 8). Test machine was loaded with
> > gcc 3.3.2.
> >
> > We are starting SA and the spamass-milter program using the following
> > script:
> >
> > #!/sbin/sh
> > #
> > # From: skod@ises-llc.com (Scott Griffith, ISES-LLC)
> > # To: <cr...@stanfordalumni.org>,
> <sp...@lists.sourceforge.net>
> > # Subject: Re: [Spamassassin-talk] SysV-style startup script
> > # Date: Sat, 24 Nov 2001 12:09:16 -0700
> > #
> > # In case there are any Solaris folks out there who aren't comfortable
> > # with their own rc scripts, here's what I've been using for Solaris 7
> > # from day 1 with no problems. Filename:
> > #
> > # /etc/rc2.d/S78spamd
> >
> > #PATH=$PATH:/usr/bin:/usr/local/bin:/sbin:/bin:/usr/sbin
> > PATH=$PATH:/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin
> > DAEMON=/usr/local/sbin/spamass-milter
> > SOCKET=/var/run/spamass.sock
> > DESC="Sendmail milter plugin for SpamAssassin"
> >
> > case "$1" in
> > 'start')
> > if [ -x /usr/bin/spamd -o -x /usr/local/bin/spamd ]
> > then
> > spamd -d -m 20 -u <obscured> --syslog-socket=inet
> > --nouser-config
> > fi
> >
> > $DAEMON -p $SOCKET -i 192.168.<obscured> &
> >
> > ;;
> >
> > 'stop')
> > /usr/bin/pkill -9 -x -u <obscured> '(spamd)'
> >
> > /usr/bin/pkill -9 -x -u 0 'spamass-milter'
> > rm $SOCKET
> >
> > ;;
> >
> > *)
> > echo "Usage: $0 { start | stop }"
> > exit 1
> > ;;
> > esac
> > exit 0
> >
> > I had good success passing occasional messages through SA to test mail
> > accounts and it seems to work just as expected. On the test machine, I
> > was able to change
> > /etc/mail/spamassassin/local.cf to match our needs and local
> > configuration. Our only intent is to let SA tag the X-Spam* headers,
> > providing no change to subject or body of the messages.
> >
> > The problem I am having now is that under a production load (~30,000
> > SMTP connections per day), it looks like spamd/spamc handoff is slowing
> > to a crawl and consuming great amounts of memory. The first 2-3 emails
> > that come in after starting process within 2-5 seconds each, and after
> > about 20 messages, the time spamd takes to process gets up into 100+
> > seconds. With a steady volume of mail coming in, everything eventually
> > chokes down, as sendmail itself starts backing up tremendously.
> >
> > The only thing that I did "out of the ordinary" was that I compiled
> > everything on our test machine, tar'd up the directories that everything
> > was built into, untar'd on the production machine, and ran "make
> > install". I did it this way because in our situation, compiling on the
> > production sendmail machine is frowned upon. This very well could be
> > the reason of my slowdown problems, and before I go fight the "but I
> > have to be able to compile in production", I wanted to see if anyone had
> > any ideas about what could be causing the slowdowns.
> >
> > I know it's a LONNG first post, and thanks to any/all that can muddle
> > through and reply.
>
> **********************************************************************
>
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> This footnote confirms that this email message has been swept
> for the presence of computer viruses and is believed to be clean.
>
> **********************************************************************
>
>
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote confirms that this email message has been swept
for the presence of computer viruses and is believed to be clean.
**********************************************************************
Re: New to SA, problems with production speed
Posted by le...@srs.gov.
Martin,
I'm having a little problem with the patch, as I'm admittedly not
extremely "perl savvy". Perhaps you can see what I might be doing wrong
and steer me in the right direction.
1. Saving both patches as text files (named patch1 and patch2
respectively) into the /Mail-SpamAssassin-3.0.1 directory (I've tried with
/Mail-SpamAssassin-3.0.2 as well)
2. Change to the /Mail-SpamAssassin-3.0.1 directory
3. Run "patch < patch1"
At this point, MANIFEST is updated correctly, but the files that
SHOULD be created in lib/Mail/SpamAssassin (SpamdForkScaling.pm and
SubProcBackChannel.pm) are created in the base directory that I'm running
patch from.
Also, when patch tries to apply to spamd/spamd.raw it stops saying
it can't find the file, and I have to manually enter "spamd/spamd.raw" to
get that patch to apply.
4. Run "patch < patch2" (this one works fine)
5. Since SpamdForkScaling.pm and SubProcBackChannel.pm are not in the
proper directory, I manually copy those to lib/Mail/SpamAssassin
6. Run "make" followed by "make install". Once again, the
SpamdForkScaling.pm and SubProcBackChannel.pm are not copied to the
/usr/local/lib/perl5/site_perl/5.8.3/Mail/SpamAssassin directory, so I
copy them manually
7. Start everything up using an rc script
The /var/log/syslog output shows a couple of child processes starting up,
then shows "prefork: select timeout failed! recovering". Anytime a piece
of mail is sent through from this point on, the select timeout failed
message repeats hundreds of times.
FWIW, this is on a Solaris 8 system.
Thanks in advance for any help you could provide.
Martin Hepworth <ma...@solid-state-logic.com>
01/19/2005 01:02 PM
To
leonard.gray@srs.gov
cc
users@spamassassin.apache.org
Subject
Re: New to SA, problems with production speed
Leonard
know issue with sa 3.0x and spamc/spamd. Will ne Fixed with 3.10
work around is lower number of children allowed or apply following
patches..
http://bugzilla.spamassassin.org/show_bug.cgi?id=3983
--
Martin Hepworth
Snr Systems Administrator
Solid State Logic
Tel: +44 (0)1865 842300
leonard.gray@srs.gov wrote:
>
>
> This is my first post here, and liable to be a doozie!
>
> Running SA 3.0.2 with Sendmail 8.12.11, hooked in with spamass-milter
> 0.2.0, all under Solaris 9. I also have SPF-Milter installed from
> spf.pobox.com. SPF is the first milter, SA is the second
> in the sendmail.cf file.
>
> Sendmail running only as MTA with user delivery responsibilities.
>
> I was able to build and install SA and the milter on a test machine
> (running same config, except Solaris 8). Test machine was loaded with
> gcc 3.3.2.
>
> We are starting SA and the spamass-milter program using the following
> script:
>
> #!/sbin/sh
> #
> # From: skod@ises-llc.com (Scott Griffith, ISES-LLC)
> # To: <cr...@stanfordalumni.org>,
<sp...@lists.sourceforge.net>
> # Subject: Re: [Spamassassin-talk] SysV-style startup script
> # Date: Sat, 24 Nov 2001 12:09:16 -0700
> #
> # In case there are any Solaris folks out there who aren't comfortable
> # with their own rc scripts, here's what I've been using for Solaris 7
> # from day 1 with no problems. Filename:
> #
> # /etc/rc2.d/S78spamd
>
> #PATH=$PATH:/usr/bin:/usr/local/bin:/sbin:/bin:/usr/sbin
> PATH=$PATH:/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin
> DAEMON=/usr/local/sbin/spamass-milter
> SOCKET=/var/run/spamass.sock
> DESC="Sendmail milter plugin for SpamAssassin"
>
> case "$1" in
> 'start')
> if [ -x /usr/bin/spamd -o -x /usr/local/bin/spamd ]
> then
> spamd -d -m 20 -u <obscured> --syslog-socket=inet
> --nouser-config
> fi
>
> $DAEMON -p $SOCKET -i 192.168.<obscured> &
>
> ;;
>
> 'stop')
> /usr/bin/pkill -9 -x -u <obscured> '(spamd)'
>
> /usr/bin/pkill -9 -x -u 0 'spamass-milter'
> rm $SOCKET
>
> ;;
>
> *)
> echo "Usage: $0 { start | stop }"
> exit 1
> ;;
> esac
> exit 0
>
> I had good success passing occasional messages through SA to test mail
> accounts and it seems to work just as expected. On the test machine, I
> was able to change
> /etc/mail/spamassassin/local.cf to match our needs and local
> configuration. Our only intent is to let SA tag the X-Spam* headers,
> providing no change to subject or body of the messages.
>
> The problem I am having now is that under a production load (~30,000
> SMTP connections per day), it looks like spamd/spamc handoff is slowing
> to a crawl and consuming great amounts of memory. The first 2-3 emails
> that come in after starting process within 2-5 seconds each, and after
> about 20 messages, the time spamd takes to process gets up into 100+
> seconds. With a steady volume of mail coming in, everything eventually
> chokes down, as sendmail itself starts backing up tremendously.
>
> The only thing that I did "out of the ordinary" was that I compiled
> everything on our test machine, tar'd up the directories that everything
> was built into, untar'd on the production machine, and ran "make
> install". I did it this way because in our situation, compiling on the
> production sendmail machine is frowned upon. This very well could be
> the reason of my slowdown problems, and before I go fight the "but I
> have to be able to compile in production", I wanted to see if anyone had
> any ideas about what could be causing the slowdowns.
>
> I know it's a LONNG first post, and thanks to any/all that can muddle
> through and reply.
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote confirms that this email message has been swept
for the presence of computer viruses and is believed to be clean.
**********************************************************************
Re: New to SA, problems with production speed
Posted by le...@srs.gov.
Thanks Martin, that helps let me know I haven't completely lost it.
I downloaded the patches, and am inexperienced in how to use "patch".
Tried several things, but assumed to place the patch files in
/SpamAssassin-3.0.2 directory, and then ran patch -i<patchfile>, which
didn't really work.
Is the patch process difficult to explain, or should I just wait for 3.10?
Thanks!
Martin Hepworth <ma...@solid-state-logic.com>
01/19/2005 01:02 PM
To
leonard.gray@srs.gov
cc
users@spamassassin.apache.org
Subject
Re: New to SA, problems with production speed
Leonard
know issue with sa 3.0x and spamc/spamd. Will ne Fixed with 3.10
work around is lower number of children allowed or apply following
patches..
http://bugzilla.spamassassin.org/show_bug.cgi?id=3983
--
Martin Hepworth
Snr Systems Administrator
Solid State Logic
Tel: +44 (0)1865 842300
leonard.gray@srs.gov wrote:
>
>
> This is my first post here, and liable to be a doozie!
>
> Running SA 3.0.2 with Sendmail 8.12.11, hooked in with spamass-milter
> 0.2.0, all under Solaris 9. I also have SPF-Milter installed from
> spf.pobox.com. SPF is the first milter, SA is the second
> in the sendmail.cf file.
>
> Sendmail running only as MTA with user delivery responsibilities.
>
> I was able to build and install SA and the milter on a test machine
> (running same config, except Solaris 8). Test machine was loaded with
> gcc 3.3.2.
>
> We are starting SA and the spamass-milter program using the following
> script:
>
> #!/sbin/sh
> #
> # From: skod@ises-llc.com (Scott Griffith, ISES-LLC)
> # To: <cr...@stanfordalumni.org>,
<sp...@lists.sourceforge.net>
> # Subject: Re: [Spamassassin-talk] SysV-style startup script
> # Date: Sat, 24 Nov 2001 12:09:16 -0700
> #
> # In case there are any Solaris folks out there who aren't comfortable
> # with their own rc scripts, here's what I've been using for Solaris 7
> # from day 1 with no problems. Filename:
> #
> # /etc/rc2.d/S78spamd
>
> #PATH=$PATH:/usr/bin:/usr/local/bin:/sbin:/bin:/usr/sbin
> PATH=$PATH:/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin
> DAEMON=/usr/local/sbin/spamass-milter
> SOCKET=/var/run/spamass.sock
> DESC="Sendmail milter plugin for SpamAssassin"
>
> case "$1" in
> 'start')
> if [ -x /usr/bin/spamd -o -x /usr/local/bin/spamd ]
> then
> spamd -d -m 20 -u <obscured> --syslog-socket=inet
> --nouser-config
> fi
>
> $DAEMON -p $SOCKET -i 192.168.<obscured> &
>
> ;;
>
> 'stop')
> /usr/bin/pkill -9 -x -u <obscured> '(spamd)'
>
> /usr/bin/pkill -9 -x -u 0 'spamass-milter'
> rm $SOCKET
>
> ;;
>
> *)
> echo "Usage: $0 { start | stop }"
> exit 1
> ;;
> esac
> exit 0
>
> I had good success passing occasional messages through SA to test mail
> accounts and it seems to work just as expected. On the test machine, I
> was able to change
> /etc/mail/spamassassin/local.cf to match our needs and local
> configuration. Our only intent is to let SA tag the X-Spam* headers,
> providing no change to subject or body of the messages.
>
> The problem I am having now is that under a production load (~30,000
> SMTP connections per day), it looks like spamd/spamc handoff is slowing
> to a crawl and consuming great amounts of memory. The first 2-3 emails
> that come in after starting process within 2-5 seconds each, and after
> about 20 messages, the time spamd takes to process gets up into 100+
> seconds. With a steady volume of mail coming in, everything eventually
> chokes down, as sendmail itself starts backing up tremendously.
>
> The only thing that I did "out of the ordinary" was that I compiled
> everything on our test machine, tar'd up the directories that everything
> was built into, untar'd on the production machine, and ran "make
> install". I did it this way because in our situation, compiling on the
> production sendmail machine is frowned upon. This very well could be
> the reason of my slowdown problems, and before I go fight the "but I
> have to be able to compile in production", I wanted to see if anyone had
> any ideas about what could be causing the slowdowns.
>
> I know it's a LONNG first post, and thanks to any/all that can muddle
> through and reply.
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote confirms that this email message has been swept
for the presence of computer viruses and is believed to be clean.
**********************************************************************
Re: New to SA, problems with production speed
Posted by Martin Hepworth <ma...@solid-state-logic.com>.
Leonard
know issue with sa 3.0x and spamc/spamd. Will ne Fixed with 3.10
work around is lower number of children allowed or apply following patches..
http://bugzilla.spamassassin.org/show_bug.cgi?id=3983
--
Martin Hepworth
Snr Systems Administrator
Solid State Logic
Tel: +44 (0)1865 842300
leonard.gray@srs.gov wrote:
>
>
> This is my first post here, and liable to be a doozie!
>
> Running SA 3.0.2 with Sendmail 8.12.11, hooked in with spamass-milter
> 0.2.0, all under Solaris 9. I also have SPF-Milter installed from
> spf.pobox.com. SPF is the first milter, SA is the second
> in the sendmail.cf file.
>
> Sendmail running only as MTA with user delivery responsibilities.
>
> I was able to build and install SA and the milter on a test machine
> (running same config, except Solaris 8). Test machine was loaded with
> gcc 3.3.2.
>
> We are starting SA and the spamass-milter program using the following
> script:
>
> #!/sbin/sh
> #
> # From: skod@ises-llc.com (Scott Griffith, ISES-LLC)
> # To: <cr...@stanfordalumni.org>, <sp...@lists.sourceforge.net>
> # Subject: Re: [Spamassassin-talk] SysV-style startup script
> # Date: Sat, 24 Nov 2001 12:09:16 -0700
> #
> # In case there are any Solaris folks out there who aren't comfortable
> # with their own rc scripts, here's what I've been using for Solaris 7
> # from day 1 with no problems. Filename:
> #
> # /etc/rc2.d/S78spamd
>
> #PATH=$PATH:/usr/bin:/usr/local/bin:/sbin:/bin:/usr/sbin
> PATH=$PATH:/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin
> DAEMON=/usr/local/sbin/spamass-milter
> SOCKET=/var/run/spamass.sock
> DESC="Sendmail milter plugin for SpamAssassin"
>
> case "$1" in
> 'start')
> if [ -x /usr/bin/spamd -o -x /usr/local/bin/spamd ]
> then
> spamd -d -m 20 -u <obscured> --syslog-socket=inet
> --nouser-config
> fi
>
> $DAEMON -p $SOCKET -i 192.168.<obscured> &
>
> ;;
>
> 'stop')
> /usr/bin/pkill -9 -x -u <obscured> '(spamd)'
>
> /usr/bin/pkill -9 -x -u 0 'spamass-milter'
> rm $SOCKET
>
> ;;
>
> *)
> echo "Usage: $0 { start | stop }"
> exit 1
> ;;
> esac
> exit 0
>
> I had good success passing occasional messages through SA to test mail
> accounts and it seems to work just as expected. On the test machine, I
> was able to change
> /etc/mail/spamassassin/local.cf to match our needs and local
> configuration. Our only intent is to let SA tag the X-Spam* headers,
> providing no change to subject or body of the messages.
>
> The problem I am having now is that under a production load (~30,000
> SMTP connections per day), it looks like spamd/spamc handoff is slowing
> to a crawl and consuming great amounts of memory. The first 2-3 emails
> that come in after starting process within 2-5 seconds each, and after
> about 20 messages, the time spamd takes to process gets up into 100+
> seconds. With a steady volume of mail coming in, everything eventually
> chokes down, as sendmail itself starts backing up tremendously.
>
> The only thing that I did "out of the ordinary" was that I compiled
> everything on our test machine, tar'd up the directories that everything
> was built into, untar'd on the production machine, and ran "make
> install". I did it this way because in our situation, compiling on the
> production sendmail machine is frowned upon. This very well could be
> the reason of my slowdown problems, and before I go fight the "but I
> have to be able to compile in production", I wanted to see if anyone had
> any ideas about what could be causing the slowdowns.
>
> I know it's a LONNG first post, and thanks to any/all that can muddle
> through and reply.
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote confirms that this email message has been swept
for the presence of computer viruses and is believed to be clean.
**********************************************************************