Ga naar de inhoud 
Ik laat zien hoe de Bestandsbeschrijvingslimiet op de server beperkt verbindingen, bestanden en sockets en bepaalt dus de prestaties. Ik neem duidelijke stappen om de limieten te verhogen, de vraag te meten en EMFILE-fouten te voorkomen voordat services onder belasting uitvallen.
Centrale punten
Zodat je snel kunt handelen, heb ik de belangrijkste samengevat Hendel om de FD-limieten te optimaliseren:
- OorzaakElke socket, elk bestand, elke DB-verbinding verbruikt FD's.
- SymptomenHTTP 500, EMFILE-berichten, geblokkeerde I/O, servicecrashes.
- Meting: ulimit, /proc/limits, file-max en lsof geven duidelijkheid.
- Optimalisatie: Verhoog de limieten in limits.conf, systemd en sysctl in het bijzonder.
- BeveiligingFlankeer hoge limieten met snelheidsbeperking en bewaking.
Wat zijn bestandsdescriptors en waarom tellen limieten
Een bestandsdescriptor is een eenvoudig geheel getal Identificatiecode, die de kernel gebruikt om te verwijzen naar open bestanden, sockets, pijpen of apparaten per proces. Elk proces heeft een zachte en een harde limiet en er is ook een globaal maximum voor het hele systeem dat alle processen samen limiteert en zo het aantal processen dat kan draaien minimaliseert. Schaarste moeten worden voorkomen. Standaard zijn er vaak maar 1024 FD's beschikbaar per proces, wat al snel krap wordt voor websites met veel verkeer, API-gateways of chat-backends, enzovoort. Pieken in belasting wordt versterkt. Als een proces zijn limiet bereikt, mislukken nieuwe verbindingen, kunnen werkers geen bestanden meer openen en vullen logboeken zich met EMFILE, waardoor de Reactietijden uitgebreid. Het wordt vooral kritisch bij setups die meerdere handles per verzoek innemen: PHP-FPM, cache backends, logbestanden en reverse proxies accumuleren FD's tot de Grenzen blok.
Symptomen herkennen en meten
De eerste tekenen van een te strakke limiet zie je vaak als HTTP-500 zonder duidelijke oorzaak, trage reacties of sporadische herstarts van individuele services. Typische logboekvermeldingen zoals „Te veel open bestanden“ duiden op EMFILE en geven aan dat er onmiddellijk Behoefte aan actie. Ik controleer eerst procesgerelateerde limieten en stroomverbruik om onderscheid te maken tussen lokale knelpunten en systeembrede problemen, en zo de Oorzaak om preciezer te zijn. Deze compacte gids is geschikt voor een gestructureerde introductie Gids voor serverbeperkingen, als je snel een overzicht wilt hebben van de stelschroeven en Stappen plan. Vervolgens gebruik ik lsof om te meten hoeveel descriptoren een proces werkelijk bevat, omdat gemeten waarden aannames verslaan zodra belastingsprofielen veranderen.
# Zachte en harde limiet van de huidige shell
ulimit -n
ulimit -Hn
# Controleer de limieten van een proces
cat /proc//limits | grep "open bestanden".
# Algemene status van het systeem
cat /proc/sys/fs/file-nr # open | vrij | maximum
cat /proc/sys/fs/file-max # globaal maximum
# Ruwe schatting van verbruik per proces
lsof -p | wc -l
Limieten controleren en kerncijfers interpreteren
Ik maak een strikt onderscheid tussen procesgerelateerde en globale grenzen, zodat ik gericht knelpunten kan identificeren. elimineren in plaats van het gewoon te verplaatsen. De harde limiet stelt de bovengrens in voor verhogingen van sessies, terwijl fs.file-max en fs.nr_open het globale frame en dus de Capaciteit van de host. Een beproefde vuistregel is om minstens 65535 FD's per proces toe te staan, mits het RAM en de werklast dit ondersteunen en je de Belasting weten. Tegelijkertijd zorg ik ervoor dat de som van actieve werkers, kindprocessen en netwerkverbindingen in realistische scenario's met hoge belasting binnen de globale Frame waarden overblijft. Een duidelijk zicht op deze cijfers voorkomt blinde verhogingen zonder plan en houdt de systeemintegriteit onder controle. Druk.
| Opdracht/pad | Functie | Waarop moet u letten? |
|---|---|---|
ulimit -n / -Hn | Zachte/harde limiet van de huidige sessie | Harde limiet stelt bovengrens in voor Hijsen |
/proc//limieten | Limieten per proces en open bestanden | Kritisch voor daemons zoals nginx/php-fpm |
/proc/sys/fs/bestand-max | Globaal maximum van alle FD's | Moet worden toegevoegd aan de proceshoeveelheid en RAM fit |
/proc/sys/fs/bestand-nr | Open, gratis, maximaal aantal | Trend in belastingstests en Pieken kijk op |
lsof | Toont open handgrepen | Per werker/thread verbruikt FD's meten |
FD-limieten tijdelijk en permanent aanpassen
Voor snelle tests gebruik ik ulimit om een hogere Zachte limiet, voordat ik permanente regels definieer en services herstart. Ik schrijf dan de juiste regels in /etc/security/limits.conf, voeg systemd overrides toe en verifieer de verandering met een gerichte Belastingstest. Belangrijk: De servicegebruiker moet correct zijn, anders heeft de verhoging geen effect en de Probleem verschijnt weer onder belasting. Ik pas ook de globale limiet aan zodat veel werkerprocessen niet samen de systeemlimiet overschrijden. accumuleren laten. Alleen als de proces- en systeemkant bij elkaar passen, kan de configuratie echte scenario's met hoge belasting weerstaan en voorkomen dat EMFILE.
# Tijdelijk (tot afmelden/herstart)
ulimit -n 65535
# systeembreed (tot herstart of permanent via sysctl.conf)
sudo sysctl -w fs.file-max=2097152
# Permanent (voorbeeld voor webservergebruikers)
echo -e "www-data soft nofile 65535ww-data hard nofile 65535" | sudo tee -a /etc/security/limits.conf
# systemd diensten (bijv. nginx)
sudo mkdir -p /etc/system/system/nginx.service.d
cat <<'EOF' | sudo tee /etc/system/system/nginx.service.d/limits.conf
[Service]
LimitNOFILE=65536
EOF
sudo systemctl daemon-reload && sudo systemctl restart nginx
Stel kernelparameters correct in
Ik valideer fs.file-max en fs.nr_open samen zodat de kernel genoeg Buffer voor piekbelastingen. Als je alleen de per-proceslimiet verhoogt, dan raak je anders de globale limiet en verschuift de knelpunt op systeemniveau. Het is zinvol om een kloof aan te houden tussen de typische piekbelasting en de globale waarden, zodat er reserves zijn voor onderhoudsvensters of piekverkeer en Risicopieken kan worden gedempt. Meer informatie over het afstellen voor het hele systeem is te vinden in het artikel over Kernel afstellen, dat ik graag gebruik als hulpmiddel voor diepgaande aanpassingen aan het besturingssysteem. Checklist gebruik. Nadat ik wijzigingen heb aangebracht, laad ik de parameters opnieuw, controleer ik bestand-nr opnieuw en controleer ik of alle services opnieuw zijn gestart met de nieuwe limieten en de Waarden overnemen.
# Permanente kernel parameters
sudo bash -c 'cat >> /etc/sysctl.d/99-ulimits.conf <<EOF
fs.bestand-max = 2097152
fs.nr_open = 2097152
EOF
sudo sysctl --systeem
# Besturing
cat /proc/sys/fs/file-max
cat /proc/sys/fs/nr_open || sysctl fs.nr_open
Capaciteitsplanning en architectuur
Realistische capaciteitsplanning begint met gemeten Profielen per verzoek: Hoeveel FD's hebben de webserver, app-laag, database en cache samen nodig? Uit deze cijfers leid ik het totale aantal gelijktijdig open handles per host af en plan buffers voor Pieken aan. Bereken voorzichtig: logrotatie, extra sockets, tijdelijke bestanden en back-uptaken verhogen de vraag en vreten bronnen op. Reserves. Ik besteed aandacht aan het feit dat horizontale schaling met loadbalancers de FD-belasting per node verlaagt, waardoor de fouttolerantie en change windows afnemen. Vereenvoudigd. Alleen met duidelijke limietwaarden per tier kun je specifieke limieten instellen en op een verstandige manier capaciteit toewijzen tussen services. delen.
Verfijning van webserver en database
Voor webservers houd ik me aan de regel Draden*4 kleiner dan de FD limiet zodat er reserves zijn voor upstream verbindingen, tijdelijke bestanden en logs. Voor nginx en Apache neem ik keep-alive, open access en error logs en upstream sockets mee in de berekening en beveilig mezelf zo Buffer. Databases zoals MariaDB of PostgreSQL openen veel sockets tegen applicaties, replicatie en monitoring; hun limieten moeten overeenkomen met de verbindingspool en verkeerspieken. fit. Caches (Redis, Memcached) verminderen de DB-belasting, maar verminderen niet noodzakelijkerwijs het aantal FD's als veel clients parallelle verzoeken en verbindingen maken. houd. Ik plan daarom gecoördineerde limieten langs de keten: frontend, upstream, DB, cache en berichtwachtrijen, zodat nergens de eerste harde limiet wordt overschreden. Barrière bereikt.
# Voorbeeld: nginx systemd limit en worker
LimitNOFILE=65536 # systemd
worker_processes auto;
worker_connections 4096; # 4096 * Werker <= 65536
# Voorbeeld: PostgreSQL
max_connections = 1000 # FD vereiste ~ 1-2 per verbinding + bestanden/logs
WordPress en PHP stacks efficiënt houden
WordPress instanties met veel plugins openen meer bestanden, meer netwerkverbindingen en meer Logboeken. Ik verminder het aantal onnodige includes met OPCache, verminder de belasting van databases met Redis Object Cache en besteed statische assets uit via een CDN om bestandstoegang tot een minimum te beperken. Verbindingen om de belasting te verminderen. Tegelijkertijd verhoog ik specifiek de limieten voor php-fpm en de webserver zodat pieken tijdens cronjobs, crawlers of winkeluitchecken geen probleem zijn. Afbrekingen genereren. Een schone afhandeling van foutlogs en rotaties voorkomt dat logboekschrijvers op niets stuiten en geen nieuwe bestanden openen. mei. Zo combineer ik verbruiksvermindering en limietverhoging zodat de stack betaalbaar blijft onder belasting en Doorvoer houdt.
Containers en cloudomgevingen
In Docker en Kubernetes erven processen vaak de FD-limieten van de Knooppunten, Daarom controleer ik eerst de hostparameters en dan de servicedefinities. Analoge principes zijn van toepassing op systemd-nspawn of containerd, maar de implementatie gebeurt in unit-bestanden, PodSpecs of daemon-configuraties met Opheffen. Ik documenteer de limieten als code (IaC) en houd ze consistent via playbooks zodat nieuwe knooppunten identieke limieten hebben. Grenzen meenemen. Met Kubernetes controleer ik ook SecurityContexts en stel ik de vereiste mogelijkheden in zodat de systeemkant Grenzen effect hebben. Uiteindelijk blijft de meting in het cluster belangrijk, omdat scheduling, autoscaling en rolling updates de verdeling van open handles veranderen en je Buffer.
# Voorbeeld: systemd in container hosts
cat <<'EOF' | sudo tee /etc/system/system/myapp.service.d/limits.conf
[Service]
LimitNOFILE=65536
EOF
# Kubernetes: podSpec (container image moet ulimit respecteren)
# Opmerking: rlimit-instellingen moeten anders worden ingesteld, afhankelijk van de runtime/OS
Beveiliging, snelheidsbeperking en bewaking
Hoge limieten bieden ademruimte, maar vergroten het aanvalsoppervlak voor Overstromingen, Daarom beperk ik aanvragen aan de rand met rate limiting en stel ik verbindingslimieten in op de webserver. Een firewall voor webtoepassingen en zinvolle time-outs voorkomen dat inactieve verbindingen de FD's permanent blokkeren. binden. Voor terugkerende tests gebruik ik reproduceerbare belastingsprofielen en gebruik ik Prometheus, Netdata of Nagios om consequent de metriek met betrekking tot open bestanden en Sockets. Afhankelijk van de werkbelasting corrigeer ik grenswaarden geleidelijk in plaats van ze abrupt te verhogen, zodat effecten meetbaar blijven en Ontmanteling is eenvoudig. Als je dieper wilt ingaan op grenswaarden aan de verbindingskant, dan is dit compacte artikel over Verbindingsbeperkingen, die ik gebruik bij netwerkgrenzen als Gids serveert.
Problemen oplossen met EMFILE: gestructureerde procedure
Ik begin met een kijkje in de Tijdschrift en in de servicelogs om de tijd en frequentie van de fouten te beperken. Vervolgens gebruik ik lsof om het topverbruik per proces te controleren en patronen te identificeren, zoals lekken, toenemende logging of ongebruikelijke Socket-types. Vervolgens vergelijk ik de ingestelde limieten met echte pieken en verhoog ze eerst tijdelijk, zodat ik oorzaak en gevolg kan valideren in een gecontroleerde test en op basis daarvan het volgende kan bepalen Permanente instellingen afgeleid. Als er een lek wordt gevonden, patch of rol ik het onderdeel terug, omdat hogere limieten alleen symptomen verbergen en het probleem uitstellen. Probleem. Tot slot documenteer ik de correctie, stel ik alarmen in en plan ik een nieuwe belastingstest zodat de oplossing geldig is en opnieuw kan worden gebruikt. Vertrouwen creëert.
Realistisch inschatten van de kosten van middelen voor hoge FD-limieten
Elk open bestand of socket kost kernelgeheugen. Plan daarom de RAM-voetafdruk Afhankelijk van de kernelversie en architectuur zijn er een paar honderd bytes tot een paar kilobytes nodig per FD (inclusief VFS/socketstructuren). Met honderdduizenden FD's loopt dit op. Ik heb global file-max zo gedimensioneerd dat er in het ergste geval nog voldoende paginacache en RAM vrij is voor applicaties. Een eenvoudige tegencontrole wordt uitgevoerd via vmstat, free en de trend van open FD's via file-nr tijdens een Piekbelastingstests. Het doel is een configuratie die niet doorslaat naar swap bij piekbelasting en die geen overmatige reclaim- of OOM-activiteit veroorzaakt.
Distributie- en startpadvallen (PAM, systemd, Cron)
Of er beperkingen van toepassing zijn, hangt af van de Beginpad van. PAM-gebaseerde aanmeldingen (ssh, su, login) lezen /etc/security/limits.conf, terwijl systemd diensten voornamelijk hun eenheidsparameters (LimitNOFILE) en niet verplichte PAM. Cron/at kunnen hun eigen context hebben. Daarom valideer ik per service:
- Hoe start het proces? (systemctl status, ps -ef)
- Welke limieten ziet het echt? (cat /proc//limits)
- Werkt PAM? (Controleer PAM-modules in /etc/pam.d/*)
- Bestaan er systeemwijde standaardinstellingen? (systemd: DefaultLimitNOFILE in system.conf)
Op deze manier voorkom ik dat applicaties verschillende FD-limieten ontvangen afhankelijk van het startpad en van inconsistent reageren.
Praktisch dimensioneren met rekenvoorbeelden
Ik reken op de Arbeiders en verbindingsprofielen van achteruit naar de vereiste FD-capaciteit:
- nginx met 8 werkers met elk 4000 verbindingen: ~32000 verbindingen. In de regel reserveert nginx 1 FD per actieve verbinding; plus upstream (keep-alive) en logs voegen ~10-20% buffer toe. Resultaat: ~38000 FD's voor nginx alleen.
- php-fpm met 150 kinderen, meestal 20-40 FD's per kind (inclusief, sockets, logs): voorzichtig 6000 FD's.
- Redis/DB-clients: 200 parallelle verbindingen, elk 1-2 FD's: ~400 FD's.
Totaal per host: ~44k FD's. Ik stel in LimitNOFILE voor nginx tot 65536, php-fpm analoog, en vliegtuig wereldwijd fs.file-max zodat alle diensten plus reserve (x1.5-x2) erin passen. Voor meerdere intensief gebruikte instanties per host, schaal globaal naar 1-2 miljoen FD's als RAM en I/O-paden voldoende zijn. overgave.
Diepere diagnose: lekkages en hotspots vinden
Als de FD's voortdurend stijgen, gebruik ik gerichte hulpmiddelen om de oorzaak te vinden:
# Openstaande grepen gegroepeerd op type
lsof -p | awk '{print $5}' | sorteren | uniq -c | sorteren -nr
# Alleen sockets van één proces
lsof -Pan -p -i
# Welke bestanden groeien (logs, temp)
lsof +L1 # Verwijderde maar nog open bestanden
ls -l /proc//fd
# Syscall-weergave: wie is er constant aan het openen?
strace -f -p -e trace=open,openat,close,socket,accept,accept4 -s 0
Bijzonder verraderlijk zijn Verwijderde logboeken, die nog open zijn: Ze bezetten ruimte en FD's, maar verschijnen niet meer in het bestandssysteem. Herstarten of expliciet heropenen (bijvoorbeeld met nginx via USR1) lost dit probleem netjes op. Verkeerd geconfigureerde watchers/exporters kunnen ook constant nieuwe sockets openen - snelheidslimieten en pooling.
Inotify, epoll en EMFILE duidelijk afbakenen
Niet elke limiet op bronnen wordt een FD limiet genoemd. In ontwikkel- en CI-omgevingen mislukken builds vaak met ENOSPC in relatie tot Inotify (watcher-limieten). Ik controleer en stel in als aanvulling:
# Inotify-limieten (gebruikersbreed en instanties)
sysctl fs.inotify.max_user_watches
sysctl fs.inotify.max_user_instances
# Voorbeeld toename
sudo sysctl -w fs.inotify.max_user_watches=524288
sudo sysctl -w fs.inotify.max_user_instances=1024
Hoewel epoll intern met FD's werkt, is het eigenlijke knelpunt met massieve Langlevend-verbindingen overschrijden vaak de FD-limiet zelf. Daarom correleer ik epoll/event loop gegevens (bijvoorbeeld actieve handles) met file-nr en proces-gerelateerd verbruik.
Taal- en runtime-specialiteiten (Java, Node.js, Go, Python)
Runtimes gaan verschillend om met FD's:
- Java/NettyVeel NOK-kanalen per proces, logframeworks houden bestandsaanvullers open. Ik stel genereuze limieten in en roteer logs met een heropenstrategie in plaats van sluiten/vervangen.
- Node.jsEMFILE treedt snel op bij bestandssysteem zware werklasten (bijv. watcher, build pipelines). Ik regel parallelle fs operaties, verhoog limieten en stel backoff/retry strategieën in.
- Ga naarHoog parallellisme door goroutines kan veel sockets openen. Ik beperk dial en response header timeouts en controleer of verbindingen goed worden afgesloten (IdleConnTimeout).
- Python/uWSGI/GunicornWorker/thread-modellen verbruiken FD's voor logs, sockets en tijdelijke bestanden; ik harmoniseer het aantal workers, threadpools en tijdelijke bestanden. nofile-limieten.
Ze hebben allemaal één ding gemeen: Zonder gecoördineerde houtrotatie en betrouwbare Beheer van verbindingen FD's stijgen geleidelijk.
Containers in concrete termen: Docker- en Kubernetes-instellingen
Om ervoor te zorgen dat de containers de gewenste limieten ook echt zien, stel ik ze consequent in langs de keten:
- Docker uitvoerenstart met -ulimit nofile=65535:65535 of ingesteld door de standaard daemon (bijv. standaardlimieten).
- AfbeeldingenStart scripts mogen een beperkende ulimiet niet resetten.
- KubernetesAfhankelijk van de runtime (containerd, cri-o) hebben rlimit-instellingen een verschillend effect. Ik test in de pod via cat /proc/self/limits en pas de node/runtime standaardinstellingen aan als de specifieke eigenschappen van de pod niet voldoende zijn.
Vooral in multi-tenant omgevingen beveilig ik de Totaal bedrag tegen fs.file-max en isoleer lawaaierige buureffecten door aparte nodesets of pod-budgetten te gebruiken, zodat individuele implementaties de door de host gereserveerde FD's niet verbruiken.
Bewakingsmetriek en alarmen verduidelijken
Naast bestand-nr en bestand-max bewaak ik ook FD's en trendlijnen per proces:
- SysteemwijdToegewezen vs. maximum, veranderingssnelheid, piek/maximum-verhouding.
- Per procesFD's per werker/thread, Top-N processen, nachtelijke afwijkingen (batch/jobs).
- KwalitatiefHTTP-foutenpercentages, wachtrijlengtes, acceptatie-/handshake-fouten gesynchroniseerd met de FD-trend.
Ik stel waarschuwingen in meerlagigWaarschuwing bij 70-80%, kritisch vanaf 90% van de geconfigureerde limiet, plus Lekdetectie via stijgende 7-daagse trends. Hierdoor kan ik op tijd reageren voordat harde barrières in werking treden.
Draaiboek voor noodgevallen
Wanneer EMFILE acuut toeslaat, handel ik in duidelijke stappen:
- Identificeer de grootste verbruikers (lsof, /proc//fd, journaalposten).
- Verhoog tijdelijk de zachte limiet (ulimit in session of LimitNOFILE override) en herstart de service.
- Als logs de reden zijn: Stop rotatie, trigger heropenen, verlaag logniveau.
- Barstverkeer aan de rand gashendel (Tariefbeperkingen/verbindingsbeperkingen verhogen of aanscherpen - afhankelijk van de situatie).
- Probleemoplossing (lek, te agressief parallellisme, ontbrekende time-outs) en permanente limieten vastdraaien.
Opvolging is belangrijk: documentatie, herhaalde belastingstests en alarmen voor het slijpen, zodat dezelfde ketting in een vroeg stadium wordt herkend.
Kort samengevat
Met verhoogde FD-limieten, schoon ingestelde kernelparameters en een geteste architectuur kan ik mijn klanten diensten leveren. Manoeuvreerruimte onder hoge belasting. Ik meet eerst, stel dan de juiste grenswaarden in, controleer met belastingstests en stel het resultaat veilig met snelheidsbegrenzing, bewaking en wissen. Regels.
