Ilya Kosmodemyansky 2015-ös jelentésének átirata "Linux tuning a PostgreSQL teljesítményének javítása érdekében"
Jogi nyilatkozat: Megjegyzem, hogy ez a jelentés 2015. novemberi keltezésű – több mint 4 év telt el, és sok idő telt el. A jelentésben tárgyalt 9.4-es verzió már nem támogatott. Az elmúlt 4 évben a PostgreSQL 5 új kiadása, és a Linux kernel 15 verziója jelent meg. Ha átírja ezeket a részeket, akkor egy másik jelentést kap. De itt figyelembe vesszük az alapvető Linux-hangolást a PostgreSQL-hez, amely ma is aktuális.
A nevem Ilya Kosmodemyansky. A PostgreSQL-Consultingnál dolgozom. És most beszélek egy kicsit arról, hogy mi a teendő a Linux-szal általában az adatbázisokkal és a PostgreSQL-lel kapcsolatban, mert az elvek meglehetősen hasonlóak.
Miről fogunk beszélni? Ha PostgreSQL-lel kommunikál, akkor bizonyos mértékig UNIX rendszergazdának kell lennie. Mit jelent? Ha összehasonlítjuk az Oracle-t és a PostgreSQL-t, akkor az Oracle-ben 80%-ban DBA adatbázis-adminisztrátornak és 20%-ban Linux rendszergazdának kell lenni.
A PostgreSQL-lel ez egy kicsit bonyolultabb. A PostgreSQL-lel sokkal jobban meg kell értened a Linux működését. És közben fuss egy kicsit a mozdony után, mert mostanában egész szépen frissült minden. És új kernelek jelennek meg, új funkciók jelennek meg, javul a teljesítmény stb.
Miért beszélünk Linuxról? Egyáltalán nem azért, mert ott vagyunk a Peter Linux konferencián, hanem azért, mert modern körülmények között az egyik legindokoltabb operációs rendszer az adatbázisok általános és a PostgreSQL használatára különösen a Linux. Mert a FreeBSD sajnos valami nagyon furcsa irányba fejlődik. És lesznek problémák a teljesítménnyel és sok más dologgal is. A PostgreSQL teljesítménye Windows rendszeren általában külön komoly probléma, ami abból adódik, hogy a Windows nem rendelkezik ugyanazzal a megosztott memóriával, mint a UNIX, míg a PostgreSQL mind ehhez kötődik, mert egy többfolyamatos rendszerről van szó.
És szerintem mindenkit kevésbé érdekelnek az olyan egzotikumok, mint a Solaris, úgyhogy menjünk.
Egy modern Linux disztribúció több mint 1 syctl opcióval rendelkezik, attól függően, hogy hogyan építi fel a kernelt. Ugyanakkor, ha megnézzük a különböző diókat, sokféleképpen módosíthatunk valamit. Vannak fájlrendszer-paraméterek a csatlakoztatásukhoz. Ha kérdése van az indítással kapcsolatban: mit kell engedélyezni a BIOS-ban, hogyan kell beállítani a hardvert stb.
Ez egy nagyon nagy kötet, amelyet több napon keresztül is meg lehet beszélni, és nem egy rövid jelentésben, hanem most a fontos dolgokra koncentrálok, hogyan kerüljük el azokat a rake-eket, amelyek garantáltan megakadályozzák az adatbázis megfelelő használatát Linuxon, ha ne javítsd ki őket. Ugyanakkor fontos szempont, hogy sok alapértelmezett paraméter nem szerepel az adatbázisnak megfelelő beállításokban. Vagyis alapértelmezés szerint rosszul vagy egyáltalán nem fog működni.
Milyen hagyományos hangolási célok vannak a Linuxban? Úgy gondolom, hogy mivel mindannyian Linux adminisztrációval foglalkoznak, nem kell különösebben elmagyarázni, mik a célok.
Hangolni tudod:
- CPU.
- Memória.
- Tárolás.
- Egyéb. Erről a végén beszélünk egy uzsonnára. Még például az olyan paraméterek is, mint az energiatakarékossági irányelvek, nagyon kiszámíthatatlanul és nem a legkellemesebb módon befolyásolhatják a teljesítményt.
Mik a PostgreSQL és általában az adatbázis sajátosságai? A probléma az, hogy nem lehet megcsípni egyetlen anyát sem, és látni, hogy teljesítményünk jelentősen javult.
Igen, vannak ilyen kütyük, de az adatbázis összetett dolog. Együttműködik a kiszolgáló összes erőforrásával, és szívesebben használja a lehető legteljesebb mértékben. Ha megnézi az Oracle jelenlegi ajánlásait a gazdagép operációs rendszer használatára vonatkozóan, ez olyan lesz, mint a vicc a mongol űrhajósról – etesd meg a kutyát, és ne érj hozzá semmihez. Adjunk meg minden erőforrást az adatbázisnak, maga az adatbázis rendez mindent.
Elvileg bizonyos mértékig pontosan ugyanaz a helyzet a PostgreSQL-lel. A különbség az, hogy az adatbázis még nem képes az összes erőforrást magára venni, azaz valahol Linux szinten neked kell mindent megoldani.
A fő ötlet nem az, hogy egyetlen célt válasszunk ki és kezdjük el hangolni, például a memóriát, a CPU-t vagy valami hasonlót, hanem a munkaterhelés elemzése és az átviteli sebesség javítása, amennyire csak lehetséges, hogy a jó programozók által létrehozott terhelés. számunkra, beleértve a felhasználóinkat is.
Itt van egy kép, hogy elmagyarázza, mi ez. Van egy Linux operációs rendszer puffer, van megosztott memória és vannak PostgreSQL megosztott pufferek. A PostgreSQL az Oracle-lel ellentétben közvetlenül csak a kernelpufferen keresztül működik, vagyis ahhoz, hogy egy lap a lemezről a megosztott memóriájába kerüljön, át kell mennie a kernelpufferen és vissza, pontosan ugyanabban a helyzetben.
A lemezek ebben a rendszerben élnek. Ezt lemeznek rajzoltam. Sőt, lehet, hogy van RAID vezérlő stb.
És ez az input-output így vagy úgy ezen az ügyön keresztül történik.
A PostgreSQL egy klasszikus adatbázis. Van benne egy oldal. És minden bevitel és kimenet oldalak használatával történik. Lapokkal blokkokat emelünk a memóriába. És ha nem történt semmi, csak elolvassuk őket, majd fokozatosan eltűnnek ebből a gyorsítótárból, a megosztott pufferekből, és visszakerülnek a lemezre.
Ha valahol kicserélünk valamit, akkor az egész oldal piszkosnak lesz jelölve. Itt kékkel jelöltem őket. Ez pedig azt jelenti, hogy ezt az oldalt szinkronizálni kell a blokktárral. Azaz amikor bemocskoltuk, beírtuk a WAL-ba. És egy csodálatos pillanatban jött egy jelenség, az úgynevezett checkpoint. És ebbe a naplóba azt az információt rögzítették, hogy megérkezett. És ez azt jelenti, hogy az összes piszkos oldal, amely abban a pillanatban itt volt ezekben a megosztott pufferekben, szinkronizálva volt a tárolólemezzel az fsync használatával a kernelpufferen keresztül.
Miért történik ez? Ha elvesztettük a feszültséget, akkor nem kaptunk olyan helyzetet, hogy minden adat elveszett. A kitartó memória, amiről mindenki mesélt, eddig az adatbáziselméletben van - ez egy fényes jövő, amelyre természetesen törekszünk és tetszik, de egyelőre mínusz 20 év múlva élnek. És persze mindezt figyelemmel kell kísérni.
Az átviteli sebesség maximalizálásának feladata pedig az összes ilyen szakasz finomhangolása, hogy minden gyorsan előre-hátra mozogjon. A megosztott memória alapvetően egy oldal gyorsítótár. A PostgreSQL-ben küldtünk egy kiválasztási lekérdezést vagy ilyesmit, ez lekérte ezeket az adatokat a lemezről. Megosztott pufferekbe kerültek. Ennek megfelelően ahhoz, hogy ez jobban működjön, sok memóriának kell lennie.
Annak érdekében, hogy mindez jól és gyorsan működjön, minden szakaszban helyesen kell konfigurálnia az operációs rendszert. És válasszon kiegyensúlyozott hardvert, mert ha valahol kiegyensúlyozatlanság van, akkor sok memóriát csinálhat, de nem lesz szervizelve kellő sebességgel.
És menjünk végig ezeken a pontokon.
Ahhoz, hogy ezek az oldalak gyorsabban oda-vissza közlekedjenek, a következőket kell elérnie:
- Először is hatékonyabban kell dolgoznia a memóriával.
- Másodszor, ennek az átmenetnek, amikor az oldalak a memóriából a lemezre kerülnek, hatékonyabbnak kell lennie.
- Harmadszor pedig jó lemezeknek kell lenniük.
Ha van 512 GB RAM a szerverben, és az egész SATA merevlemezre kerül, gyorsítótár nélkül, akkor az egész adatbázisszerver nem csak egy tökké válik, hanem egy tökké SATA interfésszel. Közvetlenül bele fog futni. És semmi sem ment meg.
Ami a memóriával kapcsolatos első pontot illeti, három dolog van, ami nagyon megnehezítheti az életet.
Az első közülük a NUMA. A NUMA a teljesítmény javítására készült. A munkaterheléstől függően különböző dolgokat lehet optimalizálni. Az új jelenlegi formájában pedig nem túl jó olyan alkalmazásokhoz, mint például adatbázisok, amelyek intenzíven használják az oldalgyorsítótár megosztott puffereit.
Dióhéjban. Honnan tudhatod, ha valami nincs rendben a NUMA-val? Valami kellemetlen kopogás van, hirtelen valamelyik CPU túlterhelt. Ugyanakkor elemzi a lekérdezéseket a PostgreSQL-ben, és látja, hogy nincs ott semmi hasonló. Ezek a lekérdezések nem lehetnek olyan CPU-igényesek. Ezt sokáig el lehet fogni. A NUMA PostgreSQL-hez való konfigurálására vonatkozóan már a kezdetektől egyszerűbb használni a helyes ajánlást.
Mi történik valójában? A NUMA a Non-Uniform Memory Access rövidítése. Mi az értelme? CPU-ja van, mellette ott van a helyi memóriája. És ezek a memóriaösszeköttetések más CPU-k memóriáját is felhúzhatják.
Ha futsz numactl --hardware, akkor akkora lapot kapsz. Többek között lesz távolsági mezőny is. Lesznek számok - 10-20, valami ilyesmi. Ezek a számok nem mások, mint a távoli memória felvételéhez és helyi használatához szükséges ugrások száma. Elvileg jó ötlet. Ez jelentősen felgyorsítja a teljesítményt számos munkaterhelés mellett.
Most képzelje el, hogy az egyik CPU először megpróbálja használni a helyi memóriáját, majd megpróbálja felvenni egy másik memóriát az összekapcsoláson keresztül valamire. És ez a CPU megkapja a teljes PostgreSQL-oldal gyorsítótárát – ez az, néhány gigabájt. Mindig a legrosszabb eset jár, mert a CPU-n általában kevés memória van abban a modulban. És az összes kiszolgált memória ezeken az összeköttetéseken keresztül megy keresztül. Lassúnak és szomorúnak tűnik. És az ezt a csomópontot kiszolgáló processzor folyamatosan túlterhelt. És ennek a memóriának az elérési ideje rossz, lassú. Ez az a helyzet, amelyet nem szeretne, ha ezt adatbázishoz használja.
Ezért az adatbázis szempontjából helyesebb megoldás, ha a Linux operációs rendszer egyáltalán nem tudja, mi folyik ott. Úgy, hogy úgy fér hozzá a memóriához, ahogyan teszi.
Miert van az? Úgy tűnik, ennek fordítva kellene lennie. Ennek egyetlen egyszerű oka van: sok memóriára van szükségünk az oldal gyorsítótárához - több tíz, több száz gigabájtra.
És ha mindezt lefoglaltuk, és ott gyorsítótáraztuk az adatainkat, akkor a gyorsítótár használatából származó nyereség lényegesen nagyobb lesz, mint egy ilyen trükkös memória-hozzáférés nyeresége. És ezzel összehasonlíthatatlanul profitálunk majd ahhoz képest, hogy a NUMA használatával hatékonyabban érjük el a memóriát.
Ezért itt jelenleg kétféle megközelítés létezik, amíg el nem érkezett a fényes jövő, és maga az adatbázis sem képes kitalálni, hogy melyik CPU-kon fut, és honnan kell valamit kihúznia.
Ezért a helyes megközelítés a NUMA teljes letiltása, például újraindításkor. A legtöbb esetben a nyeremény olyan nagyságrendű, hogy fel sem merül a kérdés, melyik a jobb.
Van egy másik lehetőség is. Gyakrabban használjuk, mint az elsőt, mert amikor egy kliens hozzánk fordul támogatásért, a szerver újraindítása nagy dolog neki. Ott van egy üzlete. És problémákat tapasztalnak a NUMA miatt. Ezért megpróbáljuk az újraindításnál kevésbé invazív módon letiltani, de ügyeljen arra, hogy ellenőrizze, hogy le van-e tiltva. Mert a tapasztalatok szerint jó, ha letiltjuk a NUMA-t a szülő PostgreSQL folyamaton, de egyáltalán nem szükséges, hogy működjön. Ellenőriznünk kell, hogy valóban kikapcsolt-e.
Van egy jó bejegyzés Robert Haastól. Ez az egyik PostgreSQL committer. Az összes alacsony szintű belsőség egyik kulcsfontosságú fejlesztője. És ha követi a bejegyzésben található linkeket, számos színes történetet írnak le arról, hogy a NUMA hogyan tette nehézzé az emberek életét. Nézze, tanulmányozza át a rendszergazda ellenőrzőlistáját, hogy mit kell konfigurálni a szerveren ahhoz, hogy adatbázisunk jól működjön. Ezeket a beállításokat le kell írni és ellenőrizni, mert különben nem lesz túl jó.
Kérjük, vegye figyelembe, hogy ez minden beállításra vonatkozik, amelyről beszélni fogok. De általában az adatbázisokat master-slave módban gyűjtik össze a hibatűrés érdekében. Ne felejtsd el elvégezni ezeket a beállításokat a slave-en, mert egy nap balesetet szenvedsz, és átváltasz a slave-re, és az lesz a mester.
Vészhelyzetben, amikor minden nagyon rossz, folyamatosan csörög a telefonod és a főnököd nagy bottal rohan, nem lesz időd az ellenőrzésre gondolni. És az eredmények meglehetősen katasztrofálisak lehetnek.
A következő pont a hatalmas oldalak. A hatalmas oldalakat nehéz külön-külön tesztelni, és ennek semmi értelme, bár vannak benchmarkok, amelyek ezt megtehetik. Könnyen kereshetők a Google-on.
Mi az értelme? Van egy nem túl drága szervere, sok RAM-mal, például több mint 30 GB. Nem használsz hatalmas oldalakat. Ez azt jelenti, hogy a memóriahasználat terén mindenképpen többed lesz. És ez a rezsi messze nem a legkellemesebb.
Miert van az? Nos, miújság? Az operációs rendszer kis darabokra osztja le a memóriát. Nagyon kényelmes, így történt a történelemben. És ha részletezzük, az operációs rendszernek le kell fordítania a virtuális címeket fizikai címekre. És ez a folyamat nem a legegyszerűbb, ezért az operációs rendszer gyorsítótárazza a művelet eredményét a Translation Lookaside Bufferben (TLB).
És mivel a TLB egy gyorsítótár, a gyorsítótárban rejlő összes probléma felmerül ebben a helyzetben. Először is, ha sok RAM-ja van, és ez mind kis darabokban van lefoglalva, akkor ez a puffer nagyon nagy lesz. És ha a gyorsítótár nagy, akkor a keresés lassabb. A rezsi egészséges és maga is helyet foglal, vagyis a RAM-ot valami nem megfelelő dolog veszi fel. Ezúttal.
Kettő: minél jobban nő a gyorsítótár egy ilyen helyzetben, annál valószínűbb, hogy gyorsítótárhiányai lesznek. Ennek a gyorsítótárnak a hatékonysága pedig gyorsan csökken a méretének növekedésével. Ezért az operációs rendszerek egy egyszerű megközelítést alkalmaztak. Linuxon már régóta használják. Nem is olyan régen jelent meg a FreeBSD-ben. De mi Linuxról beszélünk. Ezek hatalmas oldalak.
És itt kell megjegyezni, hogy a hatalmas oldalakat ötletként kezdetben az Oracle-t és az IBM-et is magában foglaló közösségek tolták, vagyis az adatbázisgyártók erősen úgy gondolták, hogy ez adatbázisoknál is hasznos lesz.
És hogyan lehet ezt megbarátkozni a PostgreSQL-lel? Először is, a hatalmas oldalakat engedélyezni kell a Linux kernelben.
Másodszor, ezeket kifejezetten meg kell adni a sysctl paraméterrel - hányan vannak. Az itteni számok valami régi szerverről származnak. Kiszámolhatja, hogy hány megosztott puffere van, hogy ott hatalmas oldalak férhessenek el.
És ha a teljes szervere a PostgreSQL-nek van dedikálva, akkor jó kiindulási pont az, hogy vagy a RAM 25%-át osztja meg megosztott puffereknek, vagy 75%-át, ha biztos benne, hogy az adatbázisa biztosan belefér ebbe a 75%-ba. Egy kiindulópont. És vegye figyelembe, ha 256 GB RAM-mal rendelkezik, akkor ennek megfelelően 64 GB nagy puffere lesz. Hozzávetőlegesen számoljon némi margóval – mire kell ezt a számot beállítani.
A 9.2-es verzió előtt (ha nem tévedek, a 8.2-es verzió óta) a PostgreSQL-t hatalmas oldalakkal lehetett összekapcsolni egy harmadik féltől származó könyvtár segítségével. És ezt mindig meg kell tenni. Először is szükség van a kernelre, hogy megfelelően tudjon kiosztani hatalmas oldalakat. Másodszor pedig, hogy a velük működő alkalmazás tudja használni őket. Nem csak így fogják használni. Mivel a PostgreSQL a rendszer 5 stílusában foglalta le a memóriát, ezt a libhugetlbfs segítségével lehetett megtenni – ez a könyvtár teljes neve.
A 9.3-ban a PostgreSQL teljesítménye javult a memóriával való munka során, és a rendszer 5 memóriafoglalási módszerét elhagyták. Mindenki nagyon örült, mert különben két PostgreSQL-példányt próbálsz futtatni egy gépen, és azt mondja, hogy nincs elég megosztott memóriám. És azt mondja, hogy a sysctl-t javítani kell. És van egy olyan sysctl, hogy még újra kell indítani stb. Általában mindenki elégedett volt. De az mmap memóriakiosztás megszakította a hatalmas oldalak használatát. Ügyfeleink többsége nagy megosztott puffereket használ. És erősen ajánlottuk, hogy ne váltsunk 9.3-ra, mert ott elkezdték jó százalékban számolni a rezsiköltséget.
De a közösség felfigyelt erre a problémára, és a 9.4-ben nagyon jól átdolgozták ezt az eseményt. A 9.4-ben pedig megjelent egy paraméter a postgresql.conf-ban, amiben engedélyezheti a try-t, be vagy off.
A próbálkozás a legbiztonságosabb megoldás. Amikor a PostgreSQL elindul, amikor lefoglalja a megosztott memóriát, megpróbálja lefoglalni ezt a memóriát a hatalmas oldalakról. És ha nem működik, akkor visszaáll a normál kiválasztáshoz. És ha FreeBSD-vel vagy Solaris-szal rendelkezik, akkor megpróbálhatja, mindig biztonságos.
Ha be van kapcsolva, akkor egyszerűen nem indul el, ha nem tudott választani a hatalmas oldalak közül. Itt már arról van szó, hogy ki és mi a szebb. De ha próbálkoztál, akkor nézd meg, hogy tényleg ki van-e emelve, amire szükséged van, mert nagy a hibalehetőség. Jelenleg ez a funkció csak Linuxon működik.
Még egy apró megjegyzés, mielőtt továbbmennénk. Az átlátszó hatalmas oldalak még nem a PostgreSQL-ről szólnak. Nem tudja normálisan használni őket. És a Transparent hatalmas oldalakkal egy ilyen munkaterheléshez, amikor nagy darab megosztott memóriára van szükség, az előnyök csak a nagyon nagy mennyiségekkel járnak. Ha terabájt memóriája van, akkor ez jöhet szóba. Ha már hétköznapibb alkalmazásokról beszélünk, amikor 32, 64, 128, 256 GB memória van a gépen, akkor a szokásos hatalmas lapok rendben vannak, és egyszerűen letiltjuk az Átlátszót.
És az utolsó dolog az emlékezetben nem kapcsolódik közvetlenül a gyümölcshöz, nagyon tönkreteheti az életét. Az összes átviteli sebességet nagyban befolyásolja az a tény, hogy a szerver folyamatosan cserélődik.
És ez több szempontból is nagyon kellemetlen lesz. A fő probléma pedig az, hogy a modern kernelek kicsit másképp viselkednek, mint a régebbi Linux kernelek. És ezt a dolgot elég kellemetlen meglépni, mert ha valamiféle cserés munkáról beszélünk, az az OOM-gyilkos korai érkezésével végződik. Az OOM-gyilkos pedig, amely nem érkezett meg időben, és kidobta a PostgreSQL-t, kellemetlen. Erről mindenki tudni fog, vagyis az utolsó felhasználóig.
Mi történik? Rengeteg RAM van benne, minden jól működik. De valamiért a szerver lefagy a swapban és emiatt lelassul. Úgy tűnik, hogy sok a memória, de ez megtörténik.
Korábban azt tanácsoltuk, hogy a vm.swappiness értéket nullára állítsuk, azaz a csere letiltását. Korábban úgy tűnt, hogy a 32 GB RAM és a megfelelő megosztott pufferek hatalmas mennyiségnek számítanak. A csere fő célja, hogy legyen hova kidobni a kérget, ha leesünk. És már nem is különösebben teljesült. És akkor mit fogsz csinálni ezzel a kéreggel? Ez egy olyan feladat, ahol nem nagyon világos, hogy miért van szükség cserére, különösen ekkora méretű.
De a kernel modernebb, azaz harmadik verziójában a viselkedés megváltozott. Ha pedig a swap-ot nullára állítod, azaz kikapcsolod, akkor előbb-utóbb, még ha marad is egy kis RAM, odajön hozzád egy OOM-gyilkos, hogy megölje a legintenzívebb fogyasztókat. Mert úgy fogja tekinteni, hogy ekkora terhelés mellett még van egy kis hátra, és kiugrunk, vagyis nem a rendszerfolyamatot szögezzük le, hanem valami kevésbé fontos dolgot. Ez a kevésbé fontos a megosztott memória intenzív fogyasztója, nevezetesen a postamester. És utána jó lesz, ha nem kell helyreállítani az alapot.
Ezért most az alapértelmezett, amennyire emlékszem, a legtöbb disztribúció valahol 6 körül van, vagyis mikortól kell elkezdeni a swap-ot attól függően, hogy mennyi memória maradt. Most javasoljuk a vm.swappiness = 1 beállítást, mert ez gyakorlatilag kikapcsolja, de nem ad olyan hatásokat, mint egy váratlanul érkező OOM-killernél, és megölte az egészet.
Mi a következő lépés? Amikor az adatbázisok teljesítményéről beszélünk, és fokozatosan a lemezek felé haladunk, mindenki kapkodni kezdi a fejét. Mert azt az igazságot, hogy a lemez lassú és a memória gyors, mindenki gyermekkora óta ismeri. És mindenki tudja, hogy az adatbázisnak lemezteljesítmény-problémák lesznek.
Az ellenőrzőpont-csúcsokkal kapcsolatos fő PostgreSQL teljesítményprobléma nem fordul elő, mert a lemez lassú. Ez valószínűleg annak a ténynek köszönhető, hogy a memória és a lemez sávszélessége nincs egyensúlyban. Előfordulhat azonban, hogy különböző helyeken nincsenek kiegyensúlyozottak. A PostgreSQL nincs konfigurálva, az operációs rendszer nincs konfigurálva, a hardver nincs konfigurálva és a hardver hibás. És ez a probléma nem csak akkor fordul elő, ha minden úgy történik, ahogy kell, azaz vagy nincs terhelés, vagy jól meg vannak választva a beállítások és a hardver.
Mi ez és hogyan néz ki? Általában a PostgreSQL-lel dolgozók többször is belevágtak ebbe az ügybe. elmagyarázom. Ahogy mondtam, a PostgreSQL időnként ellenőrző pontokat hoz létre, hogy a megosztott memóriában lévő piszkos oldalakat lemezre írja. Ha nagy mennyiségű megosztott memóriánk van, akkor az ellenőrzőpont intenzíven hat a lemezre, mert az fsync segítségével kiírja ezeket az oldalakat. Megérkezik a kernel pufferébe, és az fsync használatával íródik a lemezekre. És ha ennek az üzletnek a volumene nagy, akkor egy kellemetlen hatást figyelhetünk meg, nevezetesen a lemezek nagyon nagy kihasználását.
Itt van két képem. Most elmagyarázom, mi az. Ez két időkorrelált grafikon. Az első grafikon a lemezhasználatot mutatja. Itt eléri a 90%-ot ebben az időpontban. Ha egy adatbázis meghibásodik a fizikai lemezekkel, és a RAID vezérlő kihasználtsága 90%, akkor ez rossz hír. Ez azt jelenti, hogy még egy kicsit, és eléri a 100-at, és az I/O leáll.
Ha van lemeztömbje, akkor ez egy kicsit más történet. Attól függ, hogyan van beállítva, milyen tömbről van szó stb.
Ezzel párhuzamosan itt van beállítva egy grafikon a belső postgres nézetből, amely megmondja, hogyan történik az ellenőrzési pont. A zöld szín pedig azt mutatja, hogy abban a pillanatban hány puffer, ez a piszkos oldal érkezett erre a szinkronizálási ellenőrzőpontra. És ez a legfontosabb dolog, amit itt tudnia kell. Azt látjuk, hogy itt sok az oldalunk és valamikor felütöttük a táblát, vagyis írtunk-írtunk, itt egyértelműen nagyon leterhelt a lemezrendszer. És az ellenőrzőpontunk nagyon erős hatással van a lemezre. Ideális esetben inkább így kellene kinéznie a helyzetnek, vagyis itt kevesebb felvételünk volt. A beállításokkal pedig ki tudjuk javítani, hogy továbbra is így legyen. Vagyis kicsi az újrahasznosítás, de valahol itt írunk valamit.
Mit kell tenni a probléma leküzdése érdekében? Ha leállította az IO-t az adatbázisban, ez azt jelenti, hogy minden felhasználó, aki eljött, hogy teljesítse kérését, várni fog.
Ha a Linux szemszögéből nézed, ha jó hardvert vettél, helyesen konfiguráltad, a PostgreSQL-t normálisan konfiguráltad, hogy ritkábban tegye ezeket az ellenőrző pontokat, idővel szétterítse egymás között, akkor lépj be az alapértelmezett Debian paraméterekbe. A legtöbb Linux disztribúció esetében ez a kép: vm.dirty_ratio=20, vm.dirty_background_ratio=10.
Mit jelent? Egy flushing démon jelent meg a 2.6-os kernelből. Pdglush, attól függően, hogy ki melyiket használja, amely részt vesz a piszkos oldalak háttérben történő eldobásában a kernelpufferből, és eldobja, ha el kell dobni a piszkos oldalakat, bármitől függetlenül, amikor a háttérben való elvetés nem segít.
Mikor jön a háttér? Ha a szerveren elérhető teljes RAM 10%-át a kernelpufferben lévő piszkos oldalak foglalják el, a háttérben egy speciális leíró funkció kerül meghívásra. Miért van ez a háttérben? Paraméterként figyelembe veszi, hogy hány oldalt kell leírni. És mondjuk leír N oldalt. És egy időre ez a dolog elalszik. Aztán újra jön, és másol még néhány oldalt.
Ez egy rendkívül egyszerű történet. Itt olyan a probléma, mint egy uszodánál, amikor az egyik csőbe ömlik, a másikba folyik. Megérkezett az ellenőrzőpontunk, és ha néhány koszos oldalt küldött eldobásra, akkor fokozatosan az egész szépen megoldódik a pgflush kernel pufferből.
Ha tovább gyűlnek ezek a koszos oldalak, akkor 20%-ig felhalmozódnak, utána az OS prioritása, hogy az egészet kiírják a lemezre, mert elromlik az áram és minden rossz lesz nekünk. Elveszítjük például ezeket az adatokat.
Mi a trükk? A trükk az, hogy ezek a paraméterek a modern világban a gép teljes RAM-jának 20 és 10% -át teszik ki, teljesen szörnyűek az Ön által használt lemezrendszerek teljesítményét tekintve.
Képzeld el, hogy 128 GB RAM-od van. 12,8 GB érkezik a lemezrendszerbe. És nem számít, milyen gyorsítótár van ott, nem számít, milyen tömb van ott, ezek nem tartanak sokáig.
Ezért azt javasoljuk, hogy azonnal módosítsa ezeket a számokat a RAID-vezérlő képességei alapján. Itt azonnal ajánlást tettem egy 512 MB gyorsítótárral rendelkező vezérlőre.
Mindent nagyon egyszerűnek tartanak. A vm.dirty_backgroundot bájtokba helyezheti. És ezek a beállítások érvénytelenítik az előző kettőt. Alapértelmezés szerint bármelyik arány van, vagy a bájtosak aktiválva vannak, akkor a bájtosak működni fognak. De mivel DBA-tanácsadó vagyok és különböző kliensekkel dolgozom, igyekszem szívószálakat rajzolni, és ezért ha bájtokban, akkor bájtokban. Senki nem adott garanciát arra, hogy egy jó admin nem tesz több memóriát a szerverbe, nem indítja újra, és a szám ugyanaz marad. Csak számolja ki ezeket a számokat, hogy minden beleférjen garanciával.
Mi történik, ha nem illesz be? Azt írtam, hogy minden öblítés gyakorlatilag leáll, de valójában ez egy beszéd. Az operációs rendszerrel van egy nagy probléma - sok a koszos oldal, ezért gyakorlatilag leáll az IO, amit a kliensei generálnak, vagyis az alkalmazás sql lekérdezést küldött az adatbázisba, vár. Bármilyen bemenet/kimenet a legalacsonyabb prioritású, mivel az adatbázist egy ellenőrző pont foglalja el. És hogy mikor fejezi be, az teljesen homályos. És ha elérted a nem háttér öblítést, az azt jelenti, hogy az összes IO-d le van foglalva. És amíg véget nem ér, semmit sem fog tenni.
Itt van még két fontos pont, amelyek túlmutatnak e jelentés keretein. Ezeknek a beállításoknak meg kell egyeznie a postgresql.conf, azaz az ellenőrzőpontok beállításaival. És a lemezrendszerének megfelelően konfiguráltnak kell lennie. Ha van gyorsítótár a RAID-en, akkor annak akkumulátornak kell lennie. Az emberek RAID-et vásárolnak jó gyorsítótárral, akkumulátor nélkül. Ha RAID-ben vannak SSD-k, akkor ezeknek szervereknek kell lenniük, ott kondenzátoroknak kell lenniük. Itt van egy részletes ellenőrző lista. Ez a hivatkozás tartalmazza a teljesítménylemezek PostgreSQL-ben történő konfigurálásáról szóló beszámolómat. Ott vannak ezek az ellenőrző listák.
Mi az, ami még nagyon megnehezítheti az életet? Ez két paraméter. Viszonylag újak. Alapértelmezés szerint különböző alkalmazásokban szerepelhetnek. És ugyanúgy megnehezíthetik az életet, ha nem megfelelően vannak bekapcsolva.
Két viszonylag új dolog van. A harmadik magban már megjelentek. Ez a sched_migration_cost nanoszekundumban és a sched_autogroup_enabled, amely alapértelmezés szerint az egyik.
És hogyan teszik tönkre az életedet? Mi az a sched_migration_cost? Linuxon az ütemező migrálhat egy folyamatot egyik CPU-ról a másikra. A lekérdezéseket végrehajtó PostgreSQL esetében pedig teljesen tisztázatlan a másik CPU-ra való átállás. Operációs rendszer szempontjából, amikor az ablakokat az openoffice és a terminál között váltja, ez jó lehet, de adatbázisnak ez nagyon rossz. Ezért az ésszerű irányelv az, hogy a migration_cost értéket valamilyen nagy értékre, legalább több ezer nanoszekundumra állítjuk.
Mit jelent ez az ütemező számára? Úgy tekintjük, hogy ezalatt a folyamat még forró. Vagyis ha van egy régóta futó tranzakciója, amely már régóta csinál valamit, akkor ezt az ütemező megérti. Feltételezi, hogy amíg ez az időkorlát le nem telik, nincs szükség a folyamat áttelepítésére. Ha egyidejűleg a folyamat csinál valamit, akkor nem migrálják sehova, csendben fog működni a hozzá kiosztott CPU-n. Az eredmény pedig kiváló.
A második pont az autogroup. Van egy jó ötlet olyan konkrét munkaterhelésekhez, amelyek nem kapcsolódnak a modern adatbázisokhoz – ez a folyamatok csoportosítása a virtuális terminál szerint, amelyről elindítják őket. Ez bizonyos feladatokhoz kényelmes. A gyakorlatban a PostgreSQL egy többfolyamatos rendszer egy előforkkal, amely egyetlen terminálról fut. Van egy zárolási írója, ellenőrzőpontja, és az összes ügyfélkérelme egy ütemezőbe lesz csoportosítva, CPU-nként. És kórusban várják ott, hogy szabaduljon, hogy zavarják egymást, és tovább lefoglalják. Ez egy ilyen terhelés esetén teljesen felesleges történet, ezért ki kell kapcsolni.
Alexey Lesovsky kollégám egy egyszerű pgbench-vel végzett teszteket, ahol egy nagyságrenddel megnövelte a migration_cost-ot és kikapcsolta az autogroup-ot. A rossz hardverek közötti különbség közel 10% volt. A postgres levelezőlistán egy vita folyik, ahol az emberek a lekérdezési sebesség hasonló változásairól adnak eredményt 50%-ban befolyásolta. Elég sok ilyen történet létezik.
És végül az energiatakarékossági politikáról. A jó dolog az, hogy a Linux már laptopon is használható. És állítólag jól elhasználja az akkumulátort. De hirtelen kiderül, hogy ez a szerveren is megtörténhet.
Sőt, ha szervereket bérel valamelyik tárhelytől, akkor a „jó” tárhelyszolgáltatókat nem érdekli, hogy jobb teljesítményt nyújtson. Feladatuk vasuk minél hatékonyabb felhasználása. Ezért alapértelmezés szerint engedélyezhetik a laptop energiatakarékos üzemmódját az operációs rendszeren.
Ha ezt a cuccot nagy terhelés alatt álló adatbázisú szerveren használod, akkor az acpi_cpufreq + permormance a választásod. Még igény esetén is lesznek problémák.
Az Intel_pstate egy kicsit más illesztőprogram. És most ezt részesítik előnyben, mivel ez később és jobban működik.
És ennek megfelelően a kormányzó csak teljesítmény. Az Ondemand, a powersave és minden más nem rólad szól.
A PostgreSQL magyarázó elemzésének eredményei több nagyságrenddel is eltérhetnek, ha engedélyezzük az energiatakarékosságot, mivel gyakorlatilag az adatbázisunk alatt lévő CPU teljesen kiszámíthatatlanul fog futni.
Ezek az elemek alapértelmezés szerint szerepelhetnek. Nézze meg alaposan, hogy alapértelmezés szerint bekapcsolták-e. Ez valóban nagy probléma lehet.
A végén pedig köszönetet szeretnék mondani a PosgreSQL-Consulting DBA csapatunk srácainak, nevezetesen Max Boguknak és Alexey Lesovsky-nak, akik nap mint nap haladnak ebben az ügyben. És igyekszünk a tőlünk telhető legjobbat megtenni ügyfeleinkért, hogy mindez működjön a számukra. Ez olyan, mint a repülésbiztonsági utasításoknál. Itt minden vérrel van megírva. Ezen diófélék mindegyike valamilyen probléma folyamatában található. Örömmel osztom meg őket veletek.
Kérdések:
Köszönöm! Ha például egy cég pénzt szeretne megtakarítani, és egy szerveren szeretné elhelyezni az adatbázist és az alkalmazáslogikát, vagy ha a cég a mikroszolgáltatási architektúrák divatos trendjét követi, amelyben a PostgreSQL konténerben fut. Mi a trükk? A Sysctl globálisan érinti a teljes kernelt. Nem hallottam olyanról, hogy a sysctl-eket valahogy virtualizálták volna, hogy külön működjenek egy tárolón. Csak egy cgroup van, és ott a vezérlésnek csak egy része van. Hogy lehet ezzel együtt élni? Vagy ha teljesítményt szeretne, futtassa a PostgreSQL-t egy külön hardverkiszolgálón, és hangolja azt?
Körülbelül háromféleképpen válaszoltunk kérdésére. Ha nem egy tuningolható hardveres szerverről beszélünk stb, akkor nyugi, ezek nélkül a beállítások nélkül minden rendben lesz. Ha akkora terhelésed van, hogy ezeket a beállításokat el kell végezned, akkor előbb érsz az iron szerverre, mint ezekre a beállításokra.
Mi a probléma? Ha ez egy virtuális gép, akkor valószínűleg sok problémája lesz, például azzal a ténnyel, hogy a legtöbb virtuális gépen a lemez késleltetése meglehetősen következetlen. Még ha a lemez átviteli sebessége jó is, akkor is egy meghiúsult I/O tranzakció, amely nem befolyásolja nagymértékben az átlagos átviteli sebességet, ami az ellenőrzési pont idején vagy a WAL-ba íráskor történt, akkor ezt az adatbázis nagyon meg fogja szenvedni. És ezt észre fogja venni, mielőtt ezekkel a problémákkal találkozna.
Ha ugyanazon a kiszolgálón van NGINX, akkor ugyanaz a probléma lesz. Harcolni fog a közös emlékezetért. És nem fogsz eljutni az itt leírt problémákhoz.
Másrészt azonban ezen paraméterek egy része továbbra is releváns lesz az Ön számára. Például a sysctl-lel állítsd be a dirty_ratio-t, hogy ne legyen olyan őrült – ez mindenesetre segít. Így vagy úgy, interakcióba lép a lemezzel. És rossz minta szerint lesz. Ez általában az általam bemutatott paraméterek alapértelmezett értéke. És mindenesetre jobb megváltoztatni őket.
De problémák lehetnek a NUMA-val. A VmWare például jól működik a NUMA-val pontosan ellenkező beállításokkal. És itt kell választani - vas szerver vagy nem vas.
Lenne egy kérdésem az Amazon AWS-hez kapcsolódóan. Előre beállított képekkel rendelkeznek. Az egyik az Amazon RDS. Vannak egyéni beállítások az operációs rendszerükhöz?
Vannak beállítások, de ezek különböző beállítások. Itt konfiguráljuk az operációs rendszert abból a szempontból, hogy az adatbázis hogyan fogja használni ezt a dolgot. És vannak olyan paraméterek, amelyek meghatározzák, hogy most merre menjünk, ilyen például az alakítás. Vagyis annyi erőforrásra van szükségünk, hogy most felemésztjük őket. Ezt követően az Amazon RDS megszorítja ezeket az erőforrásokat, és ott csökken a teljesítmény. Vannak egyéni történetek arról, hogy az emberek hogyan kezdenek foglalkozni ezzel az üggyel. Néha egészen sikeresen is. De ennek semmi köze az operációs rendszer beállításaihoz. Mintha feltörné a felhőt. Ez egy másik történet.
Miért nincs hatása az Átlátszó hatalmas oldalaknak a Hatalmas TLB-hez képest?
Ne adj. Ez sokféleképpen magyarázható. De valójában egyszerűen nem adják. Mi a PostgreSQL története? Indításkor nagy darab megosztott memóriát foglal le. Teljesen lényegtelen, hogy átlátszóak-e vagy sem. Az a tény, hogy már az elején kiemelkednek, mindent megmagyaráz. És ha sok a memória, és újra kell építeni a shared_memory szegmenst, akkor az átlátszó hatalmas oldalak relevánsak lesznek. A PostgreSQL-ben egyszerűen egy hatalmas darabban van lefoglalva az elején, és ennyi, aztán ott nem történik semmi különös. Természetesen használhatja, de van esély arra, hogy a shared_memory megsérüljön, amikor újra lefoglal valamit. A PostgreSQL nem tud erről.
Forrás: will.com