Porque é que o Nextcloud parece lento, e o que o corrige de facto

Quando uma instância Nextcloud parece lenta, o primeiro instinto é dar-lhe mais CPU e memória. Normalmente isso não muda nada, porque o tempo está a ir para outro lado: background jobs a correr no sítio errado, uma cache que não está configurada, file locks a bater na base de dados, uma tabela sem índice. Esta é a ordem pela qual verificamos as coisas, com as definições que corrigem cada uma. Tudo o que se segue aplica-se quer o Nextcloud corra num servidor simples quer em containers.

Comece pelo que o Nextcloud já lhe diz

O Nextcloud traz as suas próprias verificações de saúde. Corra-as antes de alterar seja o que for:

sudo -u apache php occ setupchecks
sudo -u apache php occ status

Use o utilizador do web server (apache, www-data ou nginx, consoante o seu sistema). Os mesmos resultados aparecem nas definições de administração, em Visão geral. Cada aviso ali é uma descoberta real. Corrija-os primeiro. Vários dos pontos abaixo vão aparecer nessa lista.

Os background jobs não devem andar à boleia dos page loads

O Nextcloud tem tarefas de manutenção a fazer: varrimentos de ficheiros, previews, notificações, limpezas, expiração de atividade. Por omissão, em modo AJAX, corre uma tarefa de cada vez que um utilizador carrega uma página. Os utilizadores pagam a manutenção com os seus próprios page loads, e numa instância calma as tarefas ficam para trás.

Mude para system cron:

sudo -u apache php occ background:cron

Depois corra o cron.php a cada cinco minutos. Um systemd timer é mais limpo do que uma entrada no crontab porque regista as falhas:

# /etc/systemd/system/nextcloud-cron.service
[Service]
Type=oneshot
User=apache
ExecStart=/usr/bin/php -f /var/www/nextcloud/cron.php

# /etc/systemd/system/nextcloud-cron.timer
[Timer]
OnBootSec=5min
OnUnitActiveSec=5min
[Install]
WantedBy=timers.target

Ative-o com systemctl enable --now nextcloud-cron.timer. Já que está nisso, defina uma janela de manutenção para que as tarefas pesadas corram de noite:

sudo -u apache php occ config:system:set maintenance_window_start --type=integer --value=1

O valor é uma hora em UTC. As tarefas pesadas correm nas quatro horas seguintes.

Caching e file locking

Sem uma memory cache, o Nextcloud pede à base de dados as mesmas coisas vezes sem conta. Sem um locking backend adequado, cada operação de ficheiro também obtém um lock na base de dados. Configure ambos no config.php:

'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
  'host' => '/run/redis/redis.sock',
  'port' => 0,
],

O APCu é a cache local rápida dentro de cada processo PHP. O Redis guarda o estado partilhado e os file locks. Use um Unix socket se o Redis estiver na mesma máquina, e garanta que o utilizador do web server o consegue abrir.

O APCu também precisa de ser ativado para a linha de comandos, ou o occ queixa-se:

; /etc/php.d/40-apcu.ini
apc.enable_cli=1

O próprio PHP: OPcache e o pool FPM

O Nextcloud é uma aplicação PHP grande. Sem OPcache suficiente, o PHP recompila partes dela em cada pedido. Valores iniciais típicos:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60

O setupchecks diz-lhe se o interned strings buffer é demasiado pequeno. Depois dimensione o pool PHP-FPM para a memória que realmente tem: pm.max_children multiplicado pela memória típica de um worker PHP tem de caber na RAM com espaço para a base de dados e o Redis. Meça a memória real de um worker sob carga antes de escolher, em vez de copiar um número de um fórum.

A base de dados: índices e big integers

As atualizações acrescentam por vezes índices e colunas que as instalações existentes não recebem automaticamente, porque criá-los numa tabela grande demora tempo. O Nextcloud deixa esse passo consigo:

sudo -u apache php occ db:add-missing-indices
sudo -u apache php occ db:add-missing-columns
sudo -u apache php occ db:add-missing-primary-keys
sudo -u apache php occ db:convert-filecache-bigint

Corra-os depois de cada atualização major, numa janela de manutenção, porque podem bloquear tabelas grandes. Um índice em falta na tabela da file cache é uma das razões mais comuns para uma instância grande parecer lenta ao navegar nas pastas.

Previews: gere-as antecipadamente

As miniaturas são geradas na primeira vez que alguém abre uma pasta. Uma pasta de fotografias de alta resolução significa uma primeira visita lenta para quem lá chegar primeiro. Duas coisas ajudam. Limite os tamanhos das previews:

sudo -u apache php occ config:system:set preview_max_x --value=2048 --type=integer
sudo -u apache php occ config:system:set preview_max_y --value=2048 --type=integer

E, se os seus utilizadores guardam muitas imagens, use a aplicação Preview Generator para criar as previews no background job em vez de a pedido.

O editor de documentos é uma carga de trabalho própria

A edição no browser com Collabora corre como um serviço separado. O Nextcloud envia-lhe o documento, e o Collabora renderiza-o e edita-o. Quando as pessoas dizem «o Nextcloud está lento» enquanto editam, o estrangulamento é normalmente o Collabora, não o Nextcloud. Observe a sua CPU e memória em separado, enquanto várias pessoas editam folhas de cálculo grandes ao mesmo tempo, e dimensione-o a partir dessas medições.

Dois pontos de configuração importam tanto para a velocidade como para a segurança. Aponte o Nextcloud ao Collabora por um caminho que seja rápido e próximo. E restrinja que servidores podem falar com a interface WOPI do Collabora:

sudo -u apache php occ config:app:set richdocuments wopi_allowlist --value="10.0.0.0/24"

Use ali o intervalo de endereços do seu próprio servidor Nextcloud, para que só o seu Nextcloud possa abrir documentos através do seu editor.

Fixe o que corre

Se corre o Nextcloud em containers, fixe cada imagem (Nextcloud, base de dados, Redis, Collabora) a uma tag escolhida por si.

A ordem, em resumo

1. occ setupchecks e corrigir todos os avisos.
2. System cron através de um timer, mais uma janela de manutenção.
3. APCu localmente, Redis para locking e cache partilhada.
4. OPcache bem dimensionada e um pool FPM dimensionado a partir de medições.
5. Índices, colunas e chaves em falta acrescentados depois de cada atualização.
6. Previews limitadas e geradas em background.
7. Collabora medido e dimensionado como serviço próprio, com uma allow list WOPI.
8. Cada componente fixado a uma versão escolhida por si.

Só depois de tudo isso é que acrescentar hardware lhe diz algo útil. É assim que operamos o Nextcloud com Collabora para os nossos clientes em instâncias dedicadas, e teremos todo o gosto em olhar para a sua.

Fale com um engenheiro

Relacionados: Managed Nextcloud para documentos de escritório · Arquivo de e-mail privado com pesquisa por IA local