Administration af Unix-servere kan være en udfordring, især når de systemer, du administrerer, er meget brugte, og problemer med ydeevnen reducerer tilgængeligheden. Heldigvis kan du sætte grænser for visse ressourcer for at hjælpe med at sikre, at de vigtigste processer på dine servere kan blive ved med at køre, og at konkurrerende processer ikke bruger langt flere ressourcer, end det er godt for det samlede system. Kommandoen ulimit kan holde katastrofen på afstand, men du skal forudse, hvor begrænsninger vil give mening, og hvor de vil skabe problemer.
Det sker måske ikke så ofte, men en enkelt bruger, der starter for mange processer, kan gøre et system ubrugeligt for alle andre. En gaffelbombe — et denial of service-angreb, hvor en proces hele tiden replikerer sig selv, indtil de tilgængelige ressourcer er opbrugt — er et værste tilfælde af dette. Men selv venlige brugere kan bruge flere ressourcer end godt er for et system — ofte uden at det er hensigten. Samtidig kan legitime processer undertiden fejle, når de kører mod grænser, der er beregnet til almindelige brugere. I dette tilfælde skal du sørge for, at disse processer får opstrammede tildelinger af systemressourcer, der gør det muligt for dem at køre ordentligt uden at gøre de samme ressourcer tilgængelige for alle.
For at se de grænser, der er tilknyttet dit login, skal du bruge kommandoen ulimit -a. Hvis du bruger en almindelig brugerkonto, vil du sandsynligvis se noget som dette:
$ 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
En ting, du måske bemærker med det samme, er, at du ikke kan oprette core-dumps – fordi din maksimale core-filstørrelse er 0. Ja, det betyder ingenting, ingen data, ingen core-dump. Hvis en proces, som du kører, afbrydes, vil der ikke blive lagt nogen core-fil i din hjemmemappe. Så længe core-filstørrelsen er sat til nul, er core-dumps ikke tilladt. Dette giver mening for de fleste brugere, da de sandsynligvis ikke vil gøre andet med et core dump end at slette det, men hvis du har brug for et core dump til at debugge problemer, du støder på med et program, vil du måske ønske at indstille din core filstørrelse til ubegrænset – og måske kan du det.
$ ulimit -c ulimited$ ulimit -cunlimited
Hvis du administrerer en server og ønsker at slå muligheden for at generere core-dumps til for alle dine brugere — måske er de udviklere er virkelig nødt til at kunne analysere disse core-dumps, skal du skifte bruger til root og redigere din /etc/security/limits.conf (Linux) eller foretage ændringer i din /etc/system (Solaris) fil.
Hvis du på den anden side administrerer en server og ikke ønsker, at nogen af dine brugere kan generere core dumps, uanset hvor meget de gerne vil sætte tænderne i en, kan du sætte en grænse på 0 i din limits.conf.
En anden grænse, der ofte håndhæves, er en grænse, der begrænser antallet af processer, som en person kan køre. Den ulimit-indstilling, der bruges til dette, er -u. Du kan se din grænse som vi gjorde ovenfor med kommandoen ulimit -a eller vise kun “nproc”-grænsen med kommandoen ulimit -u.
$ ulimit -u50
Etter engang kan dine brugere ændre deres grænser med en anden ulimit-kommando — ulimit -u 100 — medmindre de selvfølgelig ikke kan det. Hvis du har begrænset dem til 50 processer i limits.conf- eller systemfilen, vil de få en fejl som denne, når de forsøger at øge deres grænser:
$ ulimit -u 100-bash: ulimit: max user processes: cannot modify limit: Operation not permitted
Limits kan også opstilles efter gruppe, så du f.eks. kan give udviklere mulighed for at køre flere processer end ledere. Linjer som disse i din limits.conf-fil ville gøre det:
@managers hard nproc 50@developers hard nproc 200
Hvis du ønsker at begrænse antallet af åbne filer, bruger du bare en anden indstilling.
@managers hard nofile 2048@developers hard nofile 8192sbob hard nofile 8192
Her har vi givet to grupper og en enkeltperson øgede grænser for deres åbne filer. Disse har alle sat hårde grænser. Hvis du også indstiller bløde grænser, vil brugerne få advarsler, når de når den nedre grænse.
@developers soft nofile 2048@developers hard nofile 8192
For at se en liste over ulimit-indstillingerne skal du se på man-siden (man ulimit). Du vil bemærke, at ulimit er indbygget i bash — i det mindste på Linux — og at følgende indstillinger er tilgængelige:
-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
Hvis du limits.conf-filen tillader det, kan du måske se begrænsninger som disse opsat for bestemte programmer, der virkelig har brug for den ekstra kapacitet. I dette eksempel får oracle-brugeren mulighed for at køre op til 16.384 processer og åbne 65.536 filer. Disse linjer ville blive opsat i oracle-brugerens .bash_profile.
if ; then if ; then ulimit -p 16384 ulimit -n 65536 else ulimit -u 16384 -n 65536 fifi