Het beheren van Unix servers kan een uitdaging zijn, vooral als de systemen die u beheert zwaar gebruikt worden en prestatieproblemen de beschikbaarheid verminderen. Gelukkig kun je grenzen stellen aan bepaalde bronnen om ervoor te zorgen dat de belangrijkste processen op je servers kunnen blijven draaien en dat concurrerende processen niet veel meer bronnen gebruiken dan goed is voor het systeem als geheel. Het ulimit commando kan rampen op afstand houden, maar je moet wel weten waar limieten zinvol zijn en waar ze problemen kunnen veroorzaken.
Het gebeurt misschien niet zo vaak, maar een enkele gebruiker die te veel processen start kan een systeem onbruikbaar maken voor alle anderen. Een fork bomb – een denial of service aanval waarbij een proces zichzelf voortdurend herhaalt totdat de beschikbare bronnen zijn uitgeput – is hiervan het ergste geval. Zelfs vriendelijke gebruikers kunnen echter meer bronnen gebruiken dan goed is voor een systeem — vaak zonder dat ze dat van plan zijn. Tegelijkertijd kunnen legitieme processen soms falen wanneer ze tegen limieten aanlopen die zijn ontworpen voor gemiddelde gebruikers. In dit geval moet u er voor zorgen dat deze processen versterkte toewijzingen van systeembronnen krijgen, zodat ze goed kunnen draaien zonder dat dezelfde bronnen voor iedereen beschikbaar zijn.
Om de limieten te zien die aan uw login zijn gekoppeld, gebruikt u het commando ulimit -a. Als u een gewone gebruikersaccount gebruikt, ziet u waarschijnlijk iets als dit:
$ ulimit -acore file size (blocks, -c) 0data seg size (kbytes, -d) unlimitedscheduling priority (-e) 0file size (blocks, -f) unlimitedpending signals (-i) 32767max locked memory (kbytes, -l) 32max memory size (kbytes, -m) unlimitedopen files (-n) 1024pipe size (512 bytes, -p) 8POSIX message queues (bytes, -q) 819200real-time priority (-r) 0stack size (kbytes, -s) 10240cpu time (seconds, -t) unlimitedmax user processes (-u) 50virtual memory (kbytes, -v) unlimitedfile locks (-x) unlimited
Eén ding dat u misschien meteen opvalt, is dat u geen core dumps kunt maken — omdat uw maximale core bestandsgrootte 0 is. Ja, dat betekent niets, geen gegevens, geen core dump. Als een proces dat u draait afbreekt, zal er geen core bestand gedropt worden in uw home directory. Zolang de kernbestandsgrootte op nul staat, zijn kerndumps niet toegestaan. Dit is logisch voor de meeste gebruikers omdat ze waarschijnlijk niets meer met een core dump zouden doen dan hem wissen, maar als je een core dump nodig hebt om problemen die je tegenkomt met een applicatie te debuggen, wil je misschien je core bestandsgrootte op onbeperkt zetten — en misschien kan dat.
$ ulimit -c ulimited$ ulimit -cunlimited
Als je een server beheert en je wilt de mogelijkheid om core dumps te genereren voor al je gebruikers aanzetten — misschien zijn het ontwikkelaars die deze core dumps echt moeten kunnen analyseren, dan moet je als gebruiker naar root overschakelen en je /etc/security/limits.conf (Linux) of in /etc/system (Solaris) wijzigen.
Als je daarentegen een server beheert en niet wilt dat één van je gebruikers core dumps kan genereren, hoe graag ze daar ook hun tanden in willen zetten, dan kun je een limiet van 0 instellen in je limits.conf.
Een andere limiet die vaak wordt afgedwongen, is er één die het aantal processen beperkt dat een individu kan draaien. De ulimit optie die hiervoor gebruikt wordt is -u. U kan uw limiet bekijken zoals we hierboven deden met het ulimit -a commando of enkel de “nproc” limiet tonen met het commando ulimit -u.
$ ulimit -u50
Wederom kunnen uw gebruikers hun limieten veranderen met een ander ulimit commando — ulimit -u 100 — tenzij, natuurlijk, ze dat niet kunnen. Als u hen beperkt hebt tot 50 processen in het limits.conf of systeem bestand, zullen ze een fout als deze krijgen wanneer ze hun limieten proberen te verhogen:
$ ulimit -u 100-bash: ulimit: max user processes: cannot modify limit: Operation not permitted
Limieten kunnen ook per groep worden ingesteld, zodat u bijvoorbeeld ontwikkelaars de mogelijkheid kunt geven om meer processen te draaien dan managers. Regels als deze in uw limits.conf bestand zouden dat doen:
@managers hard nproc 50@developers hard nproc 200
Als u het aantal open bestanden wilt beperken, gebruikt u gewoon een andere instelling.
@managers hard nofile 2048@developers hard nofile 8192sbob hard nofile 8192
Hier hebben we twee groepen en een individu verhogingen gegeven in hun open bestanden limieten. Dit zijn allemaal harde limieten. Als u ook zachte limieten instelt, zullen de gebruikers waarschuwingen krijgen als ze de laagste limiet bereiken.
@developers soft nofile 2048@developers hard nofile 8192
Om een lijst van de ulimit opties te zien, kijk op de man page (man ulimit). U zult zien dat ulimit in bash is ingebouwd — tenminste op Linux — en dat de volgende opties beschikbaar zijn:
-a All current limits are reported-c The maximum size of core files created-d The maximum size of a process's data segment-e The maximum scheduling priority ("nice")-f The maximum size of files written by the shell and its children-i The maximum number of pending signals-l The maximum size that may be locked into memory-m The maximum resident set size (has no effect on Linux)-n The maximum number of open file descriptors (most systems do not allow this value to be set)-p The pipe size in 512-byte blocks (this may not be set)-q The maximum number of bytes in POSIX message queues-r The maximum real-time scheduling priority-s The maximum stack size-t The maximum amount of cpu time in seconds-u The maximum number of processes available to a single user-v The maximum amount of virtual memory available to the shell
Als u limits.conf bestand toestaat, ziet u misschien limieten zoals deze ingesteld voor bepaalde toepassingen die de extra capaciteit echt nodig hebben. In dit voorbeeld krijgt de oracle gebruiker de mogelijkheid om tot 16.384 processen te draaien en 65.536 bestanden te openen. Deze regels zouden worden ingesteld in het .bash_profile.
if ; then if ; then ulimit -p 16384 ulimit -n 65536 else ulimit -u 16384 -n 65536 fifi
van de oracle gebruiker