Administrera Unix-servrar kan vara en utmaning, särskilt när systemen du hanterar används flitigt och prestandaproblem minskar tillgängligheten. Som tur är kan du sätta gränser för vissa resurser för att se till att de viktigaste processerna på dina servrar kan fortsätta att köras och att konkurrerande processer inte förbrukar mycket mer resurser än vad som är bra för hela systemet. Kommandot ulimit kan hålla katastrofen i schack, men du måste förutse var begränsningar är meningsfulla och var de kommer att orsaka problem.
Det händer kanske inte så ofta, men en enskild användare som startar för många processer kan göra ett system obrukbart för alla andra. En gaffelbomb – en överbelastningsattack där en process kontinuerligt replikerar sig själv tills de tillgängliga resurserna är uttömda – är det värsta exemplet på detta. Även vänliga användare kan dock använda mer resurser än vad som är bra för ett system — ofta utan att det är meningen. Samtidigt kan legitima processer ibland misslyckas när de körs mot gränser som är utformade för genomsnittliga användare. I det här fallet måste du se till att dessa processer får förstärkta tilldelningar av systemresurser som gör att de kan köras ordentligt utan att göra samma resurser tillgängliga för alla.
För att se de gränser som är associerade med din inloggning använder du kommandot ulimit -a. Om du använder ett vanligt användarkonto kommer du troligen att se något som liknar detta:
$ 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 sak som du kanske märker direkt är att du inte kan skapa core-dumps – eftersom din max core-filstorlek är 0. Ja, det betyder ingenting, inga data, ingen core-dump. Om en process som du kör avbryts kommer ingen kärnfil att släppas till din hemkatalog. Så länge som kärnfilstorleken är inställd på noll tillåts inte core dumps. Detta är vettigt för de flesta användare eftersom de förmodligen inte skulle göra något mer med en core dump än att radera den, men om du behöver en core dump för att felsöka problem som du stöter på med ett program kanske du vill ställa in din core file size till obegränsad – och kanske kan du göra det.
$ ulimit -c ulimited$ ulimit -cunlimited
Om du hanterar en server och vill aktivera möjligheten att generera core-dumps för alla dina användare – kanske är det utvecklare som verkligen behöver kunna analysera dessa core-dumps, måste du byta användare till root och redigera din /etc/security/limits.conf (Linux) eller göra ändringar i filen /etc/system (Solaris).
Om du å andra sidan hanterar en server och inte vill att någon av dina användare ska kunna generera core dumps, oavsett hur mycket de vill sätta tänderna i en sådan, kan du ställa in en gräns på 0 i din limits.conf.
En annan gräns som ofta tillämpas är en gräns som begränsar antalet processer som en person kan köra. Det ulimit-alternativ som används för detta är -u. Du kan titta på din gräns som vi gjorde ovan med kommandot ulimit -a eller visa bara ”nproc”-gränsen med kommandot ulimit -u.
$ ulimit -u50
Ennu en gång kan dina användare ändra sina gränser med ett annat ulimit-kommando – ulimit -u 100 – om de inte kan göra det, såklart. Om du har begränsat dem till 50 processer i filen limits.conf eller systemfilen får de ett sådant här fel när de försöker öka sina gränser:
$ ulimit -u 100-bash: ulimit: max user processes: cannot modify limit: Operation not permitted
Limiter kan också ställas in per grupp så att du till exempel kan ge utvecklare möjlighet att köra fler processer än chefer. Rader som dessa i filen limits.conf skulle göra det:
@managers hard nproc 50@developers hard nproc 200
Om du vill begränsa antalet öppna filer använder du bara en annan inställning.
@managers hard nofile 2048@developers hard nofile 8192sbob hard nofile 8192
Här har vi gett två grupper och en individ ökade gränser för öppna filer. Dessa har alla satt hårda gränser. Om du också ställer in mjuka gränser kommer användarna att få varningar när de når den nedre gränsen.
@developers soft nofile 2048@developers hard nofile 8192
För att se en lista över ulimit-alternativen kan du titta på man-sidan (man ulimit). Du kommer att märka att ulimit är en bash-inbyggd – åtminstone på Linux – och att följande alternativ är tillgängliga:
-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
Om du tillåter filen limits.conf kan du kanske se gränser som dessa som är uppsatta för särskilda program som verkligen behöver den extra kapaciteten. I det här exemplet får oracle-användaren möjlighet att köra upp till 16 384 processer och öppna 65 536 filer. De här raderna skulle ställas in i oracle-användarens .bash_profile.
if ; then if ; then ulimit -p 16384 ulimit -n 65536 else ulimit -u 16384 -n 65536 fifi