Zapobiegnij wyczerpaniu się pamięci VPS na serwerze dokumentów ONLYOFFICE

Jeśli serwer dokumentów ONLYOFFICE ulegnie awarii lub uruchomi się ponownie z powodu braku pamięci na serwerze VPS, najpierw potwierdź wystąpienie zdarzenia braku pamięci i sprawdź, czy limit pamięci Dockera nie jest zbyt mały. Następnie zapewnij wystarczającą ilość fizycznej pamięci RAM dla obciążenia i dodaj tylko pamięć wymiany jako bufor bezpieczeństwa; wielokrotne ponowne uruchamianie edytora nie rozwiąże problemu ciągłego niedoboru pojemności.

1. Udowodnij, że przyczyną awarii jest obciążenie pamięci

Uruchom na serwerze VPS z systemem Linux, a nie w ustawieniach integracji ONLYOFFICE. Komunikat przeglądarki, taki jak „Nie można załadować dokumentu”, może być również spowodowany problemami z siecią lub uwierzytelnianiem, dlatego ważne jest, aby ustalić, czy program Linux OOM (Out-of-Memory Killer) faktycznie zakończył proces.

Uruchom te polecenia przez SSH. Zastąp je onlyoffice-document-servernazwą kontenera wyświetlaną w następujący sposób 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 -hPokazuje dostępną pamięć RAM i swap hosta. docker statsMierzy stan działającego kontenera, podczas gdy polecenie „inspect” raportuje stan kontenera (OOM-killed), ostatni kod wyjścia i skonfigurowane limity zasobów w bajtach. HostConfig.MemoryWartość różna od zera oznacza jawny limit pamięci. Statystyka pamięci Dockera może wykluczać niektóre pamięci podręczne plików, dlatego należy ją porównywać z pomiarami hosta, a nie traktować jako pełny obraz. Zobacz odnośnik do statystyk Dockera .

Jeśli kontener się zatrzymał, docker statsnie można wyświetlić poprzedniego szczytu. Zamiast tego sprawdź dziennik jądra i ostatnie komunikaty aplikacji:

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

Komunikaty jądra informujące o braku pamięci lub zamknięciu procesu pomagają zidentyfikować dany proces. OOMKilled=trueStanowią one silny dowód na wystąpienie zdarzenia OOM w kontenerze, ale falsenie wykluczają możliwości zamknięcia procesu potomnego przez jądro hosta podczas działania kontenera. Podobnie, kod wyjścia 137 sygnalizuje jedynie zakończenie sygnału SIGKILL, a nie jego przyczynę. Jeśli nie ma dowodów na brak pamięci, przed zakupem dodatkowej pamięci RAM należy sprawdzić logi i błędy połączeń.

2. Zapewnij VPS-owi wystarczającą ilość pamięci RAM przed dostrojeniem czegokolwiek innego

Według stanu na październik 2026 roku, oficjalny plik README serwera dokumentów Docker firmy ONLYOFFICE wymienia 4 GB lub więcej pamięci RAM i co najmniej 2 GB przestrzeni wymiany wśród zalecanych wymagań. Oddzielna, oficjalna dokumentacja instalatora obsługiwanego jednym kliknięciem wskazuje 4 GB pamięci RAM dla środowisk testowych Dockera, zaleca 8 GB lub więcej w środowisku produkcyjnym i określa co najmniej 4 GB przestrzeni wymiany w wymaganiach instalatora. Dokumenty te opisują różne konteksty wdrożenia, dlatego nie należy interpretować 4 GB jako gwarancji niezawodnej wydajności produkcyjnej.

Jeśli Twój VPS ma tylko 1–2 GB pamięci RAM, rozbudowa jego pakietu to najpewniejsze rozwiązanie w przypadku instalacji opartej na Dockerze. Jeśli ma już 4 GB, sprawdź, ile pamięci zużywa system operacyjny, baza danych, odwrotny serwer proxy, NextCloud i inne kontenery. Serwer, który wydaje się wygodny w stanie bezczynności, może nadal mieć za mało pamięci, gdy kilka osób jednocześnie otwiera dokumenty lub konwertuje duże arkusze kalkulacyjne.

Na obciążonym hoście użyj tej opcji ps aux --sort=-rss | headdo identyfikacji procesów intensywnie wykorzystujących pamięć i powtórz ją docker statspodczas reprezentatywnej sesji edycji. Zarezerwuj przestrzeń dla reszty komputera zamiast przypisywać całą dostępną pamięć RAM do ONLYOFFICE. Jeśli stałe zapotrzebowanie przekracza pojemność hosta, przenieś konkurencyjne usługi lub zmodernizuj serwer VPS; modyfikacja na poziomie aplikacji nie spowoduje brakującej pamięci fizycznej.

Sprawdź, czy nie doszło do przypadkowego przepełnienia pamięci Dockera

Kontenery Dockera domyślnie nie mają sztywnego limitu pamięci, ale wdrożenie może go ustalić za pomocą --memoryfunkcji lub Compose mem_limit. Na przykład limit kontenera 2 GB może powodować likwidację braku pamięci (OOM) nawet wtedy, gdy host 8 GB ma wolną pamięć RAM. Przed zmianą sprawdź rzeczywisty limit. Jeśli limit jest niepotrzebnie niski, dostosuj oryginalną konfigurację Dockera lub Compose do wartości uzasadnionej pomiarami i pozostałą pojemnością hosta. Zapoznaj się z dokumentacją ograniczeń zasobów Dockera i specyfikacją usługi Compose .

Nie ustawiaj bezmyślnie nieograniczonej alokacji pamięci na współdzielonym serwerze VPS: może to narazić inne usługi na straty pamięci (OOM) w całym hoście. Sprawdź również --memory-swapCompose memswap_limit; Docker zlicza łączną pamięć RAM i swap w tym ustawieniu. Równa ilość pamięci RAM i łączne limity skutecznie wyłączają swap dla kontenera. Jeśli zarządzasz ONLYOFFICE za pomocą Compose, wprowadź zmianę w pliku Compose, aby ustawienie przetrwało po odtworzeniu kontenera.

3. Dodaj bufor wymiany, jeśli VPS go nie posiada

Plik wymiany może absorbować chwilowe skoki pamięci, ale jest przechowywany na dysku i działa znacznie wolniej niż pamięć RAM. Sprawdź swapon --showto df -h /najpierw. Poniższy przykład dodaje plik wymiany o rozmiarze 2 GB do serwera VPS przy użyciu kompatybilnego lokalnego systemu plików, takiego jak ext4, gdy ten /swapfilejeszcze nie istnieje, a dostawca zezwala na wymianę:

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

Utrwal nowy plik wymiany dopiero po swaponpomyślnym zakończeniu. Sprawdź, czy istnieje wpis za pomocą grep -F '/swapfile' /etc/fstab; jeśli nie istnieje, dodaj go raz:

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

Tworzenie plików wymiany w systemach Btrfs, sieciowych systemach plików i niektórych innych konfiguracjach wymaga innego podejścia. Nie uruchamiaj tych poleceń na istniejącym pliku wymiany ani nie zakładaj, że fallocatedziałają wszędzie. Podręcznik Linux swapon wyjaśnia ograniczenia systemu plików. Jeśli serwer VPS regularnie wykonuje wymianę przy normalnym obciążeniu edycyjnym, priorytetem powinno być zwiększenie pamięci RAM niż utworzenie większego pliku wymiany.

4. Sprawdź ponownie serwer przy realistycznym obciążeniu edycyjnym

Zmiana planu VPS lub włączenie usługi wymiany często nie wymaga edycji konfiguracji ONLYOFFICE. Jeśli zmieniłeś ustawienia wdrożenia Dockera, zaplanuj konserwację i zachowaj istniejące montowania, sekrety, ścieżki certyfikatów i ustawienia integracji podczas ich stosowania. Dokumenty README usługi ONLYOFFICE Docker zawierają ostrzeżenie documentserver-prepare4shutdown.shdotyczące planowanych wyłączeń i informują, że odłączanie edytorów może potrwać kilka minut. Nie twórz ponownie ani nie restartuj aktywnie używanego serwera dokumentów, ponieważ może to wpłynąć na niezapisane zmiany.

Gdy usługa będzie gotowa, sprawdź, czy kontener działa i ponownie sprawdź jego pamięć:

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

Ostatnie sprawdzenie wykorzystuje wewnętrzny punkt końcowy informacji pokazany w oficjalnym teście stanu zdrowia Docker Compose w ONLYOFFICE ; należy go uruchomić w kontenerze, ponieważ port 8000 może nie być opublikowany na serwerze VPS. Odpowiedź punktu końcowego wskazuje na dostępność usługi, ale niekoniecznie oznacza, że ​​każda integracja pamięci masowej lub wywołanie zwrotne zapisu działa.

Sprawdź, czy problem z pamięcią został rozwiązany

Otwórz ponownie mały dokument, a następnie jeden reprezentatywny, duży dokument za pośrednictwem swojej usługi NextCloud, ownCloud lub innej integracji. Zapisz nieszkodliwą edycję i sprawdź, czy pojawi się ona po ponownym otwarciu pliku. Monitoruj free -hlogi docker statsOOM jądra (OOM) w okresie użytkowania, który wcześniej powodował awarie.

Skuteczne rozwiązanie problemu oznacza, że ​​normalne dokumenty nadal będą się otwierać i zapisywać, wykorzystanie pamięci mieści się w granicach limitów VPS i kontenerów oraz nie pojawią się nowe komunikaty o braku pamięci (OOM). Jeśli awarie ustępują tylko przy niskiej aktywności, VPS nadal nie ma zapasu na szczytowe obciążenie; dostosuj rozmiar pamięci RAM do tego szczytu, zamiast polegać na ciągłej wymianie. Jeśli pamięć RAM pozostaje dostępna i nie pojawiają się nowe komunikaty o braku pamięci (OOM), ale dokumenty nadal nie są obsługiwane, przełącz dochodzenie na dzienniki ONLYOFFICE, odwrotny serwer proxy lub konektor pamięci masowej zamiast wprowadzać dalsze zmiany w pamięci.