CloudLinux erőforrás limitek

A CloudLinux OS a következő erőforrások korlátozását tudja, támogatja:

Az alábbiakban ajánlásokat talál a tipikus megosztott tárhely beállításokhoz. Az ajánlások nem függnek a szerver teljesítményétől. Csak attól függenek, hogy mennyire “gyorsak” szeretnéd, hogy a tárhely-fiókjaid legyenek.

A limitek magyarázata

Az LVE egy kernel szintű technológia, amelyet a CloudLinux csapat fejlesztett ki. A technológia közös gyökerei a konténer alapú virtualizációval vannak, és legújabb inkarnációjában a cgroups-ot használja. Könnyűsúlyú és átlátható. Az LVE célja, hogy egyetlen weboldal se tudja leállítani a webszerverét.

Ma egyetlen webhely képes elfogyasztani az összes CPU, IO, memória erőforrást vagy Apache folyamatot - és leállítani a szervert. Az LVE ezt megakadályozza. Ez az Apache modul, a PAM modul és a kernel együttműködésével történik.

mod_hostinglimits egy Apache modul, amely:

• észleli a VirtualHostot, ahonnan a kérés érkezett;
• felismeri, hogy CGI vagy PHP szkriptnek szánták-e;
• a kérés kiszolgálásához használt Apache folyamatot az LVE-be helyezi a SuexecUserGroup utasítással meghatározott felhasználó számára az adott virtuális hoszthoz;
• hagyja, hogy az Apache kiszolgálja a kérést;
• eltávolítja az Apache folyamatot a felhasználó LVE-jéből.

A kernel gondoskodik arról, hogy minden LVE méltányos részesedést kapjon a szerver erőforrásaiból, és hogy egyetlen ügyfél se használhasson többet az adott ügyfél számára beállított korlátoknál. Ma már korlátozhatjuk a CPU , a memória (virtuális és fizikai), az IO, a folyamatok számát, valamint a belépő folyamatok számát (egyidejű kapcsolatok az apache-hoz).

Minden LVE korlátozza a belépő folyamatok (az LVE-be belépő Apache-folyamatok) mennyiségét, hogy megakadályozza, hogy egyetlen webhely kimerítse az összes Apache-folyamatot. Ha a határértéket elérjük, akkor a mod_hostinglimits nem lesz képes Apache folyamatot elhelyezni az LVE-ben, és 508-as hibakódot fog visszaadni. Így a nagyon nehéz webhelyek lelassulnak és elkezdenek 508-as hibákat küldeni, anélkül, hogy ez hatással lenne a többi felhasználóra.

• Ha a webhelyet CPU vagy IO korlátozza, akkor a webhely lassabban fog reagálni.
• Ha a webhelyet korlátozza a memória vagy a folyamatok száma, akkor a felhasználó 500 vagy 503 hibát fog kapni, hogy a szerver nem tudja végrehajtani a szkriptet.

Az LVE telepítésének ellenőrzése

Az LVE használatához telepített CloudLinux OS Shared kernelre és betöltött LVE modulra van szükség. A kernelt a következő parancs futtatásával ellenőrizheti:

uname -r

Valami olyasmit kell látnod, mint 4.18.0-425.3.1.lve.1.el8.x86_64. A kernel nevében lve-nek kell szerepelnie. Ha meg akarod nézni, hogy az lve kernel modul betöltődött-e, futtasd a következőt:

$ lsmod|grep lve
kmodlve             34320384  11

### LVE limitek beállítása

Az LVE értékek ellenőrzésének legjobb módja a kedvenc vezérlőpanelén (pl. cPanel) található LVE-kezelő használata. Alternatívaként használhatja az lvectl parancssori eszközt is a limitek vezérlésére. A limitek az /etc/container/ve.cfg fájlba kerülnek mentésre.

<?xml version="1.0" ?>
<lveconfig>
 <defaults>
         <cpu limit="25"/>
         <ncpu limit="1"/>
         <io limit="1024"/>
         <mem limit="262144"/>
         <other maxentryprocs="200"/>
         <pmem limit="262144"/>
         <nproc limit="0"/>
 </defaults>
 <lve id="532">
         <cpu limit="30"/>
         <ncpu limit="5"/>
 </lve>
</lveconfig>

A fenti értékek a CPU-korlátot 25%-ra, az IO-korlátot 1024KB/s-ra, a virtuális memória korlátját 1GB-ra (a memória korlátja 4096 byte-os oldalak számaként van beállítva, tehát az érteket be kell szorozni 4096-val), a fizikai memória korlátját 1GB-ra, a CPU-magok számát LVE-nként 1-re, az entry processek maximális számát 200-ra, a folyamatok számát pedig nem korlátozza az összes LVE esetében. Az 532-es azonosítóval rendelkező LVE esetében a 30%-os korlátot és a folyamatok számának korlátozását 5-re állítja be.

SPEED limit

A CPU SPEED limit lehetővé teszi a CPU limit beállítását egy mag %-ában, vagy fix Hz értékként.

A --speed=XX% egy maghoz viszonyított teljesítményt állítana be.

Például:

• –speed=50% 1/2 CPU magot jelentene.
• –speed=100% 1 magot jelentene,
• –speed=150% 1,5 magot jelentene.
• –speed=XXmhz automatikusan észleli az egyes magok CPU-sebességét, és beállítja a CPU ütemezőt, hogy a felhasználó ne léphesse túl ezt a határt.

Például 1ghz-es CPU esetén a –speed=2ghz beállítása 2 magot jelentene, míg 4ghz-es CPU esetén ugyanez a beállítás 1/2 magot jelentene.

Ez lehetővé tenné a tárhelyszolgáltatók számára, hogy a különböző hardverek esetében egyetlen beállítással közelítőleg azonos teljesítményszint-korlátokat állítsanak be.

Megjegyzés: Erősen javasoljuk, hogy a CPU sebességkorlátok beállítása ne legyen kevesebb, mint 100%. Mivel az ilyen korlátok CPU-kontextus váltást okoznak, ami megnövekedett %sys értéket eredményez.

Fizikai memóriakorlát

A fizikai memóriakorlát a végfelhasználói folyamatok által ténylegesen használt memória mennyiségének felel meg. Az egyes folyamatok fizikai memóriahasználatát a folyamat felső kimenetének RES oszlopának figyelésével láthatja. Mivel a hasonló folyamatok (például a PHP) sok memóriát megosztanak, a fizikai memóriahasználat gyakran sokkal alacsonyabb, mint a virtuális memóriahasználat.

Ezen kívül a fizikai memória tartalmazza az ügyfél által használt megosztott memóriát, valamint a lemez gyorsítótárat is. A lemez gyorsítótár esetében - ha egy felhasználónak kezd hiányozni a fizikai memória, a lemez gyorsítótárhoz használt memória felszabadul, anélkül, hogy memóriahibákat okozna.

Amikor az LVE túllépi a fizikai memória határértékét, a CloudLinux OS Shared először felszabadítja a lemez gyorsítótárhoz használt memóriát, és ha ez nem elég, akkor megöl néhány folyamatot az adott LVE-n belül, és növeli az fPMEM számlálót. Ez általában 500-as és 503-as hibák kiszolgálását okozza a webszerver számára. A fizikai memóriakorlátozás sokkal jobb módja a memória korlátozásának a megosztott tárhely esetében.

IO

Az IO-korlátok korlátozzák az ügyfél lemez elérési teljesítményét. Ezek KB/s-ban vannak megadva. Ha a határértéket elérik, a folyamatokat visszafogják (alvó üzemmódba helyezik). Ez biztosítja, hogy az LVE-n belüli folyamatok ne léphessék túl a limitet. Mégsem hagyják abba a munkát, és nem is ölik meg őket - csak lassabban dolgoznak, amikor elérik a korlátot.

Az IO-korlátok csak a DISK IO-t érintik, a hálózatra nincs hatásuk. Nem veszi figyelembe a lemez gyorsítótárhoz való hozzáféréseket sem. Tehát, még ha 1000-szer töltődik is be egy fájl a lemez gyorsítótárából - ez nem számít bele az IO-korlátokba.

IOPS

Az IOPS-korlátok a másodpercenkénti olvasási/írási műveletek teljes számát korlátozzák. A határérték elérésekor az olvasási/írási műveletek leállnak az aktuális másodperc lejártáig.

Entry processzek

A “belépési folyamatok” (Entry processes) korlátja az LVE-be történő belépések számát szabályozza. Minden egyes alkalommal, amikor egy folyamat “belép” az LVE-be, növeljük a számlálót. Minden alkalommal, amikor egy folyamat kilép az LVE-ből, a számlálót csökkentjük. Nem számoljuk azokat a folyamatokat, amelyek magában az LVE-ben jönnek létre. Ez az “Apache concurrent connections” (Apache egyidejű kapcsolatok) korlátként is ismert.

A folyamat akkor lép be az LVE-be, amikor új HTTP-kérés érkezik a CGI/PHP számára.

Ezt a korlátot a webszerver elleni DoS-támadások megelőzésére hozták létre. Az egyik meglehetősen népszerű támadás az összes Apache-kapcsolat lekötése a szerver valamelyik lassú oldalának elérésével. Amint az összes Apache-hely elfogyott, senki más nem tud csatlakozni a webkiszolgálóhoz, így az leálltnak tűnik. A problémát tovább rontják a CPU-korlátok, mivel ha az oldal a CPU-korlát miatt lassulni kezd - egyre lassabban és lassabban fog válaszolni a kérésekre, ami egyre több és több kapcsolat lekötését okozza.

Ennek megoldására létrehoztuk a belépési folyamatok (gyakran párhuzamos kapcsolatoknak nevezett) limitet. Ez korlátozza az egyidejű kapcsolatok számát az Apache-hoz, ami azt okozza, hogy a webszerver 508 hibaoldalt ( Resource Limit Reached) szolgáltat, amint a webhelyre irányuló egyidejű kérések száma meghaladja a korlátot.

A LiteSpeed webkiszolgálóval való munka esetén a belépési folyamatok korlátjának megvalósítása eltér az Apache-ban megvalósítottól.

Ezért, ha azonos terhelés van egyidejű kérésekkel az Apache és a LiteSpeed számára, a belépési folyamatok korlátja a webszerver függvényében eltérő lehet.

A LiteSpeed esetében az Entry processes limit az lsphp master folyamatok számával nő, például munkacsoportos üzemmódban a webszerver csak egy lsphp master folyamatot indít, akkor ez a folyamat a kérések feldolgozásához gyermekfolyamatokat forkoltat, anélkül, hogy az Entry processes limit növekedne.

Ha a LiteSpeed segítségével szeretné beállítani az egyidejű kapcsolat limitet, használhatja a szabványos webszerver eszközöket, mint például a https://docs.litespeedtech.com/cp/cpanel/antiddos/#connection-throttling.

Folyamatok száma

Az NPROC szabályozza a folyamatok és szálak teljes számát az LVE-n belül. A limit elérése után nem hozható létre új folyamat (amíg egy másik el nem hal). Amikor ez megtörténik, az NPROC számláló növekszik. Az Apache ilyen esetben 500 vagy 503 hibát adhat vissza.

Inodeok

Az LVE Manager inodes limits bővítmény lehetővé teszi az ügyfelek számára az inode limitek beállítását. Az inode egy fájlrendszer adatstruktúrája, amely egy fájl vagy mappa információinak tárolására szolgál. Az inode-ok száma jelzi, hogy egy fiók hány fájl és mappa van. inodes limits a lemezkvóta szintjén működik , és csak a /home partíción lesz engedélyezve.

Az LVE Manager lehetővé teszi a soft és hard IO limit beállítását.

• A hard limit megakadályozza, hogy a felhasználó adatokat írjon a lemezre.
• A puha limitet egy bizonyos ideig lehet túllépni. A türelmi idő a következővel állítható be: edquota -t .
• Az LVE Manager segítségével ugyanúgy beállíthatja az inodes limiteket, mint bármely más LVE limitet:

Kompatibilitási mátrix

Megjegyzés: Kérjük, vegye figyelembe, hogy a mod_lsapi nem működik, ha a php-fpm engedélyezve van, mivel a php-fpm ugyanúgy egy PHP kezelő, mint a mod_lsapi.

Megjegyzés: A mod_lsapi egy Apache modul, míg a LiteSpeed egy önálló megoldás, és nem használ egyetlen Apache modult sem (mivel saját implementációt biztosít ezeknek a moduloknak). Ezenfelül tanácsos az Apache konfigurációját változatlanul hagyni arra az esetre, ha úgy döntene, hogy visszavált a LiteSpeedről.