Overview

This article shares information for troubleshooting the typical performance issues of Kerio Connect, for example:

• Kerio Connect server issues (high CPU or RAM usage, automatic restarts, and crashes - segmentation faults, server inaccessible or down, too many connections, out of storage or storage occupied is not correct, etc.)
• Folder Corruption issues (user account is slow and cannot reindex, Kerio mailboxes expanding to enormous sizes, a specific account is not syncing, failed to open the GAL folder, mailboxes appear empty, failed to load shared folders, etc.)
• Email client-related issues (Outlook is freezing, webmail is not loading, unable to use Kerio Connect Client, etc.)
• Mailflow-related issues (mail is not being received, mail stops working randomly, taking a very long time to receive emails, etc.)
• Webadmin configuration-related issues (MailServer freezes when creating or deleting a mailbox)

Information

Checking the server user data

It is recommended to run the stat-check script to eliminate environmental issues. The best practice is to have a maximum of 10,000 items in each folder (e.g., Inbox, Sent Items, Calendar) and this is one of the aspects that the script checks for.

Note: The stat-check.sh script is built for running in the store/mail folder on a Kerio Connect server, on a UNIX-style server (such as Linux or macOS). If the server is Windows-based, the information can be gathered and analyzed outside of the Kerio Connect server. The script will gather information from each status.fld file that exists in the store and will organize the information in an easy-to-read manner.

Each folder in the store location of Kerio Connect contains a status.fld file, which holds folder-specific information that can help in troubleshooting performance issues. The status.fld files can be collected from Kerio Connect using the below commands:

• For Linux/macOS, we can use the find command in the <Kerio install folder>/store/mail:
  find . -name status.fld -exec tar rvf status.tar {} \;
  
  
  This will create a status.tar file containing all the status.fld files, while retaining the folder structure, and the resulting file will be located in the same folder where the command was run from.
• For Windows, we can use xcopy in the <Kerio install folder>\store\mail:
  xcopy *status.fld d:\status\*.* /S /E /V
  
  
  The status.fld file structure would go to D:\status\ in this case, any path of your choosing can be used. The resulting folder will need to be zipped for transferring it to a machine capable of running the script.
• The resulting archive can either be sent to the support team for analysis, or it can be uncompressed into a pretend external store folder in a UNIX-style server (macOS or Linux), where stat-check.sh can be run.
• The script first needs to be made executable by running a chmod +x stat-check.sh command via Terminal, and then we can run the script: ./stat-check.sh status/ 
  
  
  
  You can also refer to an example of Output/Script analysis, to understand the expected output of the script.
  
  • Each section of the output is self-explanatory and can assist in pinpointing the root cause of the performance issue and several possible solutions can be found in the article: Kerio Connect mailserver is causing unexpected high CPU, RAM leaks or crashes.

Checking the hardware

As a next step, it is recommended to check the server hardware specifications - RAM, CPU, and disk speed, to also cover the hardware aspect. The server needs to meet the Kerio Connect Server Requirements, depending on the number of user accounts in the server.

• To measure the disk performance, we can use the following third-party knowledge articles:
  
  • Windows Server 2008 R2
  • Windows Server 2012 and up
  • macOS
  • Linux

Other known scenarios and best practices

• For crashes on Linux systems (mainly on Ubuntu 18.04 and up), it is recommended to modify the following Systemd and PIDs settings:
  • Set DefaultTasksMax to infinity in /etc/systemd/system.conf.
    
    
    
    
  • Make sure that /sys/fs/cgroup/pids/system.slice/kerio-connect.service/pids.max is set to max.
    
    
    
    
  • It is recommended to restart the Linux machine to apply all the mentioned above changes.
    
    
• For 0% CPU/RAM usage in the dashboard histograms, it is known Kerio Connect process does not crash at that point. That is the result of a resource bottleneck/deprivation, where all the server resources are invested in core functionality in order to keep the server's main functions alive. The Kerio dashboard is a reporting function that is not vital, therefore, the dashboards are not being updated anymore in these situations. While it might sound unusual, a 0% in the Kerio dashboard histograms actually implies a 100% CPU/RAM usage. This behavior is usually called Kerio flatline.
  
  • Troubleshooting this behavior requires Checking the server user data and working our way down from there.
• For macOS users (configured with an EWS profile either in Mac Mail or Outlook for Mac), there might be issues with the synchronization state, which can be noticed in the Error log:
  
  
  
  
  • For resolving common EWS (Exchange Web Services) related issues, follow these steps:
    • Delete the EWS (Exchange Web Services) account from Mac Mail or Mac Outlook app.
    • Restart the Kerio Connect service. 
    • Recreate the EWS profile.

Related Articles

• High RAM Usage in Kerio Connect
• Kerio Connect Service Crashes and Restarts
  
• XMPP Services Not Starting in Kerio Connect
  
• Error: '1920 Service Kerio Connect (KerioMailServer) failed to start' When Starting Kerio Connect
  
• Server Error: Your Full-Text Index Is Being Re-Indexed. This Operation Can Take a While