Heilsuvísir í PostgreSQL með augum Java forritara

Hæ

Ég heiti Vanya og er Java forritari. Það vill svo til að ég vinn mikið með PostgreSQL - að setja upp gagnagrunninn, fínstilla uppbyggingu, frammistöðu og spila smá DBA um helgar.

Nýlega hef ég lagað nokkra gagnagrunna í örþjónustunum okkar og skrifað Java bókasafn bls-vísitala-heilsa, sem auðveldar þessa vinnu, sparar mér tíma og hjálpar mér að forðast algeng mistök sem þróunaraðilar gera. Það er þetta bókasafn sem við munum tala um í dag.

Afneitun ábyrgðar

Aðalútgáfan af PostgreSQL sem ég vinn með er 10. Allar SQL fyrirspurnir sem ég nota eru líka prófaðar á útgáfu 11. Lágmarks studd útgáfa er 9.6.

Forsaga

Þetta byrjaði allt fyrir tæpu ári síðan með aðstæðum sem mér fannst undarlegt: samkeppnisgerð vísitölu upp úr þurru endaði með villu. Vísitalan sjálf, eins og venjulega, var áfram í gagnagrunninum í ógildu ástandi. Loggreining sýndi skort temp_file_limit. Og við förum... Þegar ég kafaði dýpra, uppgötvaði ég fullt af vandamálum í uppsetningu gagnagrunnsins og bretti upp ermarnar og byrjaði að laga þau með glampa í augunum.

Vandamál eitt - sjálfgefna stillingar

Sennilega eru allir frekar þreyttir á samlíkingunni um Postgres, sem hægt er að keyra á kaffivél, en... sjálfgefna uppsetningin vekur í raun ýmsar spurningar. Að minnsta kosti er þess virði að borga eftirtekt til viðhaldsvinnu_mem, temp_file_limit, statement_timeout и lock_timeout.

Í okkar tilviki viðhaldsvinnu_mem var sjálfgefið 64 MB, og temp_file_limit eitthvað í kringum 2 GB - við höfðum einfaldlega ekki nóg minni til að búa til vísitölu á stóru borði.

Þess vegna, í bls-vísitala-heilsa Ég safnaði röð lykill, að mínu mati, færibreyturnar sem ætti að stilla fyrir hvern gagnagrunn.

Vandamál tvö - afrit vísitölur

Gagnagrunnar okkar lifa á SSD drifum og við notum HA-stillingar með mörgum gagnaverum, master host og n-fjöldi eftirlíkinga. Diskapláss er mjög dýrmæt auðlind fyrir okkur; það er ekki síður mikilvægt en frammistaða og örgjörvanotkun. Þess vegna þurfum við annars vegar vísitölur fyrir hraðlestur og hins vegar viljum við ekki sjá óþarfa vísitölur í gagnagrunninum þar sem þær éta upp pláss og hægja á uppfærslu gagna.

Og nú, eftir að hafa endurheimt allt ógildar vísitölur og búinn að sjá nóg skýrslur Oleg Bartunov, ákvað ég að skipuleggja „frábæra“ hreinsun. Það kom í ljós að verktaki líkar ekki við að lesa gagnagrunnsskjöl. Þeim líkar það ekki mjög vel. Vegna þessa koma upp tvær dæmigerðar villur - handvirkt búið til vísitölu á aðallykil og svipað „handvirkt“ vísitala á einstökum dálki. Staðreyndin er sú að þeirra er ekki þörf - Postgres mun gera allt sjálft. Slíkum vísitölum er óhætt að eyða og greiningar hafa birst í þessu skyni duplicated_indexes.

Vandamál þrjú - vísitölur sem skerast

Flestir nýliðar búa til vísitölur á einum dálki. Smám saman, eftir að hafa upplifað þetta fyrirtæki rækilega, byrjar fólk að fínstilla fyrirspurnir sínar og bæta við flóknari vísitölum sem innihalda nokkra dálka. Svona birtast vísitölur á dálkum A, A + B, A+B+C og svo framvegis. Það er óhætt að henda fyrstu tveimur af þessum vísitölum út, þar sem þær eru forskeyti þeirrar þriðju. Þetta sparar líka mikið diskpláss og það eru til greiningar fyrir þetta skornum_vísitölum.

Vandamál fjögur - erlendir lyklar án vísitölu

Postgres gerir þér kleift að búa til erlenda lykilþvingun án þess að tilgreina stuðningsvísitölu. Í mörgum tilfellum er þetta ekki vandamál og kemur kannski ekki einu sinni fram... Í bili...

Það var það sama með okkur: það er bara að á einhverjum tímapunkti byrjaði að „bæta“ við okkur af aðalhýslinum, sem keyrir samkvæmt áætlun og hreinsar gagnagrunninn af prófpöntunum. Örgjörvi og IO fóru til spillis, beiðnir hægðu á sér og voru liðnar út, þjónustan var fimm hundruð. Fljótleg greining pg_stat_activity sýndi að fyrirspurnir eins og:

delete from <table> where id in (…)

Í þessu tilviki var auðvitað vísitala eftir id í marktöflunni og mjög fáum færslum var eytt í samræmi við ástandið. Það virtist sem allt ætti að virka, en því miður, það gerði það ekki.

Hin dásamlega kom til bjargar útskýra greina og sagði að auk þess að eyða skrám í marktöflunni, þá er einnig tilvísunarheilleikaathugun, og á einni af tengdum töflum mistekst þessi athugun raðskönnun vegna skorts á viðeigandi vísitölu. Þannig fæddist greining erlendir_lyklar_án_vísitölu.

Vandamál fimm - núllgildi í vísitölum

Sjálfgefið er að Postgres inniheldur núllgildi í btree vísitölum, en þeirra er venjulega ekki þörf þar. Þess vegna reyni ég af kostgæfni að henda þessum núllum (greiningar vísitölur_með_nullgildum), búa til hlutavísitölur á núllhæfa dálka eftir tegund where <A> is not null. Þannig gat ég minnkað stærð einnar af vísitölum okkar úr 1877 MB í 16 KB. Og í einni af þjónustunum minnkaði stærð gagnagrunnsins samtals um 16% (um 4.3 GB í algildum tölum) vegna útilokunar núllgilda frá vísitölunum. Gífurlegur sparnaður í diskplássi með mjög einföldum breytingum. 🙂

Vandamál sex - skortur á aðallyklum

Vegna eðlis vélbúnaðarins MVCC í Postgres ástand sem þetta er mögulegt uppblásinnþegar stærð borðsins þíns stækkar hratt vegna mikils fjölda dauðra gagna. Ég trúði því barnalega að þetta myndi ekki ógna okkur, og að þetta myndi ekki gerast fyrir herstöðina okkar, því við, vá!!!, erum venjulegir forritarar... Hversu heimskur og barnalegur ég var...

Einn daginn tók einn dásamlegur flutningur og uppfærði allar færslur í stórri og virkan töflu. Við fengum +100 GB í borðstærðina út í bláinn. Það var bölvuð synd, en óförum okkar lauk ekki þar. Eftir að sjálfvirka tómarúminu á þessu borði lauk 15 klukkustundum síðar varð ljóst að staðsetningin myndi ekki skila sér aftur. Við gátum ekki stöðvað þjónustuna og gert VACUUM FULL, svo við ákváðum að nota pg_repack. Og svo kom í ljós að pg_repack veit ekki hvernig á að vinna úr töflum án aðallykils eða annarrar sérstöðutakmörkunar og taflan okkar var ekki með aðallykil. Þannig fæddist greining töflur_án_aðallykils.

Í útgáfu bókasafnsins 0.1.5 Möguleikinn á að safna gögnum úr uppþembu töflur og vísitölur og bregðast við þeim tímanlega hefur verið bætt við.

Vandamál sjö og átta - ófullnægjandi vísitölur og ónotaðar vísitölur

Eftirfarandi tvær greiningar eru: töflur_með_vantar_vísitölum и ónotaðar_vísitölur – birtist í endanlegri mynd tiltölulega nýlega. Málið er að það var ekki bara hægt að taka þá og bæta þeim við.

Eins og ég skrifaði þegar, notum við stillingar með nokkrum eftirmyndum og lestrarálagið á mismunandi vélum er í grundvallaratriðum mismunandi. Fyrir vikið kemur í ljós að sumar töflur og vísitölur á sumum vélum eru nánast ekki notaðar og til greiningar þarf að safna tölfræði frá öllum vélum í klasanum. Endurstilla tölfræði Þetta er líka nauðsynlegt á hvern gestgjafa í þyrpingunni; þú getur ekki gert þetta aðeins á meistaranum.

Þessi aðferð gerði okkur kleift að spara nokkra tugi gígabæta með því að fjarlægja vísitölur sem aldrei voru notaðar, auk þess að bæta vísitölum sem vantar á töflur sem sjaldan eru notaðar.

Sem niðurstaða

Auðvitað, fyrir næstum allar greiningar sem þú getur stillt útilokunarlista. Þannig geturðu fljótt innleitt athuganir í forritinu þínu, komið í veg fyrir að nýjar villur komi upp og lagað síðan smám saman gamlar.

Suma greiningu er hægt að framkvæma í virkniprófum strax eftir að gagnagrunnsflutningar hafa verið settir út. Og þetta er kannski einn af öflugustu eiginleikum bókasafnsins míns. Dæmi um notkun má finna í kynningu.

Það er skynsamlegt að framkvæma athuganir fyrir ónotaðar eða vantar vísitölur, svo og fyrir uppblásinn, aðeins á raunverulegum gagnagrunni. Hægt er að skrá innsöfnuð gildi í smellahús eða send í eftirlitskerfið.

Ég vona það svo sannarlega bls-vísitala-heilsa verður gagnlegt og eftirsótt. Þú getur líka stuðlað að þróun bókasafnsins með því að tilkynna vandamál sem þú finnur og stinga upp á nýjum greiningum.

Heimild: www.habr.com