Why is my M-Files not as fast as it used to be?

Note: This content is no longer updated. For the latest content, please go to the user guide for M-Files Online. For information on the supported product versions, refer to our lifecycle policy.

If M-Files users are experiencing noticeable performance issues in their day-to-day use of M-Files, carry out the procedures outlined below to pinpoint the potential source or sources of the problem. System slowness may be caused by various factors, such as hardware or infrastructure issues, vault structure or periodic maintenance operations, or issues related to opening views or files, and so on.

When contacting our support about performance issues, consider attaching the following information to your request:

Performance issues caused by factors related to hardware or infrastructure

Performance issues may be caused by hardware or infrastructure related problems. Inspect the following performance counters on the M-Files Server computer as well as the Microsoft SQL Server computer (if they are separate servers):

  • The page file usage: Use Performance Monitor to check the current and peak page file usage. Note that Windows always uses the page file no matter how much RAM you have, but if the page file peak usage is higher than around 10 percent, it may indicate that the system is at least periodically low on RAM or that RAM usage is excessive. See Inspecting Page File Usage in Performance Monitor for instructions on checking page file usage.
  • Current RAM usage via Windows Task Manager.
  • The CPU load via Windows Task Manager: If the load spikes close to 100 percent, the system may be under-resourced or some of the processes may be hoarding excessive amounts of resources.
  • The network connectivity between the server computers if M-Files Server and Microsoft SQL Server are running on separate servers. Network latency between the servers may cause noticeable slowness for the end users.
  • Make sure the Microsoft SQL Server instance has been assigned a memory limit. It should be set high enough to provide as much RAM for the SQL Server as possible but low enough to prevent the system from swapping. In general, leave from 3 to 4 GB for the host operating system and its services, and if M-Files Server runs on the same system, allocate from 2 to 3 GB for it and other processes. See Modifying the Memory Limit for a Microsoft SQL Server Instance for instructions on setting the memory limit for the Microsoft SQL Server instance.
    Note: These values are approximates and depend on multiple factors, such as the number of vaults, the use of server side vault applications, and so on.

Performance issues caused by vault structure or periodic maintenance operations

System slowness may also be caused by issues in the vault structure, and periodic maintenance operations may be perceived as performance issues by the end user.

The following factors related to vault structure or maintenance operations may cause (temporary) system slowness:

  • The metadata of the vault may not be optimal. There should not, for instance, be value lists with tens of thousands of entries or classes with hundreds of obligatory properties.
  • Modifying named access control lists causes the permissions of every affected document to be updated and may thus induce temporary system slowness.
  • Running background jobs like optimizations and backups may cause temporary slowness. These operations should not be run during high usage hours.
  • Having a large number of export and import jobs running at short intervals may cause performance issues.
  • The event log in M-Files Admin may be used to reveal instances of exceptional vault use, such as excessive number of file downloads.
  • For Firebird vaults, the metadata file size should be no larger than 2 GB per vault. See Registry Setting for Extending Firebird Usability for instructions on defining the maximum metadata file size and Checking the Size of a Firebird Metadata File for instructions on checking the metadata file size.

Performance issues in opening views or performing searches

Perform the following checks to verify if system slowness occurs in conjunction with opening views or performing searches:

  1. Use M-Files Desktop on the M-Files server computer and use Local Procedure Call as the protocol for connecting to the vault to rule out potential network-related issues. See Adding a Vault Connection for instructions on defining the vault connection and using Local Procedure Call as the protocol.
  2. Log in to the vault as a normal user, not as administrator, so that permission checks are not bypassed when using the vault and thus you can verify whether or not the issue is related to permission checks.
  3. Try to change the properties of a view, and then press ⇧ Shift + F5 to fully refresh the view. Try to modify different properties of views, such as filters or grouping levels, to see if the problem is related to views.
    Note: You can create a copy of an existing view so that you do not need to change the properties of the original view. Right-click a view of your choice and select Copy from the context menu, then right-click on an empty space in the listing area and select Paste from the context menu.