Home
» Come fare
»
Impedisci a ONLYOFFICE Document Server di esaurire la memoria del VPS.
Impedisci a ONLYOFFICE Document Server di esaurire la memoria del VPS.
Se ONLYOFFICE Document Server si arresta in modo anomalo o si riavvia a causa dell'esaurimento della memoria del VPS, innanzitutto verifica che si verifichi un evento di memoria insufficiente e controlla se il limite di memoria di Docker è troppo basso. Quindi, fornisci una quantità di RAM fisica sufficiente per il carico di lavoro e aggiungi lo swap solo come margine di sicurezza; riavviare ripetutamente l'editor non risolverà una persistente carenza di capacità.
1. Dimostrare che la pressione della memoria sta causando il guasto
Avviare il processo sul VPS Linux, non nelle impostazioni di integrazione di ONLYOFFICE. Un messaggio del browser come "Impossibile caricare il documento" può anche essere causato da problemi di rete o di autenticazione, quindi è importante verificare se il gestore di errori di memoria insufficiente (OOM) di Linux ha effettivamente terminato un processo.
Esegui questi comandi tramite SSH. Sostituisci onlyoffice-document-servercon il nome del container mostrato da docker ps -a:
free -hMostra la RAM e lo swap disponibili sull'host. docker statsMisura un container in esecuzione, mentre il comando inspect riporta lo stato di terminazione per OOM del container, l'ultimo codice di uscita e i limiti di risorse configurati in byte. Un HostConfig.Memoryvalore diverso da zero indica un limite di memoria esplicito. La statistica della memoria di Docker potrebbe escludere alcune cache di file, quindi dovrebbe essere confrontata con le misurazioni dell'host piuttosto che essere considerata come un quadro completo. Consultare la documentazione di riferimento sulle statistiche di Docker .
Esempio di verifica della memoria: confrontare la RAM disponibile dell'host con l'utilizzo e il limite del contenitore del server di documenti; i valori visualizzati sono a scopo illustrativo.
Se il container si è arrestato, docker statsnon è possibile visualizzare il suo picco precedente. Controllare invece il log del kernel e i messaggi recenti dell'applicazione:
I messaggi del kernel che menzionano "Memoria insufficiente" o "Processo terminato" aiutano a identificare il processo coinvolto. OOMKilled=trueSono una forte prova di un evento di memoria insufficiente (OOM) del container, ma falsenon escludono che il kernel dell'host possa terminare un processo figlio mentre il container rimane attivo. Allo stesso modo, il codice di uscita 137 indica solo una terminazione SIGKILL, non la sua causa. Se non vi sono prove di OOM, è consigliabile esaminare i log e gli errori di connessione prima di acquistare ulteriore RAM.
Esempio di indagine su un errore di memoria insufficiente (OOM): esaminare lo stato del container e i messaggi del kernel anziché diagnosticare un errore di memoria basandosi esclusivamente su un errore del browser.
2. Assegna al VPS una quantità di RAM sufficiente prima di configurare qualsiasi altra cosa.
A ottobre 2026, il file README del Docker Document Server ufficiale di ONLYOFFICE elenca tra i requisiti consigliati 4 GB o più di RAM e almeno 2 GB di swap. La documentazione ufficiale separata per l'installazione one-click indica 4 GB di RAM per gli ambienti di test Docker, raccomanda 8 GB o più per la produzione e specifica almeno 4 GB di swap nei requisiti di installazione. Questi documenti descrivono contesti di implementazione diversi, quindi 4 GB non devono essere interpretati come una garanzia di prestazioni affidabili in produzione.
Se il tuo VPS ha solo 1-2 GB di RAM, l'aggiornamento del piano è la soluzione più sensata per un'installazione basata su Docker. Se invece ha già 4 GB, verifica quanta ne viene utilizzata dal sistema operativo, dal database, dal reverse proxy, da Nextcloud e dagli altri container. Un server che sembra funzionare bene in modalità inattiva potrebbe comunque esaurire la memoria quando più persone aprono documenti o convertono fogli di calcolo di grandi dimensioni contemporaneamente.
Su un host con un carico elevato, utilizzare questo strumento ps aux --sort=-rss | headper identificare i processi che consumano molta memoria e ripetere la procedura docker statsdurante una sessione di editing rappresentativa. Riservare risorse per il resto della macchina anziché assegnare tutta la RAM disponibile a ONLYOFFICE. Se la domanda continua supera la capacità dell'host, spostare i servizi concorrenti o aggiornare il VPS; una modifica a livello di applicazione non può creare la memoria fisica mancante.
Verifica la presenza di un limite di memoria Docker accidentale.
I container Docker non hanno un limite di memoria rigido per impostazione predefinita, ma un deployment può impostarne uno tramite `docker run` --memoryo `compose` mem_limit. Ad esempio, un limite di 2 GB per un container può causare errori di memoria insufficiente (OOM) anche quando un host con 8 GB di RAM libera dispone di RAM libera. Prima di modificarlo, verifica il limite effettivo. Se il limite è eccessivamente basso, regola la configurazione originale di `docker run` o `compose` a un valore giustificato da misurazioni e dalla capacità residua dell'host. Consulta la documentazione di Docker sui vincoli di risorse e le specifiche del servizio `compose` .
Non impostare ciecamente un'allocazione di memoria illimitata su un VPS condiviso: ciò può esporre altri servizi a interruzioni per esaurimento della memoria a livello dell'host. Controlla anche --memory-swaple impostazioni di Compose memswap_limit; Docker considera la RAM e lo swap combinati in tale impostazione. Limiti uguali per RAM e swap combinati disabilitano di fatto lo swap per il container. Se gestisci ONLYOFFICE con Compose, apporta la modifica al relativo file Compose in modo che l'impostazione venga mantenuta anche dopo la ricreazione del container.
3. Aggiungi un buffer di swap se il VPS non ne ha
Lo swap può assorbire un picco temporaneo di memoria, ma viene memorizzato su disco ed è molto più lento della RAM. Verificalo swapon --showprima df -h /. L'esempio seguente aggiunge un file di swap da 2 GiB a un VPS utilizzando un filesystem locale compatibile come ext4, quando /swapfilenon esiste già e il provider consente lo swap:
Rendi permanente il nuovo file di swap solo dopo che swaponl'operazione è andata a buon fine. Verifica la presenza di una voce esistente con grep -F '/swapfile' /etc/fstab; se non esiste, aggiungila una sola volta:
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
La creazione di file di swap su Btrfs, filesystem di rete e altre configurazioni richiede una gestione diversa. Non eseguire questi comandi su un file di swap esistente e non dare per scontato fallocateche funzionino ovunque. Il manuale di swapon per Linux spiega le restrizioni relative ai filesystem. Se il VPS utilizza regolarmente lo swap con un carico di lavoro di editing normale, è preferibile dare priorità a una maggiore quantità di RAM piuttosto che a un file di swap più grande.
Esempio di verifica dello swap: il dispositivo di swap e lo swap totale sono visibili, ma la sola presenza dello swap non dimostra che la capacità della RAM sia sufficiente.
4. Ricontrollare il server con un carico di lavoro di modifica realistico
Spesso, la modifica di un piano VPS o l'attivazione dello swap non richiedono alcuna modifica alla configurazione di ONLYOFFICE. Se hai modificato un'impostazione di distribuzione Docker, pianifica la manutenzione e conserva i mount, i segreti, i percorsi dei certificati e le impostazioni di integrazione esistenti durante l'applicazione. Il file README di ONLYOFFICE Docker descrive documentserver-prepare4shutdown.shgli arresti pianificati e avverte che la disconnessione degli editor può richiedere diversi minuti. Non ricreare o riavviare casualmente un server di documenti in uso, poiché le modifiche non salvate potrebbero essere compromesse.
Quando il servizio è pronto, verifica che il container sia in esecuzione e controlla nuovamente la sua memoria:
L'ultimo controllo utilizza l'endpoint informativo interno mostrato nel controllo di integrità ufficiale di ONLYOFFICE per Docker Compose ; eseguilo all'interno del container perché la porta 8000 potrebbe non essere pubblicata sul VPS. L'endpoint che risponde indica la disponibilità del servizio, non necessariamente che ogni integrazione di storage o callback di salvataggio funzioni.
Esempio di verifica: controlla che il container rimanga attivo, che l'utilizzo della memoria rimanga al di sotto del limite e che l'endpoint interno delle informazioni risponda.
Verificare che il problema di memoria sia stato risolto.
Riapri un piccolo documento e poi un documento rappresentativo di grandi dimensioni tramite la tua integrazione con Nextcloud, ownCloud o altre piattaforme. Salva una modifica innocua e verifica che appaia dopo aver riaperto il file. Continua a monitorare i log di OOM free -h, docker statsOOM e kernel durante il periodo di utilizzo che in precedenza ha causato errori.
Una soluzione efficace significa che i documenti normali continuano ad aprirsi e salvarsi, l'utilizzo della memoria rimane entro i limiti del VPS e del container e non si verificano nuovi arresti anomali per OOM (Out Of Memory). Se gli arresti anomali cessano solo quando l'attività è ridotta, il VPS non dispone ancora di risorse sufficienti per gestire i picchi di utilizzo; dimensionare la RAM in base a tali picchi anziché affidarsi allo swapping continuo. Se la RAM rimane disponibile e non si verificano nuovi messaggi di OOM, ma i documenti continuano a non funzionare, concentrare l'indagine sui log di ONLYOFFICE, sul reverse proxy o sul connettore di archiviazione anziché apportare ulteriori modifiche alla memoria.