Phone Lines icon GFI Support Home

Articles in this section

See more

Troubleshooting Performance Issues in Kerio Connect

Author: Vladyslav Velychko Updated

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 {} \;

    mceclip1.png
    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

    mceclip2.png
    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/ 

    mceclip0.png

    You can also refer to an example of Output/Script analysis, to understand the expected output of the script.

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.

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.

      default_tasks_max.png

    • Make sure that /sys/fs/cgroup/pids/system.slice/kerio-connect.service/pids.max is set to max.

      pids_max.png

    • 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.
  • 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:

    mceclip3.png

 

Related Articles

Related articles