Connect. Communicate. Collaborate. Securely.

Home » Kerio User Forums » Kerio Connect » Serious problem since 9.03 (Message queue backlog)
  •  
Bud Durland

Messages: 349
Karma: 37
Send a private message to this user
We upgraded to 9.03 over the weekend (just before 9.04 was released, such is our luck). Since then, we have had a lot of trouble with delays processing the message queue. The queue climbs into the hundreds of messages, and it often takes several HOURS for mail to be delivered.

We are using Debian 7, and the mail store is on a 3TB btrFS volume. This was working fine with version 8.5.3.

Is this one of the 'stability issues' that was corrected in version 9.04? I'd rather not downgrade unless I really have to. I don't want to confuse and annoy users by flip-flopping between web mail interfaces.

I'm being told to fix it now, and it doesn't help that we just had a consultant on-site preaching O365.
  •  
Pavel Dobry (Kerio)

Messages: 5141
Karma: 241
Send a private message to this user
There is no known bug in 9.0.3 that can cause queue size growing. I recommend checking the status of emails in the queue, mail log and also debug log with "Queue operations" messages.

[Updated on: Fri, 13 May 2016 17:13]


Knowledge Base: http://kb.kerio.com/.
Technical support: http://www.kerio.com/support
------------------
Stay Connected Anytime, Anywhere. Discover Kerio Cloud!
  •  
Bud Durland

Messages: 349
Karma: 37
Send a private message to this user
Nothing in the Debug log stands out as an error. Ditto the Mail log. In the queue monitor, the status is either blank or 'recipient's mailbox busy'. The busy message makes up about 45% of the messages in the queue, and it is many users.

Update:
Searching for 'error' or 'fail' in the debug/queue processing log finds only a message about failing to 'encode the x-ffoter header for the domain'

Searching 'Delay' shows many delays for 'mailbox busy' as shown above.

Update 2:
We tried to remove some messages from the queue. Now they are still there, but are displaying "Spoofed Sender Check Cannot be Performed". We do not have spoofed sender checking enabled in the security tab of the admin page.

[Updated on: Fri, 13 May 2016 19:19]

  •  
Bud Durland

Messages: 349
Karma: 37
Send a private message to this user
One of the things I've noticed is that there is a significant delay ('Outlook Not responding') when messages are sent. I see it hit the outbox folder, but it sometimes takes a a minute or more to recover and send the message. I see nothing of interest in any of the server logs, but my local KOFF debug log has these lines, but I'm not sure what they mean. Extra spaces removed for readability:

[16/05/2016 11:05:27.592](9628){err}{convertor} In MapiConvertor\MapiConvertor.cpp:238 (storeFromMapiToMime)
[#216] (B59E)  Exception of class HResultException: MapiConvertor\MapiName.cpp(46), MapiName::fromPropertyTag: 0x80004005 E_FAIL // Conversion has failed.

[16/05/2016 11:05:27.593](9628){err}{scp-worker} In SCProvider\ConvertorHelper.cpp:272 (ConvertorHelper::convertMapiStore)
[#217] (B59E) Exception of class HResultException: SCProvider\ConvertorHelper.cpp(266), ConvertorHelper::convertMapiStore: 0x80004005 E_FAIL // HRESULT: 0x80004005 E_FAIL

[16/05/2016 11:05:27.593](9628){err}{scp-worker} In SCProvider\Worker_msgstore.cpp:88 (SyncRequestStore::processSyncMsgStore)
[#218] (B59E) Exception of class HResultException: SCProvider\Worker_msgstore.cpp(229), SyncRequestStore::putStoreToServer: 0x80004005 E_FAIL 

[16/05/2016 11:05:27.593](9628){err}{scp-worker} In SCProvider\Worker_refresh.cpp:314 (SyncRequestRefresh::testResultSynchronizedPersonalStore)
[#219] (B59E) Personal store synchronization failed, proceeding to synchronization of hierarchy. 
  •  
j.a.duke

Messages: 335
Karma: 10
Send a private message to this user
Bud Durland wrote on Fri, 13 May 2016 11:38
Nothing in the Debug log stands out as an error. Ditto the Mail log. In the queue monitor, the status is either blank or 'recipient's mailbox busy'. The busy message makes up about 45% of the messages in the queue, and it is many users.


Bud,

I was seeing this with 8.5.x on a Mac Mini with a software RAIDed ThunderBolt enclosure.

I fixed the problem by moving to a hardware RAIDed ThunderBolt enclosure and upgrading to 9.0.x.

My mailbox busy issue would move between accounts-there were 4 or 5 repeaters, but often the culprit would be a random account. A reboot would cure the problem for about a day or two before it returned.

How full is your mail store volume?

I'm trying to remember all the variables that contributed to the issue, but in the end, it seemed to come down to both disk speed and KC version.

Cheers,
Jon
  •  
Bud Durland

Messages: 349
Karma: 37
Send a private message to this user
j.a.duke wrote on Mon, 16 May 2016 11:41


How full is your mail store volume?

I'm trying to remember all the variables that contributed to the issue, but in the end, it seemed to come down to both disk speed and KC version.


As far as we can tell, we've slao come to the conclusion that it is a disk issue. In this case the volume is on a SAN configured to support VMWare HA. The SAN supports many other VM's, and we're working on the conclusion (based in part of observation) that the I/O channel to the SAN is saturated. We're moving our mail store (3.0 TB, 1.3TB used) to a different, more lightly loaded SAN to see if that helps.

We're also changing the volume's file system from BTRFs to Ext4. I'm not sure if that's a factor, though. We had switched from EXT4 to BTRfs when we increased the size of the mail store, hoping for better performance. It ran fine under 8.5x, though we didn't really see any performance increase. It was when we upgraded to 9.03 that we started having trouble. I don't know that the file system has any impact in this case, but we're switching back to make sure.
Previous Topic: Contacts being saved to public folder on iPhone?
Next Topic: Android and PC setup help for email problem
Goto Forum:
  


Disclaimer:
Kerio discussion forums are intended for open communication between forum members and may contain information and material posted by members which may be useful in learning about Kerio products. The discussion forums are not intended to provide technical support for any specific product. Any information implied or expressed in the discussion forums is that of the posting member. Kerio is in no way responsible for the information posted in the forums, or its accuracy. Kerio employees may participate in the discussions, but their postings do not represent an offical position of the company on any issues raised or discussed. Kerio reserves the right to monitor and maintain the forums to promote free and accurate exchange of information.

Current Time: Fri Dec 02 20:51:55 CET 2016

Total time taken to generate the page: 0.00937 seconds
.:: Contact :: Home ::.
Powered by: FUDforum 3.0.4.