In addition, I should try to increase the NTFS journal size with the chkdsk /L:kbytes option.  You may simply be blocking too early on writes - Mercury doesn't give up a good fight easily, but a bit more breathing room for delayed transactions would surely be welcome in your situation.  (Use the /L option to find the current size.  You'll have to reboot for the change to take effect.  Try double, and watch your free disk space which you really want to provide more of if at all possible.)

Cheers,

Sabahattin

v4.52
MercuryS Server
MercuryE Client
Dual P4 2 Ghz
512MB Ram
 

Having a series of crashes when relaying mail from an IIS SMTP instance on another machine

IIS is set to use Mercury as a smart host and Mercury is set to accept relayed mail from the IIS machine.
Small scale usage patterns work fine, but we have noticed these crashes when we send out a large number (10k-20k) of messages generated from the IIS machine.

The contents of the messages are identical except for some customization (it's an opt-in newsletter) 

IIS Logs show numerous 421 responses from Mercury:

421 Service temporarily unavailable - please try again later.

Then these messages appear in the IIS log corresponding roughly to the timestamp on the BAD-YY-MM-DD.hhmm folders created when the Loader crashes and quarantines the queue:

421 Service not available, closing channel.
452 Message not delivered: insufficient system storage.

MercuryS Server log shows a few worrisome errors (coded E):

Unexpected abort talking to 192.168.1.53   (the IIS host)
Disk error during message reception

Disk has 10GB free.

Crashes occurred every 5-15minutes throughout the day. I stopped all services, rebooted and ran chkdsk and defragged the drive. No errors found on disk.

After that, server ran for approx 5 hours and crashed again, leaving a BAD queue folder with 80k files in it.

 
Questions:

1) Should the contents of the BAD-YY-MM-DD.hhmm folders be copied back into the main Queue to attempt processing?
Some of them seem to have significantly more files than I would expect. Most contain a few hundred, but we have 1 with 6k and 1 with 80k files in the folder.

2) Would Mercury have Disk access problems if Session logging was enabled? It was for a time, creating some large logfiles. Has since been disabled, but the loader did crash again, leaving the BAD queue folder with the 80k
files in it.

3) We do not seem to have this trouble when sending messages (even large numbers) from another application that is coded to connect to MercuryS and send through it. In that scenario we loop through each message, connect to Mercury, send, disconnect, etc. So it is much slower than the firehose that IIS seems to be opening up. Thoughts?

 
Thank you

Presumably the situation is exactly what the error messages indicate, the disk system is too slow to keep up with the many disk access requests. Activating session logging will make it worse as there will be twice as much to write to disk. Mercury has crashed for me several times when a faulty disk has been involved, so it's sensitive to disk errors.

A faster disk could help, or you may need to switch of any anti-virus program or other software that might interfere with and delay disk access.

If the contents of the BAD-YY-MM-DD.hhmm folders is valid (no broken files) you can test moving the files back into the queue directory. It might be a good idea to pause Mercury while moving large numbers of files to the queue, though.

/Rolf 

Hmm, keeps happening, although with less frequency than yesterday. It seems that once the messages are in the Mercury Queue ready to be sent via MercuryE, it is able to process them. It is just when it is processing the relay from IIS that it has the trouble.

The disk speed presumption makes sense, so I'll look at that.

Thanks Rolf.
 

Mercury/32 v4.52 keeps more data in memory and so I'd look at putting in a couple of gigs of ram as well so that the OS has a bit more room to play with.