GRP file holding up webmail
Question asked by Jay Altemoos - February 18, 2016 at 9:30 AM
Unanswered
Currently we are running SmarterMail Enterprise Version 14.4.5801. The weird issue we ran into today was a user called in mentioning that the web interface appeared to be frozen. Checking the IIS service in the taskmanager on our server, the w3wp.exe file was using 900mb of ram. Our server has more than enough ram to handle this, so I investigated further and found the the user experienced this when they clicked on their Inbox. So searching through their user account on the local drive I found that the GRP file from the previous day is 308MB. So I stopped the SmarterMail service and removed the GRP file. Restart the SmarterMail service and the user logs back in and now the inbox populates just fine with the exception of the day I removed.
 
So here's my question, why did the the web interface time out? All I saw was the candystripe progress bar just sitting there for at least 5 minutes and never got any further. I want to put the file back in place so the user has their email from that day but short of using a text editor to rip out the bad portion of the email from the GRP file, is there a utility to view the GRP file so I can find the suspect email easier? Or is a text editor my only option here?
 
Also is there any optimizations I can tweak IIS 7.5 for to recover from a situation like this instead of me pulling the rug out from under IIS in the taskmanager?

7 Replies

Reply to Thread
0
Was that user being indexed at the time by Smartermail?
0
Jay Altemoos Replied
I don't have an answer for that because I myself couldn't look at that screen if I wanted to. It was timed out on my side as well. The candystripe progress bar was sitting there for me just as it was for the user. I can assume the same for the rest of my users that use webmail it was that way too until I had IIS recover itself. All I could do is pull the rug out from under IIS by ending the w3wp.exe in taskmanager. Then Smartermail recovered fine. Really weird issue. I am in the process now of hand editing the GRP file with a text editor to find the suspect email and take it out since I can't seem to find a GRP viewer to see it as SmarterMail does. Joy.
1
Jay Altemoos Replied
Has anyone else run into this issue?
1
Jay Altemoos Replied
So I spent the better part of yesterday using a text editor and grabbed each email out of the GRP file. I placed each one in a separate text file and was able to open each email in my mail client after I renamed the extension to .EML. So my initial thought was a malformed email causing the issue, but that doesn't seem to be the case here. Here's the steps I took this morning to further narrow down the problem:
 
1. Stopped the SmarterMail service
2. Deleted the index files for this user along with the mailbox.cfg file from the Inbox
3. Started SmarterMail back up and logged into the interface
4. Issued a re-index of the users mailbox and bam the web interface starts to time out again.
5. Stopped SmarterMail and took the 308mb GRP file out again
6. Started SmarterMail again and reissued a re-index this time without the 308MB GRP file in place
7. No issues with the web interface while the re-index was happening for this user
 
So then I went a step further, I audited the entire mail server Domain folder for SmarterMail using AgentRansack. The query I fed it was giver me every GRP file in this folder no matter who's domain it is and show me any GRP files that are over 200MB. Looking at some of the other users Inbox files that are over 200MB don't have an issue. So I took a GRP file from the same user from a previous day that was having this issue and copied all the text from the file that was causing the problem and backfilled it into the other GRP file using EditPad. I only overwrote the text and not the header information. We will see what happens now. Thinking maybe corrupt GRP file? It's really odd. Is there an easier way to rebuild a GRP file than what I just did?
0
Paul Blank Replied
If you have been archiving the email this might have been simpler: Recover the email from the archive for the day in question, restore it to a different mailbox first; then check with the user, and delete all non-wanted email before restoring it to the Inbox.
 
You could even make a copy of the recovered email folder before transferring to the inbox. Then, if the problem recurs, you have a better starting point.
 
If you're not archiving the email, it's a good idea to start now.  Disk space is so cheap, and you can add a drive to the server if needed, specifying the location of a folder on that drive for just the archive data. It's saved my butt on many an occasion. As you know, email gets "lost" for all kinds of reasons.
 
Indeed, I recently "fixed" a disk space problem by adding a RAID1 pair of 1TB drives to an SM server, copying the archive files there, changing the archive location to that folder on the new RAID volume and then stopping/restarting the SM service (the Windows service, not from within the SM GUI - doing it through the SM GUI does not work!).
 
Just before restarting the service, I used FastCopy to update the archive's new location with any changes from the old location - this took seconds; it had been set up in advance. After verifying that the new location was receiving the archived files, I deleted the archive from the old location. Voila, about 450GB of new space (in my case of course) on the SM main volume.
 
Hope this is helpful going forward.
 
0
We backup the entire server every night. So I can just easily restore from a backup and be done with it. The GRP file at the time of the backup was even larger than the one in question. So my guess is the user moved some of the emails out to a separate folder. The big issue I am dealing with here is how to repair or rebuild the GRP file if it goes corrupt. Like in this instance. The other issue I just dealt with now is that SmarterMail has to chew on that large 308mb file to reindex so 0the user can see it in webmail. Well after an hour of attempting to reindex it, it never did. So I took the file out and I am going to put the previous night larger file in place and see what happens. This is frustrating to say the least.
0
rick Replied
Same problem here. I'm trialing the software and find it very buggy so far. Its very easy to hang the webmail up :-(
Not ready for prime time

Reply to Thread