Opriți serverul de documente ONLYOFFICE să rămână fără memorie VPS

Dacă ONLYOFFICE Document Server se blochează sau repornește deoarece VPS-ul rămâne fără memorie, confirmați mai întâi un eveniment de memorie insuficientă și verificați dacă există o limită de memorie Docker subdimensionată. Apoi, furnizați suficientă memorie RAM fizică pentru volumul de lucru și adăugați doar memoria swap ca buffer de siguranță; repornirea repetată a editorului nu va remedia o lipsă persistentă de capacitate.

1. Dovediți că presiunea asupra memoriei este cauza eșecului

Începeți pe VPS-ul Linux, nu în setările de integrare ONLYOFFICE. Un mesaj de browser precum „Documentul nu poate fi încărcat” poate fi cauzat și de rețea sau autentificare, așa că este important să stabiliți dacă killer-ul de memorie insuficientă (OOM) Linux a terminat de fapt un proces.

Executați aceste comenzi prin SSH. Înlocuiți-le onlyoffice-document-servercu numele containerului afișat prin docker ps -a:

free -h
docker ps -a
docker stats --no-stream onlyoffice-document-server
docker inspect --format '{{.State.OOMKilled}} {{.State.ExitCode}} {{.HostConfig.Memory}} {{.HostConfig.MemorySwap}}' onlyoffice-document-server

free -hafișează memoria RAM disponibilă a gazdei și memoria swap. docker statsmăsoară un container care rulează, în timp ce comanda inspect raportează starea OOM-killed a containerului, ultimul cod de ieșire și limitele de resurse configurate în octeți. O HostConfig.Memoryvaloare diferită de zero indică o limită explicită a memoriei. Statistica de memorie a Docker poate exclude anumite cache-uri de fișiere, așa că ar trebui comparată cu măsurătorile gazdei, mai degrabă decât tratată ca o imagine completă. Consultați referința statisticilor Docker .

Dacă containerul s-a oprit, docker statsnu se poate afișa vârful anterior. Verificați în schimb jurnalul kernelului și mesajele recente ale aplicației:

sudo journalctl -k --since "-2 hours" | grep -Ei 'out of memory|killed process|oom'
docker logs --tail 100 onlyoffice-document-server

Mesajele kernel care menționează „Memorie insuficientă” sau „Proces întrerupt” ajută la identificarea procesului implicat. OOMKilled=truereprezintă o dovadă puternică a unui eveniment OOM al containerului, dar falsenu exclude posibilitatea ca kernelul gazdă să întrerupă un proces copil în timp ce containerul rămâne activ. În mod similar, codul de ieșire 137 stabilește doar o terminare SIGKILL, nu și cauza acesteia. Dacă nu există dovezi OOM, investigați jurnalele și erorile de conexiune înainte de a cumpăra mai multă memorie RAM.

2. Dați suficientă memorie RAM VPS-ului înainte de a regla orice altceva

Începând cu octombrie 2026, fișierul oficial README al serverului de documente Docker al ONLYOFFICE listează printre cerințele recomandate 4 GB sau mai mult de RAM și cel puțin 2 GB de spațiu swap. Documentația oficială separată pentru instalarea cu un singur clic identifică 4 GB de RAM pentru mediile de testare Docker, recomandă 8 GB sau mai mult pentru producție și specifică cel puțin 4 GB de spațiu swap în cerințele instalatorului. Aceste documente descriu contexte de implementare diferite, așadar nu interpretați 4 GB ca o garanție a performanței fiabile în producție.

Dacă VPS-ul dvs. are doar 1-2 GB de RAM, actualizarea planului său este cea mai justificabilă soluție pentru o instalare bazată pe Docker. Dacă are deja 4 GB, verificați cât consumă sistemul de operare, baza de date, proxy-ul invers, Nextcloud și alte containere. Un server care arată confortabil în timp ce este inactiv poate rămâne în continuare fără memorie atunci când mai multe persoane deschid documente sau convertesc foi de calcul mari simultan.

Pe o gazdă aglomerată, se utilizează ps aux --sort=-rss | headpentru a identifica procesele care necesită multă memorie și se repetă docker statsîn timpul unei sesiuni de editare reprezentative. Rezervați spațiu pentru restul mașinii în loc să alocați toată memoria RAM disponibilă către ONLYOFFICE. Dacă cererea susținută depășește capacitatea gazdei, mutați serviciile concurente sau actualizați VPS-ul; o modificare la nivel de aplicație nu poate crea memorie fizică lipsă.

Verificați dacă există o limitare accidentală a memoriei Docker

Containerele Docker nu au o limită fixă ​​de memorie în mod implicit, dar o implementare poate seta una cu --memorysau cu Compose mem_limit. De exemplu, o limită de container de 2 GB poate cauza întreruperi ale memoriei OOM chiar și atunci când o gazdă de 8 GB are RAM liberă. Verificați limita reală înainte de a o modifica. Dacă limita este inutil de mică, ajustați configurația originală de rulare Docker sau Compose la o valoare justificată de măsurători și de capacitatea rămasă a gazdei. Consultați documentația Docker privind constrângerile de resurse și specificația serviciului Compose .

Nu setați orbește o alocare nelimitată de memorie pe un VPS partajat: acest lucru poate expune alte servicii la întreruperi OOM la nivel de gazdă. Verificați și --memory-swapsetarea din Compose memswap_limit; Docker numără memoria RAM combinată și memoria swap în acea setare. RAM egală și limitele combinate dezactivează efectiv memoria swap pentru container. Dacă gestionați ONLYOFFICE cu Compose, faceți modificarea în fișierul său Compose, astfel încât setarea să supraviețuiască recreării containerului.

3. Adăugați un buffer de swap dacă VPS-ul nu are niciunul

Fișierul swap poate absorbi o creștere temporară a memoriei, dar este stocat pe disc și este mult mai lent decât memoria RAM. Verificați swapon --showmai df -h /întâi. Următorul exemplu adaugă un fișier swap de 2 GiB la un VPS folosind un sistem de fișiere local compatibil, cum ar fi ext4, atunci când /swapfileacesta nu există deja și furnizorul permite swap-ul:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show
free -h

Faceți noul fișier swap persistent doar după ce swaponreușește. Verificați dacă există o intrare cu grep -F '/swapfile' /etc/fstab; dacă nu există, adăugați-o o dată:

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Crearea fișierelor swap pe Btrfs, sisteme de fișiere de rețea și alte configurații necesită o gestionare diferită. Nu rulați aceste comenzi peste un fișier swap existent și nu presupuneți că fallocatefuncționează peste tot. Manualul swapon Linux explică restricțiile sistemului de fișiere. Dacă VPS-ul efectuează swapping-uri în mod regulat sub sarcină normală de editare, acordați prioritate mai multă memorie RAM decât unui fișier swap mai mare.

4. Verificați din nou serverul sub o sarcină de editare realistă

Modificarea unui plan VPS sau activarea swap-ului nu necesită adesea modificări ale configurației ONLYOFFICE. Dacă ați modificat o setare de implementare Docker, programați mentenanța și păstrați montările, secretele, căile de certificat și setările de integrare existente atunci când o aplicați. Fișierul README ONLYOFFICE Docker documentează documentserver-prepare4shutdown.shopririle planificate și avertizează că deconectarea editorilor poate dura câteva minute. Nu recreați sau reporniți întâmplător un server de documente utilizat activ, deoarece modificările nesalvate pot fi afectate.

Când serviciul este gata, verificați dacă containerul rulează și inspectați din nou memoria acestuia:

docker ps --filter name=onlyoffice-document-server
docker stats --no-stream onlyoffice-document-server
docker inspect --format '{{.State.OOMKilled}}' onlyoffice-document-server
docker exec onlyoffice-document-server curl -fsS http://localhost:8000/info/info.json

Ultima verificare folosește endpoint-ul intern cu informații afișat în verificarea oficială de sănătate ONLYOFFICE Docker Compose ; rulați-l în interiorul containerului, deoarece portul 8000 poate să nu fie publicat pe VPS. Endpoint-ul care răspunde arată disponibilitatea serviciului, nu neapărat că fiecare integrare de stocare sau apel invers de salvare funcționează.

Verificați dacă problema memoriei este rezolvată

Redeschideți un document mic și apoi un document mare reprezentativ prin intermediul integrării Nextcloud, ownCloud sau altă integrare. Salvați o editare inofensivă și confirmați că aceasta apare după redeschiderea fișierului. Continuați să urmăriți jurnalele free -h, docker statsși kernel OOM în perioada de utilizare care a declanșat anterior erori.

O remediere reușită înseamnă că documentele normale continuă să se deschidă și să se salveze, utilizarea memoriei rămâne în limitele VPS și ale containerului și nu apar noi întreruperi OOM. Dacă blocările se opresc doar atunci când activitatea este redusă, VPS-ul încă nu are spațiu pentru utilizarea maximă; dimensionați memoria RAM pentru acel vârf, în loc să vă bazați pe schimbarea continuă. Dacă rămâne memorie RAM disponibilă și nu apar noi mesaje OOM, dar documentele tot eșuează, comutați investigația la jurnalele ONLYOFFICE, proxy-ul invers sau conectorul de stocare în loc să faceți alte modificări de memorie.