Phone Lines icon GFI Support Home

Articles in this section

See more

GFI MailEssentials | Backend Service Using High CPU Usage or Unresponsive When Stopping/Starting

Author: Osama Malhi Updated

Overview

This article explains the resolution for abnormally high CPU usage or slow/unresponsive backend service when stopping or starting.

 

Root Cause

This issue generates from the use of incorrect database format for reporting.

 

Process

Backend service causing high CPU is usually associated with the reporting database.

 

Solution I

On the WebUI > Reporting > Settings, if using the built-in Firebird database, ensure that the path exists and that the filename ends with .fdb.

While the UI will not validate any path that does not exist or ends with a .fdb, it can happen when upgrading to the latest version from an unsupported upgrade path, such as 2014 or older to version 21.

In this scenario, we would see the path ending with reports.mdb instead of reports.fdb.

 

Solution II

When MailEssentials scans thousands of emails per day, it is recommended to use SQL rather than the built-in database or reduce the default 12 months retention with auto-purge. For more information, please see Configuring reporting database.

In this scenario, the firebird database is either full or unresponsive.

This can be confirmed by checking the number of pending items stores in the Microsoft Message Queue (MSMQ) private queue gfimereportq@#.

  1. Navigate to Start > Run, type compmgmt.msc, and click on OK. The Computer Management Microsoft Management Console (MMC) will open.
  2. Go to the Services and Applications node and browse to Message Queuing.
  3. Open the Private Queues.
  4. Here, there should be the MailEssentials queues, 10 in total for reporting.

 

Option 1

  1. Set auto-purge to less than 12 months.
  2. Change the filename under WebUI > Reporting > Settings.
    • for example from reports.fdb to reports2.fdb
  3. Wait for the gfimereportq@# queues to clear to the new database.
Note: Changing the database will create a new database and use only that one to show reporting.

 

Option 2

  1. Set auto-purge to less than 12 months.
  2. In the MSMQ private queues, expand each gfimereportq@# queue. Two new nodes will appear, Queue Messages and Journal Messages.
  3. Right-click on Queue Messages, and select All Tasks > Purge.
  4. A confirmation window will appear. Press OK to clear all messages in the queue.
  5. Repeat these steps for all gfimereportq@# queues.
  6. Refresh the private queues and ensure they are all showing zero (0) items.
Note: Purging the gfimereportq@# queues means that the pending items will not be saved to the reporting database, and the information would be lost. This is only for reporting, and on the Dashboard > Logs tab, the data is not affected.

 

If the issue persists, contact support.

 

Confirmation

The CPU usage will be back to "normal".

 

Back to top

Related articles