Ulimit v Linuxu: zjistit limit souborů předtím, než služba spadne

Služba, která náhle odmítá nové připojení nebo píše „Too many open files“, nemusí mít nutně problém s pamětí. Může dosáhnout svého limitu deskriptorů souborů. Pod Linuxem spotřebovává socket, zápisník, soubor a někdy také pipe jeden deskriptor.

Příkaz ulimit -n ukazuje limit aktuálního shellu. Neprokazuje limit již spuštěné služby. Pro démon řízený systemd zkontrolujte proces, jednotku a trvalou konfiguraci předtím, než cokoliv změníte.

Tux před servery se složkami a konektory představujícími limit souborů Linux — Limity otevřených souborů by měly být kontrolovány na úrovni procesu a služby systemd.

Přečtěte si limit shellu a limit procesu

Ve svém terminálu začněte rozlišovat mezi měkkým limitem a tvrdým limitem. První může být snížena procesem. Druhý stanovuje strop, který uživatel bez oprávnění nemůže překročit.

ulimit -Sn
ulimit -Hn

Výsledek 1024 může stačit pro interaktivní relaci. Rychle se stává nedostatečným pro proxy, webový server nebo aplikaci, která udržuje mnoho otevřených připojení. Nekopírujte hodnotu nalezenou na fóru: začněte měřit, co služba využívá.

Najděte její PID a pak si přečtěte skutečně uplatněné limity:

systemctl show nginx -p MainPID
sudo grep 'Max open files' /proc/1234/limits
sudo ls /proc/1234/fd | wc -l

Nahraďte 1234 PID, který vrátil systemd. Počítadlo v /proc/1234/fd ukazuje počet otevřených deskriptorů. Porovnejte ho s Max open files. Malý rozdíl lépe vysvětluje saturaci než jednoduchý dojem pomalosti.

Zkontrolujte limit systemd před jeho změnou

Služba systemd automaticky nenabírá hodnotu ze své relace SSH. Jednotka může definovat LimitNOFILE, nebo zdědit globální hodnotu. Zobrazte aktuální hodnotu:

systemctl show nginx -p LimitNOFILE
systemctl cat nginx

Pokud jednotka ukazuje nízký limit a protokoly potvrzují chyby při otevírání, vytvořte přepsání spíše než abyste modifikovali soubor dodaný balíčkem:

sudo systemctl edit nginx

Pak přidejte tuto sekci s hodnotou přizpůsobenou pro vaši aplikaci:

[Service]
LimitNOFILE=65535

Pro službu vystavenou v produkci si ponechte otevřenou druhou relaci SSH. Chyba v jednotce nebo selhání restartu by vás neměly nechat bez přístupu. Zkontrolujte také dokumentaci aplikace: některé mají vlastní strop, odlišný od systemd.

Restartujte a poté zkontrolujte skutečně uplatněnou hodnotu

Po přepsání načtěte konfiguraci a restartujte pouze dotyčnou službu:

sudo systemctl daemon-reload
sudo systemctl restart nginx
systemctl show nginx -p LimitNOFILE
systemctl status nginx --no-pager

Nakonec si znovu přečtěte /proc/PID/limits s novým PID. Pokud LimitNOFILE má hodnotu 65535 v systemd, ale proces zůstává na 1024, pravděpodobně sledujete starý PID, jinou službu nebo mezilehlého správce.

Kontroly před zvýšením limitu

Potvrďte přesnou chybu pomocí journalctl -u nginx nebo v aplikačních protokolech.
Změřte počet otevřených deskriptorů před a po vrcholu zatížení.
Zvyšte limit pro konkrétní jednotku, ne pro všechny služby na stroji.
Sledujte připojení, soubory a sockety, které zůstávají otevřené: úniky deskriptorů se řeší v aplikaci.

Vyšší limit zabraňuje náhlému zastavení služby, ale neopravuje proces, který otevírá soubory, aniž by je zavíral. Uchovávejte zaznamenané hodnoty a výpisy protokolů: pomohou rozhodnout, zda byl limit příliš nízký, nebo zda je třeba službu opravit.