Nextcloud Instance is very slow

Nextcloud version: 20.0.7
Operating system and version: Debian GNU/Linux 10 (buster)
Apache or nginx version : Apache/2.4.38 (Debian), nginx/1.14.2
PHP version: 7.3

The issue you are facing:
I wanted to try out Nextcloud, so I installed it on a rather powerful VM (6-Core, 32Gb Ram, 1Tb SSD). But I am still facing performance issues, e.g creating a new text document takes about 10 seconds. Since I really doubt it’s the specs of my VM, I think I am missing some configurations / have misconfigured something. I am running Apache2 behind Nginx Reverse Proxy (both installed on the same machine), so I adapted the config/config.php file:

 'trusted_proxies' =>
  array (
    0 => '',
  'overwritehost' => '',
  'overwriteprotocol' => 'https',
  'overwrite.cli.url' => '',

The output of your Nextcloud log in Admin > Logging:
The only significant error I’m getting is this, but It’s from 3 days ago, so…

You are using a fallback implementation of the intl extension. Installing the native one is highly recommended instead.

I installed php-intl via apt, and the error never came up since, so it shouldn’t be a problem

Here’s my Nginx Configuration:

upstream backend {



server {


    listen [::]:443 ssl ipv6only=on;

    listen 443 ssl;

    ssl_certificate /etc/letsencrypt/live/;

    ssl_certificate_key /etc/letsencrypt/live/;

    ssl_stapling on;

    ssl_stapling_verify on;

    include snippets/headers.conf;

    include snippets/ssl-options.conf;

    location / {

        proxy_headers_hash_max_size 512;

        proxy_headers_hash_bucket_size 64;

        proxy_set_header Host $host;

        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        add_header Front-End-Https on;

        proxy_pass http://backend;



server {

    if ($host = {

        return 301 https://$host$request_uri;


    listen 80;

    listen [::]:80;


    return 404;


Hi @harrytuttl

I fear we need some more information about your setup. Some starting points:

Do you have caching enabled, is there a Redis server running, are static files served by Apache directly, what database are you using and how much memory do you have allocated for it?


Hi @simonspa,

thank you for your reply. Yes, I have Caching enabled, I installed php-apcu, since it was recommended in the documentation (Memory caching — Nextcloud latest Administration Manual latest documentation). Should I rather use a Redis server to increase performance? The static files are all served by Apache and I’m using MySQL (Version 8.0.23) as a database. I have allocated 8Gb of Ram to it, by adding the following line to my my.cnf:

innodb_buffer_pool_size = 8192M

If you need any more information, please let me know

Edit: I ran a MySQL Performance Script, here’s the important output:

-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 52s (481 q [9.250 qps], 33 conn, TX: 3M, RX: 79K)
[--] Reads / Writes: 99% / 1%
[--] Binary logging is enabled (GTID MODE: OFF)
[--] Physical Memory     : 31.4G
[--] Max MySQL memory    : 25.6G
[--] Other process memory: 0B
[--] Total buffers: 16.0G global + 65.1M per thread (151 max threads)
[--] P_S Max memory usage: 72B
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 16.2G (51.43% of installed RAM)
[OK] Maximum possible memory usage: 25.6G (81.61% of installed RAM)
[OK] Overall possible memory usage with other process is compatible with memory available
[OK] Slow queries: 0% (0/481)
[OK] Highest usage of available connections: 1% (2/151)
[!!] Aborted connections: 3.03%  (1/33)
[!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance
[--] Query cache have been removed in MySQL 8
[OK] No Sort requiring temporary tables
[OK] No joins without indexes
[OK] Temporary tables created on disk: 0% (0 on disk / 23 total)
[OK] Thread cache hit rate: 93% (2 created / 33 connections)
[OK] Table cache hit rate: 81% (346 open / 427 opened)
[OK] table_definition_cache(2000) is upper than number of tables(432)
[OK] Open file limit used: 0% (2/10K)
[OK] Table locks acquired immediately: 100% (4 immediate / 4 locks)
[OK] Binlog cache memory access: 100.00% (3 Memory / 3 Total)