Ipari megközelítés a PostgreSQL hangolásához: kísérletek adatbázisokkal.” Nyikolaj Szamohvalov

Azt javaslom, olvassa el Nyikolaj Szamohvalov „Ipari megközelítés a PostgreSQL hangolásához: kísérletek adatbázisokon” című jelentését.

Shared_buffers = 25% – sok vagy kevés? Vagy csak helyes? Honnan tudja, hogy ez a – meglehetősen elavult – ajánlás megfelelő-e az Ön konkrét esetére?

Ideje hozzáfogni a postgresql.conf paraméterek kiválasztásának kérdéséhez „mint egy felnőtt”. Nem vak "auto tunerek" vagy elavult cikkekből és blogokból származó tanácsok segítségével, hanem a következők alapján:

1. szigorúan ellenőrzött adatbázisokon végzett kísérletek, amelyeket automatikusan, nagy mennyiségben és olyan körülmények között hajtanak végre, amelyek a lehető legközelebb állnak a „harci” kísérletekhez,
2. a DBMS és az operációs rendszer jellemzőinek mély ismerete.

Nancy CLI (https://gitlab.com/postgres.ai/nancy), megvizsgálunk egy konkrét példát - a hírhedt megosztott_puffereket - különböző helyzetekben, különböző projektekben, és megpróbáljuk kitalálni, hogyan válasszuk ki az optimális beállítást infrastruktúránkhoz, adatbázisunkhoz és terhelésünkhöz.

Szó lesz az adatbázisokkal végzett kísérletekről. Ez egy kicsit több mint hat hónapig tartó történet.

Egy kevés rólam. A Postgresnél több mint 14 éves tapasztalat. Számos közösségi hálózatépítő cég alapított. A Postgres-t mindenhol használták és használják.

Szintén a RuPostgres csoport a Meetupon, a 2. hely a világon. Lassan megközelítjük a 2 főt. RuPostgres.org.

Különböző konferenciák PC-jén pedig, beleértve a Highloadot is, én vagyok a felelős az adatbázisokért, különösen a Postgresért a kezdetektől fogva.

Az elmúlt néhány évben pedig innen indítottam újra a Postgres tanácsadói gyakorlatomat 11 időzónával.

És amikor ezt néhány éve megtettem, volt egy kis szünetem a Postgres-szel végzett aktív fizikai munkában, valószínűleg 2010 óta. Meglepődtem, milyen keveset változott a DBA munkarutinja, és mennyi kézi munkát kell még alkalmazni. És egyből arra gondoltam, hogy itt valami nincs rendben, többet kell automatizálnom mindent.

És mivel az egész távoli volt, a legtöbb ügyfél a felhők között volt. És nyilván sok mindent automatizáltak már. Erről később. Vagyis mindez azt az ötletet eredményezte, hogy kellene egy sor eszköz, azaz valamiféle platform, amely szinte minden DBA-műveletet automatizál, hogy nagyszámú adatbázis kezelhető legyen.

Ez a jelentés nem tartalmazza:

• „Ezüst golyók” és olyan kijelentések, mint - állíts be 8 GB-ot vagy 25%-os shared_buffert, és minden rendben lesz. Nem lesz sok szó a shared_bufferekről.
• Hardcore "belsó".

És mi lesz?

• Lesznek optimalizálási elvek, amelyeket alkalmazunk és fejlesztünk. Lesznek majd mindenféle ötletek, amelyek az út során felmerülnek, és különféle eszközök, amelyeket nagyrészt nyílt forráskóddal hozunk létre, azaz mi tesszük az alapot az Open Source-ban. Sőt, jegyeink is vannak, gyakorlatilag minden kommunikáció nyílt forráskódú. Megnézheti, mit csinálunk most, mi lesz a következő kiadásban stb.
• Ezen elvek, eszközök használatában is lesz némi tapasztalat számos vállalatnál: a kis startupoktól a nagyvállalatokig.

Hogyan alakul ez az egész?

Először is, a DBA fő feladata a példányok létrehozásán, a biztonsági mentések telepítésén stb. mellett a szűk keresztmetszetek felkutatása és a teljesítmény optimalizálása.

Most így van beállítva. Nézzük a megfigyelést, látunk valamit, de hiányzik néhány részlet. Alaposabban kezdünk ásni, általában a kezünkkel, és megértjük, mit tegyünk vele így vagy úgy.

És két megközelítés létezik. A Pg_stat_statements az alapértelmezett megoldás a lassú lekérdezések azonosítására. És a Postgres naplók elemzése a pgBadger segítségével.

Mindegyik megközelítésnek komoly hátrányai vannak. Az első megközelítésben minden paramétert kidobtunk. És ha látjuk a SELECT * FROM csoportokat, ahol az oszlop egyenlő a "?" vagy „$” a Postgres 10 óta. Nem tudjuk, hogy ez index-ellenőrzés vagy szekvenciális vizsgálat. Nagyon függ a paramétertől. Ha behelyettesít egy ritkán előforduló értéket, akkor az indexvizsgálat lesz. Ha behelyettesítünk egy olyan értéket, amely a táblázat 90%-át foglalja el, akkor a szekvenciális keresés nyilvánvaló lesz, mert a Postgres ismeri a statisztikákat. És ez a pg_stat_statements nagy hátránya, bár folyamatban van néhány munka.

A naplóelemzés legnagyobb hátránya, hogy általában nem engedheti meg magának, hogy „log_min_duration_statement = 0”. És erről is beszélünk. Ennek megfelelően nem látja a teljes képet. És néhány lekérdezés, amely nagyon gyors, hatalmas mennyiségű erőforrást emészt fel, de nem fogja látni, mert a küszöb alatt van.

Hogyan oldják meg a DBA-k az általuk talált problémákat?

Például találtunk valamilyen problémát. Mit szoktak tenni? Ha Ön fejlesztő, akkor olyan példányon fog valamit csinálni, amely nem azonos méretű. Ha Ön DBA, akkor van scening. És csak egy lehet. És hat hónap lemaradt. És azt hiszed, hogy gyártásba fogsz menni. És még a tapasztalt DBA-k is belépnek a gyártásba egy replikán. És előfordul, hogy létrehoznak egy ideiglenes indexet, megbizonyosodnak róla, hogy segít, ledobják és odaadják a fejlesztőknek, hogy berakják a migrációs fájlokba. Ez az a fajta hülyeség, ami most történik. És ez probléma.

• Hangolás konfigurációk.
• Optimalizálja az indexkészletet.
• Változtassa meg magát az SQL-lekérdezést (ez a legnehezebb módja).
• Kapacitás hozzáadása (a legtöbb esetben a legegyszerűbb módja).

Sok minden történik ezekkel a dolgokkal. A Postgresben sok fogantyú található. Sok mindent tudni kell. Postgresben számos index található, köszönet a konferencia szervezőinek is. És mindezt tudni kell, és ez az, ami miatt a nem DBA-k úgy érzik, mintha a DBA-k fekete mágiát gyakorolnának. Vagyis 10 évig kell tanulnod, hogy mindezt normálisan elkezdd megérteni.

És én harcos vagyok e fekete mágia ellen. Mindent meg akarok tenni azért, hogy legyen technológia, és ebben az egészben ne legyen intuíció.

Példák az életből

Ezt legalább két projektben megfigyeltem, köztük a sajátomban is. Egy másik blogbejegyzés azt mondja, hogy a default_statistict_target 1-es értéke jó. Rendben, próbáljuk ki a gyártásban.

És itt tartunk, két évvel később, az adatbázisokon végzett kísérletek segítségével, amelyekről ma beszélünk, összehasonlíthatjuk, mi volt és mi lett.

És ehhez létre kell hoznunk egy kísérletet. Négy részből áll.

• Az első a környezet. Szükségünk van egy hardverre. És amikor eljövök egy céghez, és aláírok egy szerződést, azt mondom, hogy ugyanazt a hardvert adjanak nekem, mint a gyártásban. Minden Mesteredhez szükségem van legalább egy ilyen hardverre. Vagy ez egy példány virtuális gép az Amazonban vagy a Google-ban, vagy pontosan ugyanilyen hardverre van szükségem. Vagyis szeretném újrateremteni a környezetet. És a környezet fogalmába belefoglaljuk a Postgres fő változatát.
• A második rész kutatásunk tárgya. Ez egy adatbázis. Többféleképpen is létrehozható. Megmutatom, hogyan.
• A harmadik rész a terhelés. Ez a legnehezebb pillanat.
• A negyedik rész pedig az, hogy mit ellenőrizünk, vagyis mihez fogunk hasonlítani. Tegyük fel, hogy a konfigban módosíthatunk egy vagy több paramétert, vagy készíthetünk indexet stb.

Kísérletet indítunk. Itt van a pg_stat_statements. A bal oldalon az, ami történt. A jobb oldalon - mi történt.

A bal oldalon default_statistics_target = 100, a jobb oldalon = 1. Úgy látjuk, ez segített nekünk. Összességében minden 000%-kal javult.

De ha lefelé görgetünk, akkor a pgBadger vagy a pg_stat_statements kérések csoportjai lesznek. Két lehetőség van. Látni fogjuk, hogy bizonyos igények 88%-kal csökkentek. És itt jön a mérnöki megközelítés. Tovább áshatunk bent, mert kíváncsiak vagyunk, miért süllyedt el. Meg kell értened, mi történt a statisztikákkal. Miért vezet a statisztikákban több vödör rosszabb eredményhez?

Vagy nem tudunk ásni, hanem csináljuk az „ALTER TABLE ... ALTER COLUMN”-t, és visszaadunk 100 vödröt ennek az oszlopnak a statisztikájához. Aztán egy másik kísérlettel megbizonyosodhatunk arról, hogy ez a javítás segített. Minden. Ez egy olyan mérnöki megközelítés, amely segít abban, hogy átfogó képet lássunk, és döntéseket hozzunk adatok alapján, nem pedig intuíción.

Néhány példa más területekről. A tesztelésben évek óta léteznek CI-tesztek. És egyetlen józan eszű projekt sem élne automatizált tesztek nélkül.

Más iparágakban: a repülésben, az autóiparban, amikor aerodinamikát tesztelünk, lehetőségünk van kísérletekre is. Nem indítunk valamit rajzból egyenesen az űrbe, vagy nem teszünk azonnal pályára egy autót. Például van egy szélcsatorna.

Más iparágak megfigyeléseiből vonhatunk le következtetéseket.

Először is, különleges környezetünk van. Közel van a gyártáshoz, de nincs közel. Fő jellemzője, hogy olcsó, megismételhető és minél automatizáltabb legyen. Ezenkívül speciális eszközöknek kell lenniük a részletes elemzés elvégzéséhez.

Valószínűleg, amikor elindítunk egy repülőgépet és repülünk, kevesebb lehetőségünk van a szárnyfelület minden milliméterének tanulmányozására, mint egy szélcsatornában. Több diagnosztikai eszközünk van. Megengedhetjük magunknak, hogy több nehéz cuccot cipeljünk, amit nem engedhetünk meg magunknak, hogy a levegőben repüljünk. Ugyanez a Postgres-szel. Bizonyos esetekben engedélyezhetjük a teljes lekérdezésnaplózást a kísérletek során. És ezt nem akarjuk megtenni a termelésben. Még azt is tervezhetjük, hogy ezt az auto_explain segítségével engedélyezzük.

És ahogy mondtam, a magas szintű automatizálás azt jelenti, hogy megnyomjuk a gombot és ismételjük. Ennek így kell lennie, hogy legyen sok kísérletezés, hogy legyen stream.

Nancy CLI – az „adatbázis-laboratórium” alapja

És hát megcsináltuk ezt a dolgot. Vagyis közel egy éve, júniusban beszéltem ezekről az elképzelésekről. És már megvan az úgynevezett Nancy CLI nyílt forráskódú. Ez az adatbázis-laboratórium felépítésének alapja.

Nancy – Nyílt forráskódú, a Gitlabon. Mondhatod, kipróbálhatod. Linket adtam a diákban. Kattints rá és ott lesz segít minden tekintetben.

Természetesen sok minden van még fejlesztés alatt. Nagyon sok ötlet van. De ezt szinte minden nap használjuk. És ha van egy ötletünk - miért van az, hogy amikor 40 000 000 sort törölünk, akkor az egész az IO-ra megy le, akkor végezhetünk egy kísérletet, és részletesebben megvizsgáljuk, hogy megértsük, mi történik, majd megpróbáljuk menet közben kijavítani. Vagyis kísérletet végzünk. Például megcsípünk valamit, és megnézzük, mi történik a végén. És ezt a termelésben nem tesszük. Ez az ötlet lényege.

Hol működhet ez? Ez lokálisan működhet, azaz bárhol megteheti, akár MacBookon is futtathatja. Dokkolóra van szükségünk, menjünk. Ez minden. Futtathatja bizonyos esetekben egy hardveren vagy egy virtuális gépen, bárhol.

És lehetőség van távoli futtatásra is az Amazonban az EC2 példányban, helyben. És ez egy nagyon klassz lehetőség. Például tegnap több mint 500 kísérletet hajtottunk végre az i3 példányon, kezdve a legfiatalabbtól az i3-16-xlarge-ig. És 500 kísérlet 64 dollárba került. Mindegyik 15 percig tartott. Azaz annak a ténynek köszönhetően, hogy ott spotokat használnak, nagyon olcsó - 70% kedvezmény, az Amazon másodpercenkénti számlázása. Sokat tehetsz. Igazi kutatásokat végezhet.

A Postgres három fő verziója támogatott. Nem olyan nehéz befejezni néhány régit és az új 12. verziót is.

Egy objektumot háromféleképpen határozhatunk meg. Ez:

• Dump/sql fájl.
• A fő módszer a PGDATA könyvtár klónozása. Általában a biztonsági mentési szerverről veszik. Ha normál bináris biztonsági másolataid vannak, onnan is készíthetsz klónokat. Ha rendelkezik felhőkkel, akkor ezt egy felhőiroda, például az Amazon és a Google megteszi helyetted. Ez a legfontosabb módja a valódi termelés klónozásának. Így bontakozunk ki.
• Az utolsó módszer pedig alkalmas kutatásra, amikor meg akarjuk érteni, hogyan működik valami Postgresben. Ez a pgbench. A pgbench segítségével generálhat. Ez csak egy "db-pgbench" opció. Mondd meg neki, milyen skálán. És minden a felhőben fog generálódni, ahogy azt mondtuk.

És töltse fel:

• A betöltést egy SQL szálban tudjuk végrehajtani. Ez a legprimitívebb módszer.
• És emulálhatjuk a terhelést. És mindenekelőtt a következő módon emulálhatjuk. Össze kell gyűjtenünk az összes naplót. És fájdalmas. Megmutatom miért. És a pgreplay használatával játszunk, ami Nancy-be van beépítve.
• Vagy egy másik lehetőség. Az úgynevezett kézműves terhelés, amit bizonyos erőfeszítéssel végzünk. A harcrendszer jelenlegi terhelését elemezve kiemeljük a kérések legfelső csoportjait. A pgbench segítségével pedig ezt a terhelést emulálhatjuk a laboratóriumban.

• Vagy valamilyen SQL-t kell végrehajtanunk, azaz ellenőrizni kell valamilyen migrációt, ott indexet hozunk létre, ott végrehajtjuk az ANALAZE-t. És megnézzük, mi történt a vákuum előtt és a vákuum után. Általában bármilyen SQL.
• Vagy módosítunk egy vagy több paramétert a konfigurációban. Megmondhatjuk nekünk, hogy ellenőrizzünk például 100 értéket az Amazonban a terabájtos adatbázisunkhoz. És néhány óra múlva meglesz az eredmény. Egy terabájtos adatbázis üzembe helyezése általában több órát vesz igénybe. De van egy javítás fejlesztés alatt, lehetséges egy sorozat, azaz ugyanazt a pgdata-t folyamatosan használhatod ugyanazon a szerveren, és ellenőrizheted. A Postgres újraindul, és a gyorsítótárak visszaállnak. És vezetheti a rakományt.

• Megérkezik egy könyvtár egy csomó különböző fájllal, a pg pillanatképektől kezdveállami***. És a legérdekesebb a pg_stat_statements, a pg_stat_kcacke. Ez a két kiterjesztés elemzi a kéréseket. És a pg_stat_bgwriter nem csak a pgwriter statisztikákat tartalmazza, hanem az ellenőrzőpontokat is, és azt is, hogy a háttérprogramok hogyan szorítják ki a piszkos puffereket. És mindezt érdekes látni. Például amikor a shared_buffers-t beállítjuk, nagyon érdekes látni, hogy mennyit cseréltek ki mindenki.
• Postgres naplók is érkeznek. Két napló – egy előkészítési napló és egy terhelési lejátszási napló.
• Egy viszonylag új szolgáltatás a FlameGraphs.
• Továbbá, ha a pgreplay vagy a pgbench opciókat használta a terhelés lejátszásához, akkor a kimenetük natív lesz. És látni fogja a késleltetést és a TPS-t. Meg lehet majd érteni, hogyan látták.
• Rendszer információ.
• Alapvető CPU és IO ellenőrzések. Ez inkább az Amazon EC2-példányára vonatkozik, amikor 100 azonos példányt szeretne elindítani egy szálban, és ott 100 különböző futtatást szeretne futtatni, akkor 10 000 kísérlete lesz. És ügyelnie kell arra, hogy ne találkozzon olyan hibás példával, amelyet már elnyomott valaki. Mások aktívak ezen a hardveren, és kevés erőforrása maradt. Az ilyen eredményeket jobb elvetni. Alexey Kopytov sysbench segítségével pedig számos rövid ellenőrzést végzünk, amelyeket össze lehet hasonlítani másokkal, azaz meg fogja érteni, hogyan viselkedik a CPU és hogyan viselkedik az IO.

Milyen technikai nehézségek merülnek fel a különböző cégek példája alapján?

Tegyük fel, hogy meg akarjuk ismételni a valós terhelést naplók segítségével. Jó ötlet, ha nyílt forráskódú pgreplay-en írják. Használjuk. De ahhoz, hogy jól működjön, engedélyeznie kell a teljes lekérdezésnaplózást paraméterekkel és időzítéssel.

Vannak bizonyos bonyodalmak az időtartammal és az időbélyeggel kapcsolatban. Kiürítjük az egész konyhát. A fő kérdés az, hogy megengedheti-e magának vagy sem?

https://gist.github.com/NikolayS/08d9b7b4845371d03e195a8d8df43408

A probléma az, hogy nem biztos, hogy elérhető. Mindenekelőtt meg kell értenie, hogy melyik adatfolyam kerül a naplóba. Ha rendelkezik pg_stat_statements, akkor ezzel a lekérdezéssel (a link elérhető lesz a diákban) megtudhatja, hogy hozzávetőlegesen hány bájt lesz írva másodpercenként.

Megnézzük a kérés hosszát. Elhanyagoljuk azt a tényt, hogy nincsenek paraméterek, de ismerjük a kérés hosszát, és tudjuk, hogy másodpercenként hányszor hajtották végre. Így hozzávetőlegesen meg tudjuk becsülni, hogy másodpercenként hány bájt. Lehet, hogy kétszer annyit hibázunk, de a sorrendet így biztosan megértjük.

Láthatjuk, hogy másodpercenként 802 alkalommal hajtják végre ezt a kérést. És látjuk, hogy a bytes_per sec – 300 kB/s plusz vagy mínusz lesz írva. És általában megengedhetjük magunknak egy ilyen áramlást.

De! Az a tény, hogy különböző naplózási rendszerek léteznek. És az emberek alapértelmezett beállítása általában a "syslog".

És ha van syslogod, akkor lehet egy ilyen képed. Fogjuk a pgbench-et, engedélyezzük a lekérdezések naplózását, és meglátjuk, mi történik.

Naplózás nélkül – ez a bal oldali oszlop. 161 000 TPS-t kaptunk. A syslog segítségével - ez az Ubuntu 16.04-ben van az Amazonon, 37 000 TPS-t kapunk. És ha áttérünk két másik naplózási módszerre, akkor sokkal jobb a helyzet. Vagyis arra számítottunk, hogy csökken, de nem olyan mértékben.

A CentOS 7-en pedig, amiben a Journald is részt vesz, a naplókat bináris formátumba alakítja a könnyű keresés érdekében stb., akkor ott egy rémálom, 44-szeresünk a TPS-ben.

És ezzel élnek az emberek. És gyakran a vállalatoknál, különösen a nagyoknál, ezen nagyon nehéz változtatni. Ha meg tud szabadulni a syslogtól, akkor kérem, távolítsa el azt.

• Értékelje az IOPS-t és az írási folyamatot.
• Ellenőrizze naplózási rendszerét.
• Ha a tervezett terhelés túl nagy, fontolja meg a mintavételt.

Vannak pg_stat_statements. Mint mondtam, ott kell lennie. És minden kéréscsoportot speciális módon tudunk leírni egy fájlba. És akkor használhatunk egy nagyon kényelmes funkciót a pgbenchben - ez az a lehetőség, hogy több fájlt beszúrhatunk a „-f” opcióval.

Sok "-f"-et megért. És a végén lévő „@” segítségével megmondhatja, hogy az egyes fájloknak milyen megosztással kell rendelkezniük. Vagyis azt mondhatjuk, hogy ezt az esetek 10%-ában, ezt 20%-ban. Ez pedig közelebb visz bennünket ahhoz, amit a termelésben látunk.

Hogyan fogjuk megérteni, hogy mi van a termelésben? Milyen részesedést és hogyan? Ez egy kicsit mellékes. Van még egy termékünk postgres-ellenőrzés. Nyílt forráskódú alap is. És most aktívan fejlesztjük.

Kissé más okok miatt született. Olyan okok miatt, amelyek miatt a monitorozás nem elegendő. Vagyis jössz, nézd meg a bázist, nézd meg a létező problémákat. És általában egészségügyi ellenőrzést kell végezni. Ha Ön tapasztalt DBA, akkor végezze el az egészségellenőrzést. Megnéztük az indexek használatát, stb. Ha van OKmetered, akkor remek. Ez remek megfigyelés a Postgres számára. OKmeter.io – kérjük telepítse, ott minden nagyon jól megy. Ki van fizetve.

Ha nincs, akkor általában nincs sok. Monitoringban általában van CPU, IO, majd fenntartásokkal, és ennyi. És többre van szükségünk. Meg kell nézni, hogyan működik az autovacuum, hogyan működik a checkpoint, az io-ban el kell választani a checkpointot a bgwritertől és a háttérprogramoktól stb.

A probléma az, hogy amikor egy nagy cégnek segítesz, nem tudnak gyorsan megvalósítani valamit. Nem tudják gyorsan megvásárolni az OKmetert. Talán hat hónap múlva megveszik. Egyes csomagokat nem tudnak gyorsan kézbesíteni.

És kitaláltuk, hogy szükségünk van egy speciális szerszámra, amihez nem kell semmit sem telepíteni, vagyis a gyártásnál egyáltalán nem kell telepíteni semmit. Telepítse laptopjára vagy egy megfigyelő szerverre, ahonnan futtatni fogja. És sok mindent elemezni fog: az operációs rendszert, a fájlrendszert és magát a Postgres-t, néhány egyszerű lekérdezést végrehajtva, amelyek közvetlenül futtathatók az éles környezetben, és semmi sem fog meghiúsulni.

Postgres-checkup-nak hívtuk. Orvosi értelemben ez egy rendszeres egészségügyi vizsgálat. Ha autóipari témájú, akkor ez olyan, mint a karbantartás. Márkától függően félévente vagy évente karbantartja autóját. Karbantartást végez a bázisán? Vagyis rendszeresen végez mélyreható kutatásokat? Meg kell tenni. Ha biztonsági másolatot készít, akkor végezzen ellenőrzést, ez nem kevésbé fontos.

És van egy ilyen eszközünk. Csak körülbelül három hónapja kezdett aktívan megjelenni. Még fiatal, de sok minden van.

A „legbefolyásosabb” lekérdezési csoportok összegyűjtése – K003 jelentés a Postgres-checkupban

És van egy jelentéscsoport K. Eddig három jelentés. És van egy ilyen K003 jelentés. Ott van a pg_stat_statements legteteje, total_time szerint rendezve.

Amikor a kéréscsoportokat total_time szerint rendezzük, felül azt a csoportot látjuk, amelyik a legtöbbet terheli rendszerünket, azaz több erőforrást fogyaszt. Miért nevezek el lekérdezési csoportokat? Mert kidobtuk a paramétereket. Ezek már nem kérések, hanem kérések csoportjai, azaz elvonatkoztattak.

Ha pedig felülről lefelé optimalizálunk, akkor könnyítjük erőforrásainkat, és elhalasztjuk azt a pillanatot, amikor frissíteni kell. Ez egy nagyon jó módja a megtakarításnak.

Talán ez nem túl jó módja a felhasználók gondozásának, mert nem ritka, de nagyon bosszantó eseteket láthatunk, amikor az ember 15 másodpercet várt. Összességében olyan ritkák, hogy nem látjuk őket, de erőforrásokkal van dolgunk.

Mi történt ebben a táblázatban? Készítettünk két pillanatfelvételt. A Postgres_checkup minden mutatóhoz egy deltát ad: teljes idő, hívások, sorok, megosztott_blks_olvasás stb. Ez az, a delta kiszámítása megtörtént. A pg_stat_statements nagy problémája az, hogy nem emlékszik, mikor lett visszaállítva. Ha a pg_stat_database emlékszik, akkor a pg_stat_statements nem emlékszik. Látja, hogy van egy 1 000 000-es szám, de nem tudjuk, honnan számoltuk.

És itt tudjuk, itt van két pillanatképünk. Tudjuk, hogy a delta ebben az esetben 56 másodperc volt. Nagyon rövid rés. Összes_idő szerint rendezve. És akkor meg tudjuk különböztetni, azaz az összes mérőszámot elosztjuk időtartammal. Ha az egyes mérőszámokat elosztjuk az időtartammal, megkapjuk a másodpercenkénti hívások számát.

Ezután a másodpercenkénti összidő a kedvenc mérőszámom. Másodpercben, másodpercenként mérik, azaz hány másodpercbe telt a rendszerünk, hogy másodpercenként végrehajtsa ezt a kéréscsoportot. Ha másodpercenként egy másodpercnél többet lát ott, az azt jelenti, hogy egynél több magot kellett megadnia. Ez egy nagyon jó mérőszám. Megértheti, hogy ennek a barátnak például legalább három magra van szüksége.

Ez a mi know-how-nk, ilyet még sehol nem láttam. Kérjük, vegye figyelembe - ez nagyon egyszerű dolog - másodpercenként. Néha, amikor a CPU 100%-os, akkor fél órát másodpercenként, vagyis fél órát töltött éppen ezzel a kéréssel.

Ezután sorokat látunk másodpercenként. Tudjuk, hogy másodpercenként hány sort tért vissza.

És akkor van még egy érdekesség. Hány megosztott_puffert olvasunk ki másodpercenként magából a shared_bufferből. A találatok már megvoltak, a sorokat az operációs rendszer gyorsítótárából vagy a lemezről vettük. Az első lehetőség gyors, a második pedig lehet, hogy gyors vagy nem, a helyzettől függően.

A megkülönböztetés második módja pedig a kérelmek számának felosztása ebben a csoportban. A második oszlopban mindig egy lekérdezés lesz elosztva lekérdezésenként. És akkor érdekes - hány ezredmásodperc volt ebben a kérésben. Tudjuk, hogy ez a lekérdezés hogyan viselkedik átlagosan. Minden kéréshez 101 ezredmásodperc kellett. Ez a hagyományos mérőszám, amelyet meg kell értenünk.

Átlagosan hány sort adott vissza az egyes lekérdezések? 8-at látunk, amikor ez a csoport visszatér. Átlagosan mennyit vettek ki a gyorsítótárból és mennyit olvastak el. Látjuk, hogy minden szépen gyorsítótárazott. Szilárd találatok az első csoportban.

És minden sorban a negyedik részkarakterlánc az összesség hány százaléka. Vannak hívásaink. Tegyük fel, hogy 1 000 000. És megértjük, milyen hozzájárulást ad ez a csoport. Látjuk, hogy ebben az esetben az első csoport kevesebb, mint 0,01%-kal járul hozzá. Vagyis annyira lassú, hogy nem látjuk az összképben. A második csoport pedig a hívások 5%-a. Vagyis az összes hívás 5%-a a második csoport.

A Total_time is érdekes. A teljes munkaidőnk 14%-át fordítottuk az első csoportos kérésekre. A másodiknál ​​pedig 11% stb.

Nem megyek bele a részletekbe, de vannak finomságok. Felül egy hibát jelenítünk meg, mert összehasonlításkor a pillanatképek lebeghetnek, vagyis előfordulhat, hogy egyes kérések kiesnek, és a másodikban már nem jelenhetnek meg, míg újak jelenhetnek meg. És ott kiszámoljuk a hibát. Ha 0-t lát, az jó. Nincsenek hibák. Ha a hibaarány eléri a 20%-ot, az rendben van.

Aztán visszatérünk témánkhoz. Meg kell alakítanunk a munkaterhelést. Felülről lefelé haladva megyünk, amíg el nem érjük a 80%-ot vagy a 90%-ot. Általában ez 10-20 csoport. És fájlokat készítünk a pgbench számára. Ott random használunk. Néha ez sajnos nem megy. A Postgres 12-ben pedig több lehetőség lesz ennek a megközelítésnek a használatára.

És akkor 80-90%-ot nyerünk az összes_időben így. Mit tegyek a „@” után? Megnézzük a felhívásokat, megnézzük, mekkora az érdeklődés, és megértjük, hogy ennyi kamattal tartozunk itt. Ezekből a százalékokból megérthetjük, hogyan kell kiegyensúlyozni az egyes fájlokat. Utána pgbench-et használunk és megyünk dolgozni.

Nálunk van K001 és K002 is.

A K001 egy nagy karakterlánc négy részstringgel. Ez az egész terhelésünkre jellemző. Lásd a második oszlopot és a második alsort. Azt látjuk, hogy kb másfél másodperc másodpercenként, azaz ha két mag van, akkor jó lesz. A kapacitás körülbelül 75%-a lesz. És ez így fog működni. Ha 10 magunk van, akkor általában nyugodtak leszünk. Így tudjuk értékelni az erőforrásokat.

A K002-t lekérdezési osztályoknak hívom, azaz SELECT, INSERT, UPDATE, DELETE. És külön SELECT FOR UPDATE, mert ez egy zár.

És itt arra a következtetésre juthatunk, hogy a SELECT közönséges olvasók - az összes hívás 82% -a, de ugyanakkor - a total_time 74% -a. Vagyis sokat hívnak, de kevesebb erőforrást fogyasztanak.

És visszatérünk a kérdéshez: „Hogyan választhatjuk ki a megfelelő megosztott_puffereket?” Megfigyelem, hogy a legtöbb benchmark az elgondoláson alapul – lássuk, mi lesz az áteresztőképesség, azaz mi lesz az áteresztőképesség. Általában TPS-ben vagy QPS-ben mérik.

Mi pedig a tuning paraméterek segítségével igyekszünk minél több tranzakciót kicsikarni másodpercenként az autóból. Itt pontosan 311 másodpercenként a kiválasztottnál.

De senki sem hajt teljes sebességgel munkába és haza. Ez butaság. Ugyanez az adatbázisokkal. Nem kell teljes sebességgel haladnunk, és senki sem teszi. Senki sem él a termelésben, ami 100%-os CPU-val rendelkezik. Bár lehet, hogy valaki él, de ez nem jó.

Az ötlet az, hogy általában 20 százalékos kapacitással vezetünk, lehetőleg legfeljebb 50 százalékot. És mindenekelőtt igyekszünk optimalizálni felhasználóink ​​válaszidejét. Vagyis feltételesen el kell tekernünk a gombjainkat, hogy 20%-os sebességnél legyen minimális késleltetés. Ezt az ötletet mi is megpróbáljuk felhasználni kísérleteinkben.

És végül, ajánlások:

• Ügyeljen arra, hogy végezzen Database Lab-ot.
• Lehetőleg igény szerint csináld, hogy egy darabig kibontakozzon – játssz és dobd el. Ha felhők vannak, akkor ez magától értetődő, azaz sokat kell állnia.
• Kíváncsi. És ha valami nincs rendben, akkor kísérletekkel ellenőrizze, hogyan viselkedik. Nancy segítségével kiképezheti magát, hogy ellenőrizze az alap működését.
• És törekedjen a minimális válaszidőre.
• És ne félj a Postgres forrásaitól. Amikor forrásokkal dolgozik, tudnia kell angolul. Rengeteg hozzászólás van, ott minden el van magyarázva.
• És ellenőrizze az adatbázis állapotát rendszeresen, legalább háromhavonta, manuálisan vagy Postgres-ellenőrzéssel.

kérdések

Nagyon köszönöm! Nagyon érdekes dolog.

Két darab.

Igen, két darab. Csak én nem egészen értettem. Amikor Nancy és én dolgozunk, csak egy paramétert módosíthatunk, vagy egy egész csoportot?

Van egy delta config paraméterünk. Egyszerre annyit fordulhatsz ott, amennyit csak akarsz. De meg kell értened, hogy ha sok mindent megváltoztatsz, rossz következtetéseket vonhatsz le.

Igen. Miért kérdeztem? Mert nehéz kísérleteket végezni, ha csak egy paraméter van. Szorítsd meg, nézd meg, hogyan működik. kiraktam. Aztán kezdi a következőt.

Egyben meg is húzhatod, de ez persze helyzetfüggő. De jobb egy ötletet tesztelni. Tegnap volt egy ötletünk. Nagyon szoros helyzetünk volt. Két konfig volt. És nem tudtuk megérteni, hogy miért van nagy különbség. És felmerült az ötlet, hogy dichotómiát kell használni ahhoz, hogy következetesen megértsük és megtaláljuk, mi a különbség. A paraméterek felét azonnal azonosá teheti, majd a negyedét stb. Minden rugalmas.

És van még egy kérdés. A projekt fiatal és fejlődő. A dokumentáció már készen van, van részletes leírás?

Ott konkrétan linket tettem a paraméterek leírásához. Ott van. De sok minden még nincs meg. Hasonló gondolkodású embereket keresek. És megtalálom őket, amikor fellépek. Ez nagyon klassz. Valaki már dolgozik velem, valaki segített és csinált valamit ott. És ha érdekel ez a téma, adj visszajelzést arról, hogy mi hiányzik.

Ha felépítjük a laboratóriumot, talán lesz visszajelzés. Lássuk. Köszönöm!

Helló! Köszönöm a beszámolót! Láttam, hogy van Amazon támogatás. Tervezik-e a GSP támogatását?

Jó kérdés. Elkezdtük csinálni. És egyelőre lefagyasztottuk, mert pénzt akarunk spórolni. Vagyis van támogatás a run on localhost használatával. Ön is létrehozhat egy példányt, és helyileg dolgozhat. Egyébként ezt csináljuk. Ezt csinálom a Getlabnál, ott a GSP-nél. De egyelőre nem látjuk értelmét ilyen hangszerelésnek, mert a Google-nak nincsenek olcsó helyei. Van ??? esetek, de vannak korlátai. Először is, mindig csak 70% kedvezményt adnak, és ott nem lehet játszani az árral. A szpotokon 5-10%-kal emeljük az árat, hogy csökkentsük a kirúgás esélyét. Vagyis foltokat spórolsz, de azokat bármikor elvehetik tőled. Ha egy kicsit magasabb ajánlatot tesz, mint mások, később meghalnak. A Google teljesen más sajátosságokkal rendelkezik. És van még egy nagyon rossz korlátozás: csak 24 óráig élnek. És néha szeretnénk egy kísérletet 5 napig futtatni. De ezt foltokban is megteheti; a foltok néha hónapokig tartanak.

Helló! Köszönöm a beszámolót! Említetted az ellenőrzést. Hogyan számítja ki a stat_statements hibákat?

Nagyon jó kérdés. Nagyon részletesen meg tudom mutatni és elmondani. Röviden, megnézzük, hogyan úszott a kéréscsoportok halmaza: hány esett le és hány új jelent meg. Ezután megvizsgálunk két mérőszámot: az összes_időt és a hívásokat, tehát két hiba van. És nézzük a lebegő csoportok hozzájárulását. Két alcsoport van: a távozók és az érkezők. Lássuk, mi a hozzájárulásuk az összképhez.

Nem fél attól, hogy a pillanatfelvételek között kétszer-háromszor odafordul?

Vagyis újra regisztráltak vagy mi?

Például ezt a kérést már egyszer előzték meg, aztán jött és újra elővételben volt, aztán újra előkerült és újra elővételben volt. És itt kiszámoltál valamit, és hol van ez az egész?

Jó kérdés, meg kell néznünk.

Én is csináltam hasonlót. Persze egyszerűbb volt, egyedül csináltam. De vissza kellett állítanom, alaphelyzetbe kellett állítanom a stat_statements-t, és a pillanatkép készítésekor rá kellett jönnöm, hogy egy bizonyos töredéknél kevesebb van, ami még mindig nem érte el a plafont, hogy mennyi stat_statements halmozódhat fel ott. És én úgy tudom, hogy valószínűleg semmi sem mozdult el.

Igen igen.

De nem értem, hogyan lehetne másként megbízhatóan csinálni.

Sajnos nem emlékszem pontosan, hogy ott a lekérdezés szövegét használjuk, vagy a queryid-t pg_stat_statements-szel és arra koncentrálunk. Ha a queryid-re koncentrálunk, akkor elméletileg összehasonlítható dolgokat hasonlítunk össze.

Nem, a pillanatfelvételek között többször is ki lehet kényszeríteni, és újra eljön.

Ugyanazzal az azonosítóval?

Igen.

Ezt tanulmányozzuk. Jó kérdés. Tanulmányoznunk kell. De most, amit látunk, az vagy 0-ra van írva...

Ez persze ritka eset, de megdöbbentem, amikor megtudtam, hogy a stat_statemetns kiszorulhat oda.

A Pg_stat_statementsben sok minden szerepelhet. Arra jöttünk rá, hogy ha a track_utility = be van kapcsolva, akkor a készleteidet is nyomon követik.

Igen, természetesen.

És ha van java hibernálása, ami véletlenszerű, akkor a hash tábla ott kezd el helyezkedni. És amint kikapcsol egy nagyon betöltött alkalmazást, 50-100 csoportot kap. És ott többé-kevésbé stabil minden. Ennek egyik módja a pg_stat_statements.max növelése.

Igen, de tudnia kell, hogy mennyi. És valahogy szemmel kell tartanunk őt. Ez amit csinálok. Vagyis van pg_stat_statements.max. És látom, hogy a pillanatfelvétel idején még nem értem el a 70%-ot. Oké, nem vesztettünk semmit. Állítsuk vissza. És megint spórolunk. Ha a következő pillanatkép kevesebb, mint 70, akkor valószínűleg nem veszített újra semmit.

Igen. Az alapértelmezett most 5. És ez sok embernek elég.

Általában igen.

videók:

PS A magam nevében hozzáteszem, hogy ha a Postgres bizalmas adatokat tartalmaz, és nem kerülhet be a tesztkörnyezetbe, akkor PostgreSQL névtelenítő. A séma körülbelül a következő:

Forrás: will.com