11.13. A rendszermag korlátainak finomhangolása

11.13.1.1. kern.maxfiles

A kern.maxfiles értéke a rendszerünk igényeinek megfelelően növelhető vagy csökkenthető. Ez a változó adja meg a rendszerünkben levő állományleírók maximális számát. Amikor az állományleírókat tároló táblázat megtelik, a rendszer üzenetpufferében egy “file: table is full” üzenet jelenik meg, amit a dmesg paranccsal tudunk megnézni.

Minden megnyitott állomány, csatlakozás vagy FIFO elhasznál egy állományleírót. Egy nagyméretű szerver könnyen felemészthet több ezernyi állományleírót attól függően, hogy milyen és mennyi szolgáltatást futtat egymás mellett.

A FreeBSD korábbi kiadásaiban a kern.maxfiles a rendszermag beállításait tartalmazó állomány maxusers (a rendszerben egyszerre jelenlevő felhasználók maximumának) értékéből származott, tehát a kern.maxfiles a maxusers értékével arányosan növekszik. Amikor készítünk egy saját rendszermagot, mindig érdemes a rendszerünk használatának megfelelően beállítani ezt az értéket, mivel a rendszermag ebből a számból határozza meg a legtöbb előre meghatározott korlátait. Mivel még egy komoly szerveren sem jelentkeznek be egyszerre 256 felhasználónál többen, nagyjából ugyanannyi erőforrásra van szüksége, mint egy nagyobb webszervernek.

A kern.maxusers értéke a rendelkezésre álló memóriának megfelelően magától méreteződik a rendszer indításakor, és amit futás közben csak a kern.maxusers sysctl változó írásvédett értékének lekérdezéséből tudhatunk meg. Egyes oldalak üzemeltetése a kern.maxusers így megállapított értékétől nagyobbat vagy éppen kisebbet igényel, ezért a betöltéskor minden gond nélkül át lehet állítani 64, 128 vagy 256 értékűre. Senkinek sem ajánljuk, hogy 256 felé menjen, hacsak tényleg nincs szüksége ekkora mennyiségű állományleíróra. A kern.maxusers függvényében beállított alapértelmezett értékek tetszőleges módon átállíthatóak a rendszer indításakor vagy futás közben a /boot/loader.conf módosításával (az ide kapcsolódó javaslatokról bővebben lásd a loader.conf(5) man oldalt vagy a /boot/defaults/loader.conf állományt) illetve a leírás más részén megadott módok szerint.

A korábbi kiadásokban úgy lehet önszabályozóra állítani a maxusers beállítást, ha explicit módon 0 értéket adtunk meg neki [1]. A maxusers paraméter beállításakor érdemes legalább 4-et megadni, különösen akkor, ha használjuk az X Window Systemet vagy szoftvereket fordítunk le. Azért van erre szükség, mert a maxusers értéke által szabályozott legfontosabb mennyiség az egyszerre futtatható programok táblázatának maximális mérete, amelyet így számolunk ki: 20 + 16 * maxusers. Tehát ha a maxusers értékét 1-re állítjuk be, akkor az előbbi képlet értelmében csak 36 programunk futhat egymással párhuzamosan, beleértve mindazt a kb. 18 programot, amelyek a rendszerrel együtt indulnak, illetve még azt a további 15 programot, amelyeket az X Window System használatával indítunk el. Még egy olyan egyszerű dolog is, mint például egy man oldal megnézése, legalább kilenc programot indít el a szűréshez, kitömörítéshez és megnézéshez. Azonban ha a maxusers értékét 64-re állítjuk, akkor egyszerre akár már 1044 programot futtathatunk, ami szinte mindenre elegendő. Ha persze egy új program indításakor kapunk egy proc table full típusú üzenetet vagy nagy számú konkurens felhasználóval futtatunk szervert (ilyen például az ftp.FreeBSD.org), akkor érdemes növelni ezt a számot és újrafordítani a rendszermagot.

11.13.1.2. kern.ipc.somaxconn

Az kern.ipc.somaxconn sysctl változó a beérkező TCP kapcsolatokat fogadó sor hosszát határozza meg. Ennek az alapértelmezett értéke 128, ami az új kapcsolatok megbízható kezeléséhez általában kevés egy erősen leterhelt webszerver számára. Ilyen helyzetekben ezt az értéket javasolt 1024-re vagy még annál is nagyobbra állítani. Az egyes szolgáltatások démonai ugyan szintén korlátozni szokták a fogadósoruk méretét (például a sendmail(8) vagy az Apache), de gyakran találunk a beállításai között olyat, amivel ennek a sornak a mérete növelhető. A nagyobb fogadósorok mellesleg jó szolgálatot tesznek a Denial of Service (DoS) típusú támadásokkal szemben is.

11.13.2.1. net.inet.ip.portrange.*

A net.inet.ip.portrange.* sysctl változók vezérlik a TCP és UDP csatlakozásokhoz automatikusan hozzárendelt portszámok tartományát. Három ilyen tartomány létezik: az alsó, az alapértelmezett és a felső tartomány. A legtöbb hálózati program a net.inet.ip.portrange.first és net.inet.ip.portrange.last változók által rendre az 1024-től 5000-ig kijelölt alapértelmezett tartományt használja. A kimenő kapcsolatok is rögzített porttartományokat követnek, és adott körülmények mellett be lehet állítani úgy a rendszerünket, hogy ezen kívül osszon ki portokat. Ez a legtöbbször akkor fordul elő, amikor egy erősen leterhelt webproxyt működtetünk. A porttartományok nem okoznak gondot olyan szervereknél, ahol általában bejövő kapcsolatokra lehet számítani, tehát például webszerverek esetén, vagy ahol korlátozott a kimenő kapcsolatok száma, mint például a levelek továbbításánál. Ha olyan helyzetbe keverednénk, ahol már kifutunk a felhasználható portokból, a net.inet.ip.portrange.last mérsékelt növelésével javasolt kitörni. Ilyenkor a 10000, 20000 vagy 30000 értékek elfogadhatóak. Amikor megváltoztatjuk a porttartományok határait, előtte mindig gondoljuk át, milyen hatással lehet ez a tűzfalra. Egyes tűzfalak blokkolhatnak bizonyos tartományokat (általában az alacsonyabbakat) és arra számítanak, hogy a rendszerek a kimenő kapcsolatokhoz a nagyobb számú portokat használják — ebből kifolyólag nem ajánlott csökkenteni a net.inet.ip.portrange.first értékét.

11.13.2.2. A TCP sávszélesség-késletetés szorzat

A TCP sávszélesség-késleltetés szorzat korlátozása hasonlít a NetBSD-ben megtalálható TCP/Vegas implementációhoz. A net.inet.tcp.inflight.enable sysctl változó 1-re állításával lehet engedélyezni. A rendszer ilyenkor minden egyes kapcsolathoz megpróbálja kiszámítani a sávszélesség-késleltetés szorzatot és az optimális átviteli sebesség fenntartásához illeszkedően korlátozni a hálózat felé küldött adatok sorának hosszát.

Ez a lehetőség még olyankor bizonyulhat hasznosnak, amikor modemen, Gigabit Etherneten vagy nagysebességű WAN (vagy bármilyen más nagy sávszélesség-késleltetés szorzattal bíró) összeköttetéseken keresztül küldünk át adatokat, különösen abban az esetben, amikor ablakméretezést is használnunk vagy nagy küldési ablakot állítottunk be. Az engedélyezésekor ne felejtsük el net.inet.tcp.infligt.debug változót sem beállítani 0-ra (amivel így kikapcsoljuk a nyomkövetést),éles használat esetén pedig előnyös lehet a net.inet.cp.inflight.min változót legalább 6144-re állítani. Azonban hozzátesszük, hogy összeköttetéstől függően a nagy minimum értékek tulajdonképpen kikapcsolják a sávszélességkorlátozást. Ez a korlátozási lehetőség csökkenti a közbenső út adatainak és csomagváltásokhoz tartozó soroknak a méretét, miközben csökkenti a helyi számítógép felületén felépülő sorok méretét is. Ha kevesebb csomagot rakunk be a sorba, akkor az interaktív kapcsolatok, különösen a lassabb modemek esetében, kisebb körbejárási idővel (Round Trip Time) működnek. Továbbá megemlítenénk, hogy ez a lehetőség csak az adatok küldésére (feltöltésére, szerveroldalra) van hatással. Semmilyen befolyása nincs az adatok fogadására (letöltésére).

A net.inet.tcp.inflight.stab állítgatása nem ajánlott. A paraméter értéke alapértelmezés szerint 20, ami legfeljebb 2 csomag hozzáadását jelenti a sávszélesség-késleltetés szorzat ablakának kiszámításakor. Erre a kiegészítő ablakra azért van szükség, hogy stabilizálni tudjuk vele az algoritmust és javítani tudjuk a változó feltételekre adott reakciót, de lassabb összeköttetések esetében nagyobb ping időket is eredményezhet (habár ezek még így kisebbek, mint ha nem használnánk az algoritmust). Ilyen esetekben megpróbálhatjuk 15-re, 10-re vagy esetleg 5-re visszavenni a paraméter értékét, de ekkor a kívánt hatás eléréséhez minden bizonnyal a net.inet.tcp.inflight.min értékét is redukálunk kell majd (például 3500-ra). Ezen paraméterek megváltoztatását csak végső esetben ajánljuk!

11.13.3.1. kern.maxvnodes

A vnode egy állomány vagy könyvtár belső ábrázolása. Ennek megfelelően a vnode-ok számának növelésével az operációs rendszer spórolni tud a lemezműveletekkel. Ezt általában maga az operációs rendszer szabályozza, és nincs szükség a finomhangolására. Néhány esetben, amikor a lemezműveletek jelentik a rendszerben a szűk keresztmetszetet és kezdenek elfogyni a vnode-ok, szükség lehet ennek a számnak a növelésére. Ehhez az inaktív és szabad fizikai memória mennyiségét kell számításba vennünk.

Így kérhetjük le a pillanatnyilag használatban levő vnode-ok mennyiségét:

# sysctl vfs.numvnodes
vfs.numvnodes: 91349

Így tudhatjuk meg a vnode-ok maximális számát:

# sysctl kern.maxvnodes
kern.maxvnodes: 100000

Ha a vnode-ok aktuális kihasználtsága megközelíti a csúcsértéket, nagyjából ezerrel javasolt megnövelni a kern.maxvnodes értékét. Ezután figyeljük továbbra is a vfs.numvnodes változását. Ha ismét felkúszik a maximális értékre, akkor növeljük megint egy keveset a kern.maxvnodes értékén. Eközben a top(1) használatával figyelhetjük a memória kihasználtságának növekedését is, ilyenkor tehát több memóriának kell használatban lennie.