[ic] 'Unable to send mail' - ongoing issue

[Daniel Browning]

* Mike Heins <mike at perusion.com> [2005-03-02 12:41]:
> Quoting Daniel Browning (db at kavod.com):
> > * Jon Jensen <jon at endpoint.com> [2005-01-04 17:22]:
> > > On Tue, 4 Jan 2005, Ed LaFrance wrote:
> > > 
> > > >I've just started working on a new client's system, and I see they are 
> > > >plagued with a problem that I have observed on a myriad of other 
> > > >installations. Namely, various emails sent by Interchange occasionally do 
> > > >not go out. The failed sends can be found in the catalog error log, 
> > > >preceded by the string 'Unable to send mail using (sendmail or similar)'. 
> > > >I have seen order reports, customer receipts, contact messages and more 
> > > >email types fail in this manner, sent by both email UserTags and 
> > > >Interchange's internal mailing routines. I've seen this on Red Hat, 
> > > >Debian, FreeBSD, and Solaris systems - maybe more, but those are the ones 
> > > >that come to mind. In all cases, the systems have plenty of available RAM, 
> > > >disk space and CPU resources.
> > > >
> > > >In one case I hacked the source a bit to capture some system error info to 
> > > >the catalog error.log, and the system said the cause was a 'broken pipe'. 
> > > >This was only on one system, so I don't know if that holds true for all 
> > > >cases.
> > > 
> > > Ed,
> > > 
> > > That sounds like the classic Perl signals problem to me. Have you tried 
> > > the remedies previously discussed on the list, of MaxServers 0 in 
> > > interchange.cfg and PERL_SIGNALS=unsafe in the environment?
> > 
> > [Continuing a very old thread]
> > 
> > I periodically get this problem on one catalog.  I have been running PreFork
> > with PERL_SIGNALS=unsafe the whole time.  It occurs during heavy system load.
> > This is on a Red Hat Enterprise 3 Dual 2 ghz with 2GB ram and a fast RAID. Perl
> > 5.8.3, 5.8.4, and 5.8.5 all seem to experience the issue.  It has occurred about
> > 1-2 times per month for the last six months.
> 
> If your system is RAID for everything, even for sessions, you are
> probably running into disk latency problems. Don't believe the hogwash
> the RAID controller makers will tell you, that their controllers are
> faster for write. I have tested it many times, and with frequent writes
> I am always able to demonstrate that eventually you will get the RAID
> controller to have a significant slippage causing slowdown.
> 
> Your best bet is to have a non-RAID disk and use that for your session
> storage.

That's a good idea, maybe I'll do that.  (You've actually suggested that to me
in the past, and I've even done it on a different system, but I've forgotten all
about it...).  

I didn't mention it before, but the system is using RAID-5.  RAID-5 can
never be as fast as a non-RAID as writes (except for the very short time
that it hits the write cache), but a RAID-10 system should theoretically be
twice as fast on writes.

-- 
Daniel Browning <db at kavod.com> - Kavod Technologies.  Random Fortune:
"May your future be limited only by your dreams."
-- Christa McAuliffe