Hit ENTER after each Tag to add it to your post; Numbers in parentheses represent the Tag's usage.
I had a user call in today with a slow webmail issue with SmarterMail 14.5.5907. So I checked the users mailbox and sure enough when I either impersonate that user or login with their credentials webmail is slow to populate the Inbox only. So I connected into the server directly and found that their GRP file for today is 1.3GB in size.
So I ran a report in SmarterMail and found this is the delivery logs for the past several hours:
[2016.04.05] 15:28:47  Starting local delivery to firstname.lastname@example.org
[2016.04.05] 15:28:47  Add message to mailbox call failed. Reason: Access to the grp file is locked
[2016.04.05] 15:28:47  Delivery attempt to email@example.com to folder 'Inbox' failed. Mailbox is locked.
Now we are running anti-virus on the mail server and I do have a rule setup to exclude all SmarterMail folders. This includes the actual user folders along with the program directory. Once I restarted the IIS 7.5 service then webmail populates fine. I also found that webmail for all users was slow before I restarted the IIS service. So this one user was slowing down the entire web service all because the GRP file was so huge? I verified this by logging into another machine and tried going to our webmail landing page and it just sits there while the user with the huge GRP file was logged into webmail attempting to view their Inbox. Only way I have been able to correct the slowness was to restart IIS and then everything is good again. That is until this user with the huge GRP (1.3GB) file logs in again and tries viewing their Inbox. Then the process repeats itself.
Checking through the taskmanager on the server itself here's the memory usage for both IIS and SmarterMail:
w3wp.exe 605MB and mailservice.exe 1.2GB
We have 16GB of ram installed on this box so memory is not the issue. We are also running a Intel core I7 processor. Both memory usage and CPU usage have been normal even through the issue I stated above. I have seen this same exact situation happen about a month or so back with another user that had a huge GRP file. The only fix I could find at the time was to remove the GRP file. I don't want to keep doing this and have users lose important email all because the file size of a GRP file got too big. Compound this by several users and I have a bunch of angry users. When I looked at the index status in SM it was stuck trying to index that entire 1.3 GB GRP file for this user and appeared to not show any progress. It though only 1 email had to be indexed and I am sure there was more in that file than just that.
Any one else run into this issue? If so what was the fix for it?
Also while we are on the subject of GRP files, any plans for the future to have large GRP files broken up into smaller chunks instead of lumping it all into one file for that day? Basically right now I have a user that can't use webmail because their session ends up holding up the entire web interface for everyone we host all because the GRP file is too big. Eventually the user with the huge GRP file will get the "Ooops something went wrong message" if they wait long enough trying to view their Inbox. Which appears to crash the web interface for them. Everyone else just has to wait several minutes before they get the log in page for SM and it's slow to log in. Restarting IIS resolves this but seems like a band aid for the overall problem. The GRP gets too big and SM has a hard time handling it properly.