Navrhuji, abyste si přečetli přepis zprávy Nikolaje Samokhvalova „Průmyslový přístup k ladění PostgreSQL: experimenty s databázemi“
Shared_buffers = 25 % – je to hodně nebo málo? Nebo jen správně? Jak víte, zda je toto – poněkud zastaralé – doporučení vhodné ve vašem konkrétním případě?
Je čas přistoupit k problému výběru parametrů postgresql.conf „jako dospělý“. Ne pomocí slepých „autotunerů“ nebo zastaralých rad z článků a blogů, ale na základě:
- přísně ověřené experimenty na databázích, prováděné automaticky, ve velkém množství a za podmínek co nejblíže „bojovým“,
- hluboké porozumění funkcím DBMS a OS.
Pomocí Nancy CLI (), podíváme se na konkrétní příklad – notoricky známé shared_buffers – v různých situacích, v různých projektech a pokusíme se přijít na to, jak zvolit optimální nastavení pro naši infrastrukturu, databázi a zátěž.
Budeme mluvit o experimentech s databázemi. Toto je příběh, který trvá něco málo přes šest měsíců.
Něco málo o mně. Zkušenosti s Postgres více než 14 let. Bylo založeno několik společností zabývajících se sociálními sítěmi. Postgres byl a je používán všude.
Také skupina RuPostgres na Meetup, 2. místo na světě. Pomalu se blížíme ke 2 lidem. RuPostgres.org.
A na PC různých konferencí včetně Highload jsem od začátku zodpovědný za databáze, konkrétně Postgres.
A v posledních několika letech jsem restartoval svou poradenskou praxi Postgres 11 časových pásem odtud.
A když jsem to před pár lety udělal, měl jsem nějakou pauzu v aktivní manuální práci s Postgres, pravděpodobně od roku 2010. Překvapilo mě, jak málo se pracovní rutina DBA změnila a kolik manuální práce je stále potřeba využívat. A hned mě napadlo, že tady není něco v pořádku, potřebuji vše více zautomatizovat.
A jelikož to bylo všechno na dálku, většina klientů byla v oblacích. A mnohé už bylo zautomatizováno, samozřejmě. Více o tom později. To vše vyústilo v myšlenku, že by měla existovat řada nástrojů, tedy nějaká platforma, která zautomatizuje téměř všechny akce DBA tak, aby bylo možné spravovat velké množství databází.
Tento přehled nebude obsahovat:
- „Stříbrné odrážky“ a prohlášení jako – nastavte 8 GB nebo 25 % shared_buffers a budete v pořádku. O shared_bufferech toho moc nebude.
- Hardcore "vnitřnosti".
Co se stane?
- Budou existovat principy optimalizace, které aplikujeme a vyvíjíme. Objeví se nejrůznější nápady, které vzniknou cestou, a různé nástroje, které tvoříme z velké části v Open Source, tedy základ tvoříme v Open Source. Navíc máme vstupenky, veškerá komunikace je prakticky Open Source. Můžete vidět, co děláme nyní, co bude v příštím vydání atd.
- Budou také určité zkušenosti s používáním těchto principů, těchto nástrojů v řadě společností: od malých startupů po velké společnosti.
Jak se to všechno vyvíjí?
Za prvé, hlavním úkolem DBA je kromě zajištění tvorby instancí, nasazování záloh atd. nacházet úzká místa a optimalizovat výkon.
Nyní je to takto nastavené. Díváme se na monitoring, něco vidíme, ale chybí nám nějaké detaily. Začneme kopat opatrněji, obvykle rukama, a pochopíme, co s tím tak či onak.
A existují dva přístupy. Pg_stat_statements je výchozí řešení pro identifikaci pomalých dotazů. A analýza protokolů Postgres pomocí pgBadger.
Každý přístup má vážné nevýhody. V prvním přístupu jsme vyhodili všechny parametry. A pokud vidíme tabulky skupin SELECT * FROM, kde se sloupec rovná "?" nebo „$“ od Postgres 10. Nevíme, zda se jedná o indexový sken nebo sekvenční sken. Velmi záleží na parametru. Pokud tam dosadíte zřídka se vyskytující hodnotu, bude to indexové skenování. Pokud dosadíte hodnotu, která tam zabírá 90 % tabulky, seq scan bude zřejmý, protože Postgres statistiky zná. A to je velká nevýhoda pg_stat_statements, i když na některých pracích se pracuje.
Největší nevýhodou analýzy protokolů je, že si zpravidla nemůžete dovolit "log_min_duration_statement = 0". A o tom si také povíme. V důsledku toho nevidíte celý obrázek. A některý dotaz, který je velmi rychlý, může spotřebovat obrovské množství zdrojů, ale vy ho neuvidíte, protože je pod vaším prahem.
Jak DBA řeší problémy, které najdou?
Například jsme našli nějaký problém. Co se obvykle dělá? Pokud jste vývojář, pak budete dělat něco na nějaké instanci, která nemá stejnou velikost. Pokud jste DBA, pak máte inscenaci. A může být jen jeden. A byl o šest měsíců pozadu. A myslíte si, že půjdete do výroby. A dokonce i zkušení správci databází pak zkontrolují výrobu, na replice. A stane se, že vytvoří dočasný index, ujistí se, že pomáhá, zahodí ho a dají vývojářům, aby ho mohli vložit do migračních souborů. To je ten druh nesmyslu, který se teď děje. A to je problém.
- Vylaďte konfigurace.
- Optimalizujte sadu indexů.
- Změňte samotný SQL dotaz (toto je nejobtížnější metoda).
- Přidejte kapacitu (ve většině případů nejjednodušší způsob).
S těmito věcmi se toho děje hodně. V Postgresu je spousta klik. Je toho hodně znát. V Postgresu je mnoho indexů, děkujeme také organizátorům této konference. A to vše je potřeba vědět, a to je důvod, proč mají ne-DBA pocit, že DBA praktikují černou magii. To znamená, že musíte studovat 10 let, abyste tomu všemu začali normálně rozumět.
A já jsem bojovník proti této černé magii. Chci udělat vše pro to, aby byla technologie a v tom všem nebyla žádná intuice.
Příklady života
Pozoroval jsem to minimálně u dvou projektů, včetně mého vlastního. Další příspěvek na blogu nám říká, že hodnota 1 000 pro default_statistict_target je dobrá. Dobře, zkusíme to ve výrobě.
A jsme tady, o dva roky později pomocí našeho nástroje můžeme pomocí experimentů na databázích, o kterých dnes mluvíme, porovnávat, co bylo a co se stalo.
A k tomu potřebujeme vytvořit experiment. Skládá se ze čtyř částí.
- První je prostředí. Potřebujeme kus hardwaru. A když přijdu do nějaké firmy a podepíšu smlouvu, řeknu jim, ať mi dají stejný hardware jako ve výrobě. Pro každého vašeho Mistra potřebuji alespoň jeden takový hardware. Buď se jedná o instanční virtuální stroj v Amazonu nebo Google, nebo potřebuji přesně stejný kus hardwaru. To znamená, že chci znovu vytvořit prostředí. A do konceptu prostředí zahrnujeme hlavní verzi Postgresu.
- Druhá část je předmětem našeho výzkumu. Toto je databáze. Může být vytvořen několika způsoby. Ukážu vám jak.
- Třetí částí je zátěž. Toto je nejtěžší okamžik.
- A čtvrtá část je to, co kontrolujeme, tedy co s čím budeme porovnávat. Řekněme, že můžeme změnit jeden nebo více parametrů v konfiguraci, nebo můžeme vytvořit index atd.
Spouštíme experiment. Zde je pg_stat_statements. Vlevo je to, co se stalo. Vpravo - co se stalo.
Vlevo default_statistics_target = 100, vpravo = 1 000. Vidíme, že nám to pomohlo. Celkově se vše zlepšilo o 8 %.
Pokud se ale posuneme dolů, budou zde skupiny požadavků z pgBadger nebo z pg_stat_statements. Jsou dvě možnosti. Uvidíme, že některý požadavek klesl o 88 %. A zde přichází inženýrský přístup. Můžeme kopat hlouběji dovnitř, protože se divíme, proč se potopil. Musíte pochopit, co se stalo se statistikami. Proč více kýblů ve statistikách vede k horším výsledkům.
Nebo nemůžeme kopat, ale uděláme „ALTER TABLE ... ALTER COLUMN“ a vrátíme 100 kýblů zpět do statistiky tohoto sloupce. A pak s dalším experimentem se můžeme ujistit, že tento patch pomohl. Všechno. Jedná se o inženýrský přístup, který nám pomáhá vidět celkový obraz a rozhodovat se spíše na základě dat než na základě intuice.
Pár příkladů z jiných oblastí. Testy CI jsou v testování již mnoho let. A žádný projekt se zdravým rozumem by se neobešel bez automatizovaných testů.
V jiných odvětvích: v letectví, v automobilovém průmyslu, když testujeme aerodynamiku, máme také možnost dělat experimenty. Nevypustíme něco z nákresu přímo do vesmíru, nebo rovnou nepostavíme nějaké auto na trať. Je tu například aerodynamický tunel.
Můžeme vyvodit závěry z pozorování jiných průmyslových odvětví.
Za prvé, máme zvláštní prostředí. Je to blízko výroby, ale ne blízko. Jeho hlavním rysem je, že by měl být levný, opakovatelný a co nejvíce automatizovaný. A také musí existovat speciální nástroje pro provádění podrobné analýzy.
S největší pravděpodobností, když vypustíme letadlo a letíme, máme méně příležitostí studovat každý milimetr povrchu křídla než v aerodynamickém tunelu. Máme více diagnostických nástrojů. Můžeme si dovolit převážet těžší věci, které si nemůžeme dovolit dát do letadla ve vzduchu. To samé s Postgresem. V některých případech můžeme povolit úplné protokolování dotazů během experimentů. A to ve výrobě dělat nechceme. Můžeme dokonce plánovat, že to povolíme pomocí auto_explain.
A jak jsem řekl, vysoká úroveň automatizace znamená, že stiskneme tlačítko a opakujeme. Tak to má být, aby se hodně experimentovalo, aby to bylo na streamu.
Nancy CLI – základ „databázové laboratoře“
A tak jsme udělali tuto věc. To znamená, že jsem o těchto myšlenkách mluvil v červnu, téměř před rokem. A to už máme takzvané Nancy CLI v Open Source. To je základ pro vybudování databázové laboratoře.
— Je to v Open Source, na Gitlabu. Můžete to říct, můžete to zkusit. Dal jsem odkaz na snímky. Můžete na to kliknout a bude to tam ve všech ohledech.
Samozřejmě je toho ještě hodně ve vývoji. Je tam spousta nápadů. Ale to je něco, co používáme téměř každý den. A když máme nápad – proč je to tak, že když smažeme 40 000 000 řádků, všechno přijde na IO, pak můžeme provést experiment a podívat se podrobněji, abychom pochopili, co se děje, a pak se to pokusit opravit na cestách. To znamená, že děláme experiment. Například něco upravíme a uvidíme, co se nakonec stane. A to ve výrobě neděláme. To je podstata myšlenky.
Kde to může fungovat? To může fungovat lokálně, to znamená, že to můžete udělat kdekoli, dokonce to můžete spustit na MacBooku. Potřebujeme docker, pojďme. To je vše. Můžete jej spustit v určitém případě na kusu hardwaru nebo ve virtuálním počítači kdekoli.
A je tu také možnost běhat na dálku v Amazonu v EC2 Instance, ve spotech. A to je velmi skvělá příležitost. Například včera jsme provedli více než 500 experimentů na instanci i3, počínaje nejmladší a konče i3-16-xlarge. A 500 experimentů nás stálo 64 dolarů. Každá trvala 15 minut. Čili díky tomu, že se tam používají spoty, je to velmi levné - 70% sleva, sekundová fakturace Amazonu. Dokážeš hodně. Můžete udělat skutečný výzkum.
A podporovány jsou tři hlavní verze Postgresu. Není tak těžké dokončit některé staré a také novou 12. verzi.
Objekt můžeme definovat třemi způsoby. Tento:
- Dump/sql soubor.
- Hlavním způsobem je naklonovat adresář PGDATA. Zpravidla se přebírá ze záložního serveru. Pokud máte normální binární zálohy, můžete odtud vytvářet klony. Pokud máte mraky, cloudová kancelář jako Amazon a Google to udělá za vás. Toto je nejdůležitější způsob klonování skutečné produkce. Takto se odvíjíme.
- A poslední metoda je vhodná pro výzkum, když chcete pochopit, jak něco v Postgresu funguje. Toto je pgbench. Můžete generovat pomocí pgbench. Je to jen jedna možnost "db-pgbench". Řekni mu, jaké měřítko. A vše bude generováno v cloudu, jak je uvedeno.
A načíst:
- Načtení můžeme provést v jednom SQL vláknu. Toto je nejprimitivnější způsob.
- A můžeme emulovat zátěž. A můžeme to nejprve napodobit následujícím způsobem. Musíme posbírat všechny protokoly. A je to bolestivé. Ukážu vám proč. A hrajeme pomocí pgreplay, který je zabudován do Nancy.
- Nebo jiná možnost. Takzvaná řemeslná zátěž, kterou děláme s určitým úsilím. Při analýze našeho aktuálního zatížení bojového systému vytáhneme nejvyšší skupiny požadavků. A pomocí pgbench můžeme tuto zátěž emulovat v laboratoři.
- Buď musíme provést nějaké SQL, tedy zkontrolujeme nějakou migraci, vytvoříme tam index, tam spustíme ANALAZE. A podíváme se na to, co se stalo před vakuem a po vakuu. Obecně platí, že jakékoli SQL.
- Buď změníme jeden nebo více parametrů v konfiguraci. Můžeme nám říct, abychom zkontrolovali například 100 hodnot v Amazonu pro naši terabajtovou databázi. A za pár hodin budete mít výsledek. Nasazení terabajtové databáze vám zpravidla zabere několik hodin. Ale ve vývoji je záplata, máme řadu možných, tj. můžete konzistentně používat stejná pgdata na stejném serveru a kontrolovat. Postgres se restartuje a mezipaměti budou resetovány. A můžete řídit náklad.
- Dorazí adresář se spoustou různých souborů, počínaje snímky pgstat***. A nejzajímavější věc je pg_stat_statements, pg_stat_kcacke. Jedná se o dvě rozšíření, která analyzují požadavky. A pg_stat_bgwriter obsahuje nejen statistiky pgwriter, ale také o kontrolním bodu a o tom, jak samotné backendy vytlačují špinavé buffery. A je to všechno zajímavé vidět. Když například nastavíme sdílené_buffery, je velmi zajímavé sledovat, kolik toho všichni nahradili.
- Přicházejí také protokoly Postgres. Dva protokoly – protokol přípravy a protokol přehrávání načtení.
- Relativně novou funkcí je FlameGraphs.
- Také pokud jste pro přehrávání zátěže použili možnosti pgreplay nebo pgbench, jejich výstup bude nativní. A uvidíte latenci a TPS. Bude možné pochopit, jak to viděli.
- Systémové informace.
- Základní kontroly CPU a IO. To je spíše pro EC2 instanci v Amazonu, když chcete spustit 100 stejných instancí ve vláknu a spustit tam 100 různých běhů, pak budete mít 10 000 experimentů. A musíte se ujistit, že nenarazíte na chybnou instanci, která je již někým utlačována. Ostatní jsou na tomto hardwaru aktivní a vám zbývá málo prostředků. Takové výsledky je lepší zahodit. A s pomocí sysbenche od Alexeje Kopytova uděláme několik krátkých kontrol, které přijdou a lze je porovnat s ostatními, čili pochopíte, jak se chová CPU a jak se chová IO.
Jaké jsou technické potíže na příkladu různých společností?
Řekněme, že chceme opakovat skutečné zatížení pomocí protokolů. Je to skvělý nápad, pokud je napsán na Open Source pgreplay. Používáme to. Ale aby to dobře fungovalo, musíte povolit úplné protokolování dotazů s parametry a načasováním.
Existují určité komplikace s trváním a časovým razítkem. Vyprázdníme celou kuchyni. Hlavní otázkou je, zda si to můžete dovolit nebo ne?
Problém je, že nemusí být k dispozici. Nejprve musíte pochopit, jaký proud bude zapsán do protokolu. Pokud máte pg_stat_statements, můžete použít tento dotaz (odkaz bude k dispozici na snímcích), abyste přibližně pochopili, kolik bajtů bude zapsáno za sekundu.
Díváme se na délku žádosti. Zanedbáváme skutečnost, že neexistují žádné parametry, ale známe délku požadavku a víme, kolikrát za sekundu byl proveden. Tímto způsobem můžeme odhadnout, kolik přibližně bajtů za sekundu. Možná uděláme chybu dvakrát tolik, ale objednávku takto určitě pochopíme.
Vidíme, že tento požadavek je vykonán 802krát za sekundu. A vidíme, že bytes_per sec – 300 kB/s bude zapsáno plus mínus. A takový tok si zpravidla můžeme dovolit.
Ale! Faktem je, že existují různé systémy protokolování. A výchozí nastavení lidí je obvykle „syslog“.
A pokud máte syslog, můžete mít takový obrázek. Vezmeme pgbench, povolíme protokolování dotazů a uvidíme, co se stane.
Bez protokolování - toto je sloupec vlevo. Máme 161 000 TPS. Se syslogem – to je v Ubuntu 16.04 na Amazonu, získáme 37 000 TPS. A pokud přejdeme na dvě další metody protokolování, pak je situace mnohem lepší. To znamená, že jsme čekali, že klesne, ale ne ve stejné míře.
A na CentOS 7, na kterém se podílí také journald, převádí protokoly do binárního formátu pro snadné vyhledávání atd., pak je to noční můra, klesáme 44krát v TPS.
A s tím lidé žijí. A často ve firmách, zvláště velkých, se to mění jen velmi těžko. Pokud se můžete dostat pryč od syslog, pak prosím pryč od něj.
- Vyhodnoťte IOPS a tok zápisu.
- Zkontrolujte svůj logovací systém.
- Pokud je projektované zatížení příliš velké, zvažte odběr vzorků.
Máme pg_stat_statements. Jak jsem řekl, musí tam být. A každou skupinu požadavků můžeme vzít a popsat zvláštním způsobem v souboru. A pak můžeme použít velmi pohodlnou funkci v pgbench - to je schopnost vložit několik souborů pomocí volby „-f“.
Rozumí hodně "-f". A pomocí „@“ na konci můžete zjistit, jaké sdílení by měl mít každý soubor. To znamená, že můžeme říci, že tak učiní v 10 % případů a toto ve 20 %. A tím se přiblížíme tomu, co vidíme ve výrobě.
Jak budeme rozumět tomu, co máme ve výrobě? Jaký podíl a jak? Tohle je trochu stranou. Máme ještě jeden produkt . Také základ v Open Source. A nyní ji aktivně rozvíjíme.
Narodil se z trochu jiných důvodů. Z důvodů, že sledování nestačí. To znamená, že přijdete, podíváte se na základnu, podíváte se na problémy, které existují. A zpravidla provedete zdravotní kontrolu. Pokud jste zkušený DBA, pak proveďte health_check. Podívali jsme se na použití indexů atd. Pokud máte OKmeter, tak super. Toto je skvělý monitoring pro Postgres. OKmeter.io – nainstalujte si ho, tam je vše udělané velmi dobře. Je to placené.
Pokud žádný nemáte, pak většinou nemáte moc. V monitorování je obvykle CPU, IO a pak s výhradami, a to je vše. A potřebujeme víc. Musíme vidět, jak funguje autovakuum, jak funguje kontrolní bod, v io musíme oddělit kontrolní bod od bgwriteru a od backendů atd.
Problém je v tom, že když pomáháte velké firmě, nemůže něco rychle zavést. Nemohou rychle koupit OKmeter. Možná to koupí za šest měsíců. Nemohou rychle doručit některé balíčky.
A přišli jsme s myšlenkou, že potřebujeme speciální nástroj, který nepotřebuje nic instalovat, čili nemusíte při výrobě vůbec nic instalovat. Nainstalujte si jej do svého notebooku nebo na pozorovací server, odkud jej budete spouštět. A bude analyzovat spoustu věcí: operační systém, souborový systém a samotný Postgres, vytvoří nějaké lehké dotazy, které lze spustit přímo do produkce a nic se nezdaří.
Nazvali jsme to Postgres-checkup. Z lékařského hlediska se jedná o pravidelnou zdravotní prohlídku. Pokud je to s automobilovou tématikou, pak je to jako údržba. Údržbu na autě provádíte každých šest měsíců nebo rok, v závislosti na značce. Provádíte údržbu své základny? To znamená, že provádíte hluboký výzkum pravidelně? Musí se to udělat. Pokud děláte zálohy, pak proveďte kontrolu, to je neméně důležité.
A my takový nástroj máme. Aktivně se začal objevovat teprve asi před třemi měsíci. Je ještě mladý, ale je toho hodně.
Shromažďování „nejvlivnějších“ skupin dotazů – report K003 v Postgres-checkup
A je tu skupina zpráv K. Zatím tři zprávy. A existuje taková zpráva K003. Tam je začátek z pg_stat_statements, seřazený podle total_time.
Když třídíme skupiny požadavků podle total_time, nahoře vidíme skupinu, která nejvíce zatěžuje náš systém, tj. spotřebovává více zdrojů. Proč pojmenovávám skupiny dotazů? Protože jsme vyhodili parametry. Už to nejsou požadavky, ale skupiny žádostí, tedy jsou abstrahovány.
A pokud budeme optimalizovat shora dolů, ulehčíme našim zdrojům a oddálíme okamžik, kdy je potřeba upgradovat. To je velmi dobrý způsob, jak ušetřit peníze.
Možná to není příliš dobrý způsob, jak se o uživatele postarat, protože možná nevidíme vzácné, ale velmi nepříjemné případy, kdy člověk čekal 15 sekund. Celkově jsou tak vzácné, že je nevidíme, ale máme co do činění se zdroji.
Co se stalo v této tabulce? Pořídili jsme dva snímky. Postgres_checkup vám dá rozdíl pro každou metriku: celkový čas, volání, řádky, shared_blks_read atd. To je vše, rozdíl byl vypočten. Velký problém s pg_stat_statements je, že si nepamatuje, kdy byl resetován. Pokud si pg_stat_database pamatuje, pak si pg_stat_statements nepamatuje. Vidíte, že existuje číslo 1 000 000, ale nevíme, odkud jsme počítali.
A tady víme, tady máme dva momentky. Víme, že delta v tomto případě byla 56 sekund. Velmi krátká mezera. Seřazeno podle total_time. A pak můžeme diferencovat, tedy dělit všechny metriky podle trvání. Pokud každou metriku vydělíme dobou trvání, získáme počet hovorů za sekundu.
Dále, celkový_čas za sekundu je moje oblíbená metrika. Měří se v sekundách za sekundu, tj. kolik sekund našemu systému trvalo provedení této skupiny požadavků za sekundu. Pokud tam vidíte více než sekundu za sekundu, znamená to, že jste museli dát více než jedno jádro. Toto je velmi dobrá metrika. Můžete pochopit, že například tento přítel potřebuje alespoň tři jádra.
To je naše know-how, nikde jsem nic podobného neviděl. Vezměte prosím na vědomí - toto je velmi jednoduchá věc - sekundu za sekundu. Někdy, když je váš CPU 100%, pak půl hodiny za sekundu, to znamená, že jste půl hodiny strávili právě těmito požadavky.
Dále vidíme řádky za sekundu. Víme, kolik řádků za sekundu to vrátilo.
A pak je tu také zajímavá věc. Kolik shared_bufferů načteme za sekundu ze samotných shared_bufferů. Zásahy již byly a řádky jsme vzali z mezipaměti operačního systému nebo z disku. První možnost je rychlá a druhá může nebo nemusí být rychlá, v závislosti na situaci.
A druhým způsobem rozlišení je rozdělení počtu požadavků v této skupině. Ve druhém sloupci budete mít vždy jeden dotaz rozdělený na dotaz. A pak je zajímavé - kolik milisekund bylo v této žádosti. Víme, jak se tento dotaz průměrně chová. Na každý požadavek bylo potřeba 101 milisekund. Toto je tradiční metrika, kterou musíme pochopit.
Kolik řádků průměrně vrátil každý dotaz? Vidíme, že se tato skupina vrací 8. V průměru, kolik bylo odebráno z mezipaměti a přečteno. Vidíme, že vše je pěkně kešováno. Solidní hity pro první skupinu.
A čtvrtý podřetězec v každém řádku je procento z celkového počtu. Máme hovory. Řekněme 1 000 000. A můžeme pochopit, jaký přínos tato skupina přináší. Vidíme, že v tomto případě první skupina přispívá méně než 0,01 %. To znamená, že je tak pomalý, že to v celkovém obrazu nevidíme. A druhá skupina je 5% na hovory. To znamená, že 5 % všech hovorů tvoří druhá skupina.
Zajímavý je také Total_time. První skupině požadavků jsme věnovali 14 % naší celkové pracovní doby. A za druhé - 11% atd.
Nebudu zabíhat do podrobností, ale jsou tam jemnosti. Nahoře zobrazujeme chybu, protože když porovnáváme, snímky mohou plavat, to znamená, že některé požadavky mohou vypadnout a ve druhém již nemohou být, zatímco se mohou objevit nějaké nové. A tam vypočítáme chybu. Pokud vidíte 0, pak je to dobré. Nejsou žádné chyby. Pokud je chybovost do 20 %, je to v pořádku.
Pak se vrátíme k našemu tématu. Potřebujeme zvládnout pracovní náplň. Vezmeme to shora dolů a jdeme, dokud nedosáhneme 80 % nebo 90 %. Obvykle je to 10-20 skupin. A děláme soubory pro pgbench. Tam používáme náhodné. Někdy to bohužel nevyjde. A v Postgres 12 bude více příležitostí k využití tohoto přístupu.
A pak tímto způsobem získáme 80-90 % celkového času. Co mám dát dál za „@“? Podíváme se na hovory, podíváme se, jaký je zájem, a pochopíme, že tady dlužíme tolik zájmu. Z těchto procent můžeme pochopit, jak vyvážit každý ze souborů. Poté použijeme pgbench a jdeme do práce.
Máme také K001 a K002.
K001 je jeden velký řetězec se čtyřmi podřetězci. To je charakteristika celé naší zátěže. Viz druhý sloupec a druhý podřádek. Vidíme, že asi jedna a půl sekundy za sekundu, tedy pokud jsou dvě jádra, tak to bude dobré. Kapacita bude přibližně 75 %. A bude to fungovat takto. Pokud máme 10 jader, tak budeme obecně v klidu. Tímto způsobem můžeme hodnotit zdroje.
K002 je to, čemu říkám třídy dotazů, tj. SELECT, INSERT, UPDATE, DELETE. A zvlášť VYBRAT PRO AKTUALIZACI, protože jde o zámek.
A zde můžeme konstatovat, že SELECT jsou běžní čtenáři – 82 % všech hovorů, ale zároveň – 74 % v celkovém čase. To znamená, že se jim říká hodně, ale spotřebovávají méně zdrojů.
A vracíme se k otázce: "Jak můžeme vybrat ty správné sdílené_buffery?" Pozoruji, že většina benchmarků je založena na myšlence – uvidíme, jaká bude propustnost, tedy jaká bude propustnost. Obvykle se měří v TPS nebo QPS.
A snažíme se z auta pomocí tuningových parametrů vymáčknout co nejvíce transakcí za sekundu. Zde je přesně 311 za sekundu pro výběr.
Do práce a zpět domů ale nikdo nejezdí plnou rychlostí. To je hloupé. To samé s databázemi. Nemusíme jet naplno a nikdo to nedělá. Nikdo nežije ve výrobě, která má 100% CPU. I když možná někdo žije, ale tohle není dobré.
Myšlenka je taková, že obvykle jezdíme na 20 procent kapacity, nejlépe ne více než 50 %. A snažíme se optimalizovat dobu odezvy především pro naše uživatele. To znamená, že musíme otočit naše knoflíky tak, aby byla minimální latence při 20% rychlosti, podmíněně. To je myšlenka, kterou se také snažíme využít v našich experimentech.
A nakonec doporučení:
- Nezapomeňte udělat Database Lab.
- Pokud je to možné, udělejte to na požádání, aby se to na chvíli rozložilo - hrajte a vyhoďte. Pokud máte mraky, pak je to samozřejmé, tj. hodně stát.
- Buď zvědavý. A pokud něco není v pořádku, pak pomocí experimentů zkontrolujte, jak se to chová. Nancy se dá použít k výcviku, abyste zkontrolovali, jak základna funguje.
- A zaměřte se na minimální dobu odezvy.
- A nebojte se zdrojů Postgres. Když pracujete se zdroji, musíte umět anglicky. Je tam spousta komentářů, vše je tam vysvětleno.
- A pravidelně kontrolujte stav databáze, alespoň jednou za tři měsíce, ručně nebo Postgres-checkup.
otázky
Díky moc! Velmi zajímavá věc.
Dva kusy.
Ano, dva kusy. Jen jsem tomu moc nerozuměl. Když Nancy a já pracujeme, můžeme vyladit pouze jeden parametr nebo celou skupinu?
Máme parametr delta config. Můžete se tam otáčet, kolik chcete najednou. Ale musíte pochopit, že když změníte spoustu věcí, můžete vyvodit špatné závěry.
Ano. Proč jsem se ptal? Protože je obtížné provádět experimenty, když máte pouze jeden parametr. Utáhneš to, uvidíš, jak to funguje. Dal jsem ho ven. Pak začnete další.
Můžete to zároveň utáhnout, ale záleží samozřejmě na situaci. Ale je lepší vyzkoušet jeden nápad. Včera jsme měli nápad. Měli jsme velmi blízkou situaci. Byly tam dvě konfigurace. A my jsme nemohli pochopit, proč tam byl velký rozdíl. A vznikla myšlenka, že musíte použít dichotomii, abyste důsledně pochopili a našli, v čem je rozdíl. Okamžitě můžete udělat polovinu parametrů stejnou, pak čtvrtinu atd. Vše je flexibilní.
A je tu ještě jedna otázka. Projekt je mladý a rozvíjející se. Dokumentace je již hotová, existuje podrobný popis?
Konkrétně jsem tam udělal odkaz na popis parametrů. je to tam. Ale spousta věcí tam ještě není. Hledám stejně smýšlející lidi. A nacházím je, když vystupuji. To je velmi cool. Někdo už se mnou spolupracuje, někdo tam pomohl a něco udělal. A pokud vás toto téma zajímá, dejte zpětnou vazbu, co chybí.
Jakmile postavíme laboratoř, možná bude zpětná vazba. Uvidíme. Děkuji!
Ahoj! Díky za zprávu! Viděl jsem, že existuje podpora Amazonu. Existují nějaké plány na podporu GSP?
Dobrá otázka. Začali jsme to dělat. A zatím jsme to zmrazili, protože chceme ušetřit. To znamená, že existuje podpora pomocí spuštění na localhost. Můžete si vytvořit instanci sami a pracovat lokálně. Mimochodem, to je to, co děláme. Dělám to v Getlab, tam v GSP. Ale zatím nevidíme smysl dělat jen takovou orchestraci, protože Google nemá levná místa. Tady je ??? případy, ale mají omezení. Jednak mají vždy jen 70% slevu a tam si s cenou hrát nemůžete. Na spotech zvyšujeme cenu o 5-10%, abychom snížili pravděpodobnost, že vás nakopnou. To znamená, že ušetříte místa, ale mohou vám být kdykoli odebrána. Pokud nabídnete o něco výše než ostatní, budete později zabiti. Google má úplně jiná specifika. A je tu ještě jedno velmi špatné omezení – žijí jen 24 hodin. A někdy chceme spustit experiment na 5 dní. Ale můžete to udělat bodově; skvrny někdy trvají měsíce.
Ahoj! Díky za zprávu! Zmínil jste kontrolu. Jak vypočítáte chyby stat_statements?
Velmi dobrá otázka. Mohu vám ukázat a říct velmi podrobně. Stručně řečeno, podíváme se na to, jak se množina skupin požadavků pohybovala: kolik jich odpadlo a kolik se objevilo nových. A pak se podíváme na dvě metriky: total_time a calls, takže tam jsou dvě chyby. A podíváme se na přínos plovoucích skupin. Existují dvě podskupiny: ti, kteří odešli, a ti, kteří přišli. Podívejme se, jaký je jejich přínos k celkovému obrazu.
Nebojíte se, že se to tam během doby mezi snímky dvakrát nebo třikrát otočí?
To znamená, že se znovu zaregistrovali nebo co?
Například tento požadavek byl již jednou preemptován, pak přišel a byl preemptován znovu, pak přišel znovu a byl preemptován znovu. A tady jsi něco spočítal a kde to všechno je?
Dobrá otázka, budeme se muset podívat.
Udělal jsem podobnou věc. Bylo to samozřejmě jednodušší, dělal jsem to sám. Ale musel jsem resetovat, resetovat stat_statements a v okamžiku snímku zjistit, že existuje méně než určitý zlomek, který stále nedosahuje stropu, kolik stat_statements se tam může nashromáždit. A chápu to tak, že s největší pravděpodobností nebylo nic přemístěno.
Ano ano.
Ale nechápu, jak jinak to udělat spolehlivě.
Bohužel si přesně nepamatuji, zda tam používáme text dotazu nebo queryid s pg_stat_statements a zaměřujeme se na něj. Pokud se zaměříme na queryid, pak teoreticky porovnáváme srovnatelné věci.
Ne, může být mezi snímky několikrát vytlačen a přijít znovu.
Se stejným ID?
Ano.
Budeme to studovat. Dobrá otázka. Musíme to nastudovat. Ale zatím to, co vidíme, je buď napsáno 0...
To je samozřejmě vzácný případ, ale byl jsem šokován, když jsem zjistil, že stat_statemetns se tam mohou vytěsnit.
V Pg_stat_statements může být mnoho věcí. Narazili jsme na to, že pokud máte track_utility = on, tak se sledují i vaše sady.
Ano, samozřejmě.
A pokud máte java hibernate, což je náhodné, pak se tam začíná nacházet hashovací tabulka. A jakmile vypnete velmi nabitou aplikaci, skončíte s 50-100 skupinami. A tam je vše víceméně stabilní. Jedním ze způsobů, jak s tím bojovat, je zvýšit pg_stat_statements.max.
Ano, ale musíte vědět kolik. A nějak ho musíme hlídat. To je to co dělám. To znamená, že mám pg_stat_statements.max. A vidím, že v době snímku jsem nedosáhl 70 %. Dobře, takže jsme nic neztratili. Pojďme resetovat. A zase šetříme. Pokud je další snímek menší než 70, pak jste s největší pravděpodobností opět nic neztratili.
Ano. Výchozí hodnota je nyní 5 000. A to mnoha lidem stačí.
Obvykle ano.
Video:
PS Za sebe dodám, že pokud Postgres obsahuje důvěrná data a nelze je zahrnout do testovacího prostředí, můžete použít . Schéma je přibližně následující:
Zdroj: www.habr.com