11.13. A rendszermag korlátainak finomhangolása
Vissza | 11. fejezet - Beállítás és finomhangolás | Előre

## 11.13. A rendszermag korlátainak finomhangolása

### 11.13.1. Az állományok és a futó programok korlátozásai

#### 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 [5]. 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.

### Megjegyzés:

A `maxusers` nem korlátozza a számítógépre egyszerre bejelentkezni képes felhasználók számát. Egyszerűen csak beállítja néhány táblázat méretét és az egyszerre futtatható programok mennyiségét a rendszert egyidejűleg használni kívánó felhasználók maximális számának figyelembevételével.

#### 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. Hálózati korlátozások

A rendszermag `NMBCLUSTERS` nevű beállítása szab határt a rendszer részére elérhető memóriapufferek mennyiségének. Egy nagyobb forgalmú szerver esetén a pufferek alacsony száma gátat szabhat a FreeBSD képességeinek. Minden klaszter nagyjából 2 KB memóriát takar, így az 1024-es érték azt jelenti, hogy a rendszermag memóriájából 2 megabyte-ot fordítunk a hálózati pufferelésre. Egyszerűen kiszámítható, mennyire is van szükségünk: ha van egy webszerverünk, amely egyszerre legfeljebb 1000 párhuzamos kapcsolatot fogad, és minden kapcsolat lefoglal 16 KB-ot a fogadó-, valamint újabb 16 KB-ot a küldőpuffer számára, akkor megközelítőleg 32 MB-nyi hálózati pufferre lesz szükségünk a webszerver hatékony működéséhez. Ezt az értéket gyakran még érdemes megszorozni kettővel, így 2 x 32 MB / 2 KB = 64 MB / 2 KB = 32768. Több memóriával rendelkező számítógépek esetén egy 4096 és 32768 közti értéket javaslunk. Semmilyen körülmények között ne adjunk meg ennél nagyobb értéket, mert ezzel a rendszer már az indítása során összeomolhat. A netstat(1) `-m` beállításával ellenőrizhetjük a hálózati klaszterek kihasználtságát.

A `kern.ipc.nmbclusters` változó értékét a rendszer indításakor érdemes megváltoztatni. A FreeBSD korábbi változataiban ehhez a rendszermag `NMBCLUSTERS` nevű config(8) paraméterének módosítására van szükségünk.

Az olyan forgalmasabb szervereken, ahol sokat használják a sendfile(2) rendszerhívást, szükségünk lehet a sendfile(2) által használt pufferek számának növelésére a rendszermag `NFSBUFS` nevű konfigurációs paraméterén vagy a `/boot/loader.conf` állományon keresztül (lásd loader(8)). Amikor a futó programok közül sokan vannak `sfbufa` állapotban, akkor az egyértelműen annak a jele, hogy ezen a paraméteren állítanunk kell. A `kern.ipc.nsfbufs` egy írásvédett változót, amelyet a rendszermag állít be. Ez a paraméter névlegesen a `kern.maxusers` változó értékének megfelelően változik, de bizonyos esetekben ettől függetlenül önállóan kell behangolni.

### Fontos:

Annak ellenére, hogy egy socketet blokkolásmentesnek jelöltünk meg, a sendfile(2) meghívása egy blokkolásmentes socketre blokkolódást eredményezhet egészen addig, amíg a használatához elegendő `struct sf_buf` struktúra össze nem gyűlik.

#### 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. Virtuális memória

#### 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.

[5] Az önszabályozó algoritmus a `maxusers` értékét a rendszerben található memóriának megfelelően legalább 32-re, legfeljebb 384-re állítja.

Vissza | Fel | Előre
11.12. A lemezek finomhangolása | Főoldal | 11.14. A lapozóterület bővítése

Ha kérdése van a FreeBSD-vel kapcsolatban, a következő címre írhat (angolul): <questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon: <gabor@FreeBSD.org>.