Overview

Mailserver service may occupy full CPU capacity and increase Memory usage, resulting in Kerio Connect server (mailserver.exe process) crashes, freezes, segfaults, high CPU, and RAM load. As an outcome, System Health shows all resources being busy and the server's intermittent stops and errors.

Even with low mail traffic, Kerio Connect may face corrupted Fulltext database issues or delayed sync and slow send/receive emails' processing. Problems might be caused by the last update (OS or Kerio Connect software).

Solution

Due to various factors, the Kerio Connect process may experience intermittent issues. The most common reasons are:

• OS or hardware
• Large Calendar .eml files
• Duplicate hyperlinks within Calendar invites
• Improper setup of macOS EWS account
• High Open Folder Reference count
• Database (.journal.db) or index (index.fld) corruption

The mailserver process can be consuming all the server resources in order to attempt to fix all of the above issues. It may cause CPU and RAM bottleneck, which may result in a System crash.

You need to have Admin access to the Kerio Connect server before proceeding with the below steps to resolve the crash issue:

1. As general best-practice, we recommend keeping your OS up-to-date and fully patched. This way all Security requirements are met. It is also advisable to perform regular reboots once each 3-6 months, depending on the server stability. Other specific OS considerations:
   • Windows: review Event Viewer logs for more information about System Errors and Crashes
   • Linux: decide which process should be stopped. For more information, please review the Linux OOM Killer article.
   • macOS: see real-time CPU, network, disk statuses in the Activity Monitor.
2. It is also recommended to keep Kerio Connect updated to the latest version. More information on the latest available version can be found on our product releases page.
3. Several reports received about the EWS account in macOS causing high CPU usage. It's recommended to re-configure the accounts and check the Folder Items limits (10,000 maximum).
4. Large Calendar .eml files (over 100 MB) with attachment inside it. It's recommended to review the Calendar folders for particular users (they also might have a high Reference Folder). Then remove the identified .eml files or move them to another folder.
   For Linux/macOS, you can use the standard ls -lSh command to sort the files by size:
   
   For Windows, you can sort the files by size by clicking on the Size column:
   
   

   Note: If your Calendar event/s had hyperlink duplication within invites, then the already affected calendar items can still cause resource starvation even on the server that is updated to version 9.3 (where the issue was fixed). There isn't a way to find these events. However, this issue wouldn't be there with new Calendar events created after the update.

5. User Folder corruption that caused High Open Reference Folder count. For more information, please refer to Slow Folder Performance issues.
6. Internal .journal.db and  properties.fld clean-up. Older obsolete properties files, which are no longer used, may slow down the system. You can use standard Windows and Linux/macOS commands to remove these files altogether:
   
   1. Find the files:
      • Windows:
        dir "C:\Program Files\Kerio\MailServer\store\mail\properties.fld*" /s
      • Linux/Mac:
        find /opt/kerio/mailserver/store/ -name 'properties.fld' -print
        
   2. If there are any files found, consider running the below delete command:
      

      Note: The Kerio Connect engine should be stopped before the deletion.

      • Windows:
        del "C:\Program Files\Kerio\MailServer\store\mail\properties.fld" /s
        
      • Linux/Mac:
        find /opt/kerio/mailserver/store/ -name 'properties.fld' -print -delete
        
   3. A similar find and fix procedure can be executed for .journal.db files:
      • Windows:
        dir "C:\Program Files\Kerio\MailServer\store\mail\*journal.db" /s
del "C:\Program Files\Kerio\MailServer\store\mail\*journal.db" /s
      • Linux/Mac:
        find /opt/kerio/mailserver/store/ -name '*journal.db' -print
find /opt/kerio/mailserver/store/ -name '*journal.db' -print -delete

Testing

The system performance is back to normal.