:llä
Unix-palvelimien hallinnointi voi olla haastavaa, varsinkin kun hallinnoimasi järjestelmät ovat kovassa käytössä ja suorituskykyongelmat heikentävät käytettävyyttä. Onneksi voit asettaa tietyille resursseille rajoituksia, joiden avulla voit varmistaa, että palvelinten tärkeimmät prosessit pysyvät käynnissä ja että kilpailevat prosessit eivät kuluta paljon enemmän resursseja kuin on hyvä koko järjestelmän kannalta. Komento ulimit voi pitää katastrofin loitolla, mutta sinun on ennakoitava, missä rajoitukset ovat järkeviä ja missä ne aiheuttavat ongelmia.
Se ei ehkä tapahdu kovin usein, mutta yksittäinen käyttäjä, joka käynnistää liikaa prosesseja, voi tehdä järjestelmästä käyttökelvottoman kaikille muille. Haarautumispommi — palvelunestohyökkäys, jossa prosessi monistaa itseään jatkuvasti, kunnes käytettävissä olevat resurssit loppuvat — on pahin tapaus tästä. Ystävällisetkin käyttäjät voivat kuitenkin käyttää enemmän resursseja kuin järjestelmälle on hyväksi – usein tahattomasti. Samaan aikaan lailliset prosessit voivat joskus epäonnistua, kun niitä ajetaan rajoituksia vastaan, jotka on suunniteltu keskivertokäyttäjille. Tällöin on varmistettava, että näille prosesseille jaetaan järjestelmäresursseja niin, että ne voivat toimia kunnolla ilman, että samat resurssit ovat kaikkien käytettävissä.
Käytä komentoa ulimit -a nähdäksesi kirjautumiseesi liittyvät rajoitukset. Jos käytät tavallista käyttäjätiliä, näet todennäköisesti jotain tällaista:
$ 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
Yksi asia, jonka saatat huomata heti alkuun, on se, että et voi luoda core-dumppeja – koska core-tiedoston maksimikoko on 0. Kyllä, se tarkoittaa, ettei mitään, ei dataa, ei core-dumppia. Jos suorittamasi prosessi keskeytyy, mitään ydintiedostoa ei tiputeta kotihakemistoosi. Niin kauan kuin ydintiedoston koko on asetettu nollaan, ydintiedostojen dumppaus ei ole sallittua. Tämä on järkevää useimmille käyttäjille, koska he eivät luultavasti tee core-dumpilla mitään muuta kuin pyyhkivät sen pois, mutta jos tarvitset core-dumppia sovelluksen kanssa ilmenevien ongelmien vianmääritykseen, saatat haluta asettaa core-tiedoston koon rajattomaksi – ja ehkä voitkin.
$ ulimit -c ulimited$ ulimit -cunlimited
Jos hallinnoit palvelinta ja haluat ottaa käyttöön kyvyn luoda core-dumppeja kaikille käyttäjillesi – ehkä he ovat kehittäjiä, jotka todella tarvitsevat mahdollisuuden analysoida näitä core-dumppeja, sinun on vaihdettava käyttäjä rootiksi ja muokattava /etc/security/limits-tiedostoa.conf (Linux) tai tehdä muutoksia tiedostoon /etc/system (Solaris).
Jos taas hallinnoit palvelinta etkä halua, että kukaan käyttäjistäsi voi luoda core-dumpeja riippumatta siitä, kuinka paljon he haluaisivat upottaa hampaansa sellaiseen, voit asettaa limits.conf-tiedostoon raja-arvoksi 0.
Toinen rajoitus, jota usein käytetään, on rajoitus, joka rajoittaa yksittäisen henkilön suorittamien prosessien määrää. Tähän käytetty ulimit-optio on -u. Voit tarkastella rajojasi kuten edellä teimme komennolla ulimit -a tai näyttää vain ”nproc”-rajan komennolla ulimit -u.
$ ulimit -u50
Jälleen kerran käyttäjät voivat muuttaa rajojaan toisella ulimit-komennolla – ulimit -u 100 – elleivät he tietenkään voi. Jos olet rajoittanut heidät 50 prosessiin limits.conf- tai järjestelmätiedostossa, he saavat tällaisen virheilmoituksen yrittäessään kasvattaa rajojaan:
$ ulimit -u 100-bash: ulimit: max user processes: cannot modify limit: Operation not permitted
Limiitit voidaan asettaa myös ryhmäkohtaisesti, jolloin voit esimerkiksi antaa kehittäjille mahdollisuuden ajaa enemmän prosesseja kuin johtajille. Tällaiset rivit limits.conf-tiedostossa tekisivät tämän:
@managers hard nproc 50@developers hard nproc 200
Jos haluat rajoittaa avointen tiedostojen määrää, käytät vain eri asetusta.
@managers hard nofile 2048@developers hard nofile 8192sbob hard nofile 8192
Tässä olemme antaneet kahdelle ryhmälle ja yhdelle yksilölle korotuksia avointen tiedostojen rajoihin. Nämä kaikki asettavat kovat rajat. Jos asetat myös pehmeät rajat, käyttäjät saavat varoituksia, kun he saavuttavat alemman rajan.
@developers soft nofile 2048@developers hard nofile 8192
Luettelon ulimit-asetuksista saat man-sivulta (man ulimit). Huomaat, että ulimit on bashin sisäänrakennettu – ainakin Linuxissa – ja että seuraavat vaihtoehdot ovat käytettävissä:
-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
Jos limits.conf-tiedosto sallii, saatat nähdä tällaisia rajoituksia asetettuna tietyille sovelluksille, jotka todella tarvitsevat lisäkapasiteettia. Tässä esimerkissä oracle-käyttäjälle annetaan mahdollisuus ajaa enintään 16 384 prosessia ja avata 65 536 tiedostoa. Nämä rivit asetettaisiin oracle-käyttäjän .bash_profile.
if ; then if ; then ulimit -p 16384 ulimit -n 65536 else ulimit -u 16384 -n 65536 fifi
-profiiliin.