GetMail service pegging CPU

[Brian.Turner]

I'm running Pagegate v4.0, and the PGGMail.exe is dated 7/1/2004 2:41 PM, and is file version 4.0.0.8

Just recently our PG server was suddenly running very slow and i discovered that the GetMail service was using nearly 100% of the CPU, all the time. I did a hard boot first, but that didnt fix it.

I removed the GetMail service from the program and restarted, then all was well.

When i added it again, it again took over as much CPU as it could. There is nothing in the GetMail log though except for this:

10/5/05 12:31:44 PM Module Started
10/5/05 12:31:48 PM Time synchronized with scheduler
10/5/05 12:33:00 PM Module Started
10/5/05 12:33:02 PM Time synchronized with scheduler
10/5/05 12:34:04 PM Module Started
10/5/05 12:34:12 PM Unable to synchronize time with scheduler. Using local time.
10/5/05 12:35:32 PM Module Started
10/5/05 12:35:35 PM Time synchronized with scheduler
10/5/05 12:35:35 PM Module Stopped

I manually killed the service a couple of times with pskill just so i could have enough CPU to get into PGAdmin and turn it off, thus the several starts without stops.

GetMail was running fine for over a year, then this suddenly happened a couple of weeks ago. I just now got around to trying to re-enable GetMail (after a customer that uses the multipage feature notified me that it wasnt working), and i ma still having this problem.

Has anyone else experienced this?


-Brian

[Tech Support]

Brian,

This generally happens when the GetMail service gets a message that it doesn't really know what to do with.

In order to figure out what exactly is happening, we need to get a copy of one of the messages before it is processed by GetMail. Typically GetMail is too quick to grab a copy of the raw mail file before it is processed. The easiest approach is to stop PageGate, set the polling interval for the GetMail interface to 60 (1 minute), and restart PageGate.

Send a message to the PageGate system, then watch the MailIn folder for the message. When it shows up, make a copy before GetMail grabs the file (should be named *.msg). You may have to try a couple times if you have bad luck and the file comes in right before the 1 minute processing interval happens.

Then, send me the file to support@notepage.com and I will take a look. GetMail obviously doesn't like something about the email's format.

Also, be sure to change the processing interval for GetMail back to 5 seconds or whatever you had it set to previously.

[Brian.Turner]

I found the problem and fixed it.

I first tried compact/repair on the database (can this be automated somehow, by the way?) which it needed anyway (took it from 110MB down to about 32).

When i was copying my newly compacted DB back into the program directory, I noticed that there is a MailIn directory so i peeked inside and saw tons of files named

<mulitpage recipient>$<15 digit id number>.msg1.pro

and they wen back in time as long as i have had that multipage recipient setup. The most recent file though, was a single file with only a .MSG extension, insiead of the .msg1.pro like the others.

I moved all of these files into another directory, then restarted all of PG, and when i enabled GetMail, it did NOT peg the CPU this time. I let it run for a minute or two, then i pasted that .msg file back into the MailIn directory. Sure enough the CPU got pegged by PGGMail again, so just delted the .msg and restarted Getmail.

The .msg was considerably larger (~17kb instead of 2-4kb) than the others too. Aside from what might be some kind of attachment, it appears to be a normal email when i open it with notepad.

I can mail you guys this file if you want, for examination.

-Brian

[Brian.Turner]

I didnt see that you guys had replied already, just now emailed you the .MSG file.

-Brian

[Tech Support]

Glad to know that you've fixed the problem, thank you for the description of the process and solution.

As for the compact and repair, it's not something that can be automated, it must be done manually.

If you would, please do send that .msg file as an attachment to support@notepage.com so we can determine what it was, specifically, about the message that caused the GetMail interface to peg.