Nikolai Samokhvaloven "PostgreSQL sintonizatzeko ikuspegi industriala: datu-baseetan esperimentuak" txostenaren transkripzioa irakurtzea gomendatzen dizut.
Shared_buffers = % 25 - asko ala gutxi al da? Edo besterik ez? Nola dakizu gomendio hau - zaharkitua - egokia den zure kasuan?
Bada garaia postgresql.conf parametroak hautatzeko gaiari "heldu bat bezala". Ez "auto-sintonizatzaile" itsuen laguntzarekin edo artikulu eta blogen aholku zaharkituekin, oinarritzat hartuta baizik:
- datu-baseetan zorrozki egiaztatutako esperimentuak, automatikoki eginak, kantitate handietan eta "borrokatzeko" ahalik eta gertuen dauden baldintzetan,
- DBMS eta OSaren ezaugarriak sakon ulertzea.
Nancy CLI erabiliz (), adibide zehatz bat aztertuko dugu - shared_buffers ezagunak - egoera ezberdinetan, proiektu ezberdinetan eta gure azpiegitura, datu-base eta kargarako ezarpen optimoa nola aukeratu asmatzen saiatuko gara.
Datu-baseekin egindako esperimentuei buruz hitz egingo dugu. Sei hilabete pasatxo irauten duen istorioa da.
Niri buruz pixka bat. 14 urte baino gehiagoko esperientzia Postgres-ekin. Hainbat sare sozialen enpresa sortu dira. Postgres nonahi erabiltzen zen eta erabiltzen da.
Baita Meetup-en RuPostgres taldea, munduko 2. postua. Poliki-poliki 2 lagunera hurbiltzen ari gara. RuPostgres.org.
Eta hainbat kongresutako ordenagailuetan, Highload barne, datu-baseen arduraduna naiz, Postgres-en bereziki hasiera-hasieratik.
Eta azken urteotan, hemendik 11 ordu-eremuko Postgres aholkularitza-praktika berrabiarazi dut.
Eta duela urte batzuk hau egin nuenean, eten bat izan nuen Postgres-ekin eskuzko lan aktiboan, ziurrenik 2010etik. Harritu nintzen DBA baten lan errutina zein gutxi aldatu den eta zenbat esku-lan oraindik erabili behar den. Eta berehala pentsatu nuen zerbait gaizki zegoela hemen, dena gehiago automatizatu behar dut.
Eta dena urrun zegoenez, bezero gehienak hodeietan zeuden. Eta dagoeneko asko automatizatu dira, jakina. Honi buruz gehiago. Hau da, honek guztiak tresna batzuk egon behar zirela pentsatu zuen, hau da, DBAren ia ekintza guztiak automatizatuko dituen plataforma motaren bat, datu-base ugari kudeatu ahal izateko.
Txosten honek ez ditu jasoko:
- "Zilarrezko balak" eta adierazpenak - ezarri 8 GB edo % 25 shared_buffers eta ondo egongo zara. Shared_buffers ez da gauza handirik izango.
- Hardcore "barruak".
Zer gertatuko da?
- Aplikatu eta garatzen ditugun optimizazio-printzipioak egongo dira. Bidean sortzen diren era guztietako ideiak eta kode irekian gehienetan sortzen ditugun hainbat tresna izango dira, hau da, oinarria Kode irekian egiten dugu. Gainera, sarrerak ditugu, komunikazio guztia ia Kode Irekia da. Ikus dezakezue orain zertan ari garen, hurrengo bertsioan zer izango den, etab.
- Printzipio horiek, tresna horiek erabiltzeko esperientziaren bat ere izango da hainbat enpresatan: startup txikietatik hasi eta enpresa handietaraino.
Nola garatzen da hau guztia?
Lehenik eta behin, DBA baten zeregin nagusia, instantzien sorrera, babeskopien hedapena, etab. ziurtatzeaz gain, botila-lepoak aurkitzea eta errendimendua optimizatzea da.
Orain honela konfiguratuta dago. Jarraipenari begiratzen diogu, zerbait ikusten dugu, baina xehetasun batzuk falta zaizkigu. Kontu handiagoz zulatzen hasten gara, eskuekin normalean, eta ulertzen zer egin horrekin nola edo hala.
Eta bi ikuspegi daude. Pg_stat_statements kontsulta motelak identifikatzeko irtenbide lehenetsia da. Eta Postgres erregistroen azterketa pgBadger erabiliz.
Planteamendu bakoitzak eragozpen larriak ditu. Lehenengo hurbilpenean, parametro guztiak bota ditugu. Eta SELECT * FROM taldeak ikusten baditugu, zutabea "?" edo "$" Postgres 10etik aurrera. Ez dakigu hau indize-eskaneatze bat den edo seq- eskaneatu bat den. Oso parametroaren araberakoa da. Gutxitan aurkitzen den balio bat ordezkatzen baduzu, indize-eskaera bat izango da. Bertan taularen % 90 hartzen duen balio bat ordezkatzen baduzu, seq eskaneatzea bistakoa izango da, Postgresek estatistikak ezagutzen dituelako. Eta hau pg_stat_statements-en eragozpen handia da, nahiz eta lan batzuk egiten ari diren.
Log-analisiaren desabantailarik handiena "log_min_duration_statement = 0" ezin duzula ordaindu da. Eta honetaz ere hitz egingo dugu. Horren arabera, ez duzu argazki osoa ikusten. Eta kontsulta batzuek, oso azkarrak, baliabide kopuru handia kontsumi dezakete, baina ez duzu ikusiko zure atalasearen azpitik dagoelako.
Nola konpontzen dituzte DBAek aurkitzen dituzten arazoak?
Adibidez, arazoren bat aurkitu dugu. Zer egiten da normalean? Garatzailea bazara, tamaina berekoa ez den kasu batzuetan zerbait egingo duzu. DBA bazara, eszenaratzea duzu. Eta bakarra egon daiteke. Eta sei hilabeteko atzerapena zuen. Eta ekoizpenera joango zarela uste duzu. Eta esperientziadun DBA-ek ere produkzioan egiaztatu, erreplika batean. Eta gertatzen da behin-behineko indize bat sortzen dutela, laguntzen duela ziurtatu, bota eta garatzaileei eman, migrazio fitxategietan sartu ahal izateko. Hau da orain gertatzen ari den zentzugabekeria. Eta hau arazo bat da.
- Sintonizatu konfigurazioak.
- Optimizatu indizeen multzoa.
- Aldatu SQL kontsulta bera (hau da metodorik zailena).
- Gehitu edukiera (modurik errazena kasu gehienetan).
Gauza hauekin asko gertatzen da. Helduleku asko daude Postgres-en. Asko dago jakiteko. Postgresen aurkibide asko daude, jardunaldi honen antolatzaileei ere eskerrak. Eta hori guztia jakin behar da, eta hori da DBA ez direnek DBAk magia beltza praktikatzen ari direla sentiarazten diena. Hau da, 10 urtez ikasi behar da hori guztia normaltasunez ulertzen hasteko.
Eta magia beltz honen aurkako borrokalaria naiz. Dena egin nahi dut teknologia egon dadin, eta honetan guztian ez dago intuiziorik.
Bizitza errealeko adibideak
Gutxienez bi proiektutan ikusi nuen hori, nirea barne. Blogeko beste argitalpen batek esaten digu default_statistict_target-en 1 balio bat ona dela. Ados, proba dezagun ekoizpenean.
Eta hemen gaude, bi urte geroago gure tresna erabiliz, gaur hitz egiten ari garen datu-baseen inguruko esperimentuen laguntzaz, zer zen eta zer bihurtu den alderatu dezakegu.
Eta horretarako esperimentu bat sortu behar dugu. Lau zatiz osatuta dago.
- Lehenengoa ingurumena da. Hardware bat behar dugu. Eta enpresaren batera etortzen naizenean eta kontratu bat sinatzen dudanean, produkzioan dagoen hardware bera emateko esaten diet. Zure maisu bakoitzeko, gutxienez hau bezalako hardware pieza bat behar dut. Edo hau Amazon edo Google-ko makina birtual bat da, edo hardware-pieza bera behar dut. Hau da, ingurunea birsortu nahi dut. Eta ingurunearen kontzeptuan Postgres-en bertsio nagusia sartzen dugu.
- Bigarren zatia da gure ikerketaren xedea. Hau datu-base bat da. Hainbat modutan sor daiteke. Nola erakutsiko dizut.
- Hirugarren zatia karga da. Hau da unerik zailena.
- Eta laugarren zatia egiaztatzen duguna da, hau da, zerekin alderatuko duguna. Demagun konfigurazioan parametro bat edo gehiago alda ditzakegula, edo indize bat sortu dezakegula, etab.
Esperimentu bat martxan jartzen ari gara. Hona hemen pg_stat_statements. Ezkerrean dago gertatutakoa. Eskuinean - zer gertatu zen.
Ezkerrean default_statistics_target = 100, eskuinean = 1. Horrek lagundu zigula ikusten dugu. Orokorrean, dena %000 hobetu zen.
Baina behera korritzen badugu, pgBadger-en edo pg_stat_statements-en eskaera-taldeak egongo dira. Bi aukera daude. Eskaera batzuk %88 jaitsi direla ikusiko dugu. Eta hemen dator ingeniaritza ikuspegia. Barruan gehiago sakondu dezakegu zergatik hondoratu den galdetzen dugulako. Estatistikekin zer gertatu den ulertu behar duzu. Zergatik estatistiketan ontzi gehiagok emaitza okerragoak dakartza.
Edo ezin dugu zulatu, baina egin "ALTER TABLE ... ALTER COLUMN" eta itzuli 100 ontzi zutabe honen estatistiketara. Eta gero beste esperimentu batekin ziurtatu dezakegu adabaki honek lagundu duela. Denak. Ingeniaritza ikuspegi bat da, irudi orokorra ikusten eta intuizioan baino datuetan oinarritutako erabakiak hartzen laguntzen diguna.
Beste arlo batzuetako adibide pare bat. Urte askotan CI probak egon dira probetan. Eta bere onean dagoen proiekturik ez litzateke biziko proba automatikorik gabe.
Beste industria batzuetan: hegazkintzan, automobilgintzan, aerodinamika probatzen dugunean, esperimentuak egiteko aukera ere badugu. Ez dugu marrazki batetik ezer jaurtiko zuzenean espaziora, edo ez dugu berehala auto bat pistara eramango. Adibidez, haize-tunela dago.
Beste industria batzuen behaketetatik ondorioak atera ditzakegu.
Lehenik eta behin, ingurune berezia dugu. Ekoizpenetik gertu dago, baina ez hurbil. Bere ezaugarri nagusia merkea, errepikagarria eta ahalik eta automatizatuena izan behar duela da. Eta analisi zehatza egiteko tresna bereziak ere egon behar dira.
Seguruenik, hegazkina jaurti eta hegan egiten dugunean, haize-tunelean baino aukera gutxiago dugu hegal-azaleraren milimetro bakoitza aztertzeko. Diagnostiko tresna gehiago ditugu. Hegazkin batean airean jarri ezin ditugun gauza astunagoak eraman ditzakegu. Berdin Postgres-ekin. Baliteke, kasu batzuetan, esperimentuetan zehar kontsulta-erregistro osoa gaitzea. Eta ez dugu hau produkzioan egin nahi. Auto_explain erabiliz hau gaitzeko asmoa ere izango dugu.
Eta esan bezala, automatizazio maila altu batek botoia sakatu eta errepikatzen dugula esan nahi du. Horrela izan behar da, esperimentazio asko egon dadin, korrontean egon dadin.
Nancy CLI - "datu-basearen laborategiaren" oinarria
Eta horrela egin genuen gauza hau. Hau da, ideia horiei buruz hitz egin nuen ekainean, duela ia urtebete. Eta dagoeneko badugu Nancy CLI deritzona Open Source-n. Hau da datu base-laborategi bat eraikitzeko oinarria.
β Kode irekian dago, Gitlab-en. Esan dezakezu, proba dezakezu. Esteka bat eman dut diapositibetan. Bertan klik egin dezakezu eta bertan egongo da alderdi guztietan.
Jakina, asko dago oraindik garatzen. Ideia asko daude hor. Baina hau ia egunero erabiltzen dugun zerbait da. Eta ideia bat dugunean - zergatik da 40 lerro ezabatzen ditugunean, dena IO-ra iristen dela, orduan esperimentu bat egin dezakegu eta xehetasun gehiago aztertuko dugu zer gertatzen ari den ulertzeko eta, ondoren, berehala konpontzen saiatzeko. Hau da, esperimentu bat egiten ari gara. Adibidez, zerbait moldatzen dugu eta azkenean zer gertatzen den ikusten dugu. Eta ekoizpenean ez dugu hau egiten. Hau da ideiaren funtsa.
Non funtziona dezake honek? Honek lokalean funtziona dezake, hau da, edonon egin dezakezu, MacBook batean ere exekutatu dezakezu. Docker bat behar dugu, goazen. Hori da dena. Instantziaren batean exekutatu dezakezu hardware pieza batean, edo makina birtualean, edonon.
Eta Amazonen urrunetik exekutatzeko aukera ere badago EC2 Instantzian, lekuetan. Eta hau oso aukera polita da. Esaterako, atzo i500 instantzian 3 esperimentu baino gehiago egin genituen, gazteenetik hasi eta i3-16-xlarge-rekin amaituz. Eta 500 esperimentu 64 dolar kostatu zitzaizkigun. Bakoitzak 15 minutu iraun zuen. Hau da, han spotak erabiltzen direnez, oso merkea da -%70eko deskontua, Amazonen segundoko fakturazioa-. Asko egin dezakezu. Benetako ikerketa egin dezakezu.
Eta Postgres-en hiru bertsio nagusi onartzen dira. Ez da hain zaila antzinako batzuk eta 12. bertsio berria ere amaitzea.
Objektu bat hiru modutan defini dezakegu. Hau:
- Dup/sql fitxategia.
- Modu nagusia PGDATA direktorioa klonatzea da. Oro har, babeskopia zerbitzaritik hartzen da. Babeskopia bitar normalak badituzu, hortik klonak egin ditzakezu. Hodeiak badituzu, Amazon eta Google bezalako hodeiko bulego batek hau egingo dizu. Hau da benetako ekoizpena klonatzeko modurik garrantzitsuena. Horrela garatzen gara.
- Eta azken metodoa ikerketarako egokia da Postgres-en zerbait nola funtzionatzen duen ulertu nahi duzunean. Hau pgbench da. pgbench erabiliz sor dezakezu. "db-pgbench" aukera bakarra da. Esaiozu zer eskala. Eta dena hodeian sortuko da, esan bezala.
Eta kargatu:
- Karga SQL hari batean exekutatu dezakegu. Hau da modurik primitiboena.
- Eta karga emulatu dezakegu. Eta lehenik eta behin ondoko erara emula dezakegu. Erregistro guztiak bildu behar ditugu. Eta mingarria da. Zergatik erakutsiko dizut. Eta pgreplay erabiliz jolasten dugu, hau da, Nancyn eraikia.
- Edo beste aukera bat. Artisau-karga deritzona, esfortzu jakin batekin egiten duguna. Borroka sisteman dugun karga aztertuz, eskaera-talde nagusiak ateratzen ditugu. Eta pgbench erabiliz karga hori emulatu dezakegu laborategian.
- Edo SQL motaren bat egin behar dugu, hau da, nolabaiteko migrazioa egiaztatzen dugu, bertan indize bat sortu, ANALAZE hor exekutatzen dugu. Eta hutsaren aurretik eta hutsaren ondoren gertatutakoa aztertzen dugu. Oro har, edozein SQL.
- Edo konfigurazioan parametro bat edo gehiago aldatzen ditugu. Esan dezakegu, adibidez, Amazon-en 100 balio egiaztatzeko gure terabyte datu-baserako. Eta ordu gutxi barru emaitza izango duzu. Oro har, hainbat ordu beharko dituzu terabyteko datu-base bat zabaltzeko. Baina garatzen ari den adabaki bat dago, serie bat posible dugu, hau da, pgdata berdinak etengabe erabil ditzakezu zerbitzari berean eta egiaztatu. Postgres berrabiaraziko da eta cacheak berrezarri egingo dira. Eta zama gidatu dezakezu.
- Direktorio bat fitxategi ezberdin mordo batekin iristen da, pg argazkietatik hasitastat***. Eta interesgarriena pg_stat_statements, pg_stat_kcacke da. Eskaerak aztertzen dituzten bi luzapen dira. Eta pg_stat_bgwriter-ek pgwriter estatistikak ez ezik, kontrol-puntuan ere baditu eta backendek beraiek buffer zikinak nola desplazatzen dituzten. Eta dena interesgarria da ikustea. Adibidez, shared_buffers konfiguratzen ditugunean, oso interesgarria da ikustea zenbat ordezkatu duten guztiek.
- Postgres erregistroak ere iristen ari dira. Bi erregistro: prestaketa-erregistro bat eta karga-erregistro bat.
- Ezaugarri berri samarra FlameGraphs da.
- Gainera, karga erreproduzitzeko pgreplay edo pgbench aukerak erabili badituzu, haien irteera jatorrizkoa izango da. Eta latentzia eta TPS ikusiko dituzu. Nola ikusi zuten ulertu ahal izango da.
- Sistemaren informazioa.
- Oinarrizko CPU eta IO egiaztapenak. Hau Amazon-eko EC2 instantziarako gehiago da, hari batean 100 instantzia berdin abiarazi eta bertan 100 exekuzio ezberdin exekutatu nahi dituzunean, orduan 10 esperimentu izango dituzu. Eta ziurtatu behar duzu jada norbaitek zapaltzen ari den akatsik gabeko instantziarik topatzen ez duzula. Beste batzuk aktibo daude hardware pieza honetan eta baliabide gutxi geratzen zaizu. Hobe da horrelako emaitzak baztertzea. Eta Alexey Kopytov-en sysbench-en laguntzaz, etorriko diren eta beste batzuekin alderatu daitezkeen hainbat egiaztapen labur egiten ditugu, hau da, CPUak nola jokatzen duen eta IO-ak nola jokatzen duen ulertuko duzu.
Zeintzuk dira enpresa ezberdinen adibidean oinarritutako zailtasun teknikoak?
Demagun benetako karga errepikatu nahi dugula erregistroak erabiliz. Ideia bikaina da Open Source pgreplay-en idatzita badago. Erabiltzen dugu. Baina ondo funtziona dezan, kontsulta-erregistro osoa gaitu behar duzu parametroekin eta denborarekin.
Iraupenarekin eta denbora-zigiluarekin konplikazio batzuk daude. Sukalde hau guztia hustuko dugu. Galdera nagusia da ordaindu dezakezun ala ez?
Arazoa da erabilgarri ez egotea. Lehenik eta behin, ulertu behar duzu zer korronte idatziko den erregistroan. pg_stat_statements badituzu, kontsulta hau erabil dezakezu (esteka eskuragarri egongo da diapositibetan) segundoko zenbat byte idatziko diren gutxi gorabehera ulertzeko.
Eskaeraren luzera begiratzen dugu. Parametrorik ez dagoela alde batera uzten ari gara, baina badakigu eskaeraren iraupena eta badakigu zenbat aldiz exekutatu den segundoko. Horrela kalkulatu dezakegu gutxi gorabehera zenbat byte segundoko. Baliteke akats bat bi aldiz gehiago egitea, baina zalantzarik gabe horrela ulertuko dugu ordena.
Eskaera hau segundoko 802 aldiz exekutatzen dela ikus dezakegu. Eta ikusten dugu bytes_segundoko β 300 kB/s plus edo minus idatziko dela. Eta, oro har, halako fluxu bat ordaindu dezakegu.
Baina! Kontua da erregistro-sistema desberdinak daudela. Eta jendearen lehenetsia "syslog" izan ohi da.
Eta syslog baduzu, baliteke horrelako argazki bat izatea. pgbench hartuko dugu, kontsulta-erregistroa gaitu eta ikusiko dugu zer gertatzen den.
Erregistratu gabe - hau da ezkerreko zutabea. 161 TPS lortu ditugu. Syslog-ekin - hau Ubuntu 000-n dago Amazon-en, 16.04 TPS lortzen dugu. Eta beste bi erregistro-metodotara aldatzen bagara, orduan egoera askoz hobea da. Hau da, jaitsi egingo zela espero genuen, baina ez neurri berean.
Eta CentOS 7-n, zeinetan journald-ek ere parte hartzen duen, erregistroak formatu bitar bihurtuz bilaketa errazetarako, etab., orduan amesgaiztoa da hor, 44 aldiz jaisten dugu TPS-en.
Eta horrekin bizi da jendea. Eta askotan enpresetan, batez ere handietan, hori aldatzea oso zaila da. Syslog-tik urruntzen bazara, mesedez, aldendu bertatik.
- Ebaluatu IOPS eta idatzi fluxua.
- Egiaztatu zure erregistro-sistema.
- Aurreikusitako karga handiegia bada, kontuan hartu laginketa.
pg_stat_statements ditugu. Esan bezala, hor egon behar du. Eta eskaera-talde bakoitza modu berezi batean hartu eta deskriba dezakegu fitxategi batean. Eta gero pgbench-en eginbide oso erosoa erabil dezakegu: "-f" aukera erabiliz hainbat fitxategi txertatzeko gaitasuna da.
"-f" asko ulertzen du. Eta amaieran "@"-ren laguntzaz esan dezakezu zein partekatze izan behar duen fitxategi bakoitzak. Hau da, kasuen %10ean hori egiten dela esan dezakegu, eta %20an hau. Eta horrek ekoizpenean ikusten dugunera hurbilduko gaitu.
Nola ulertuko dugu ekoizpenean duguna? Zer partekatzea eta nola? Hau apur bat alde batera utzita dago. Produktu bat gehiago dugu . Oinarri bat ere Open Source-n. Eta orain aktiboki garatzen ari gara.
Arrazoi apur bat ezberdinengatik jaio zen. Jarraipena nahikoa ez den arrazoiengatik. Hau da, etortzen zara, oinarriari begiratu, dauden arazoei begira. Eta, normalean, osasun_azterketa bat egiten duzu. DBA esperientziaduna bazara, health_check egiten duzu. Indizeen erabilera aztertu dugu, etab. OKmeter baduzu, bikaina. Hau Postgres-en jarraipen bikaina da. OKmeter.io - mesedez instalatu, dena oso ondo dago bertan. Ordaindua da.
Ez baduzu, normalean ez duzu askorik. Monitorizazioan, normalean CPU, IO, eta gero erreserbekin, eta kito. Eta gehiago behar dugu. Autovacuum-ak nola funtzionatzen duen ikusi behar dugu, kontrol-puntuak nola funtzionatzen duen, io-n kontrol-puntua bgwriter-etik eta backendetatik bereizi behar dugu, etab.
Arazoa da enpresa handi bati laguntzen diozunean ezin dutela zerbait azkar inplementatu. Ezin dute azkar erosi OKmeter. Agian sei hilabete barru erosiko dute. Ezin dituzte pakete batzuk azkar entregatu.
Eta ezer instalatu behar ez duen tresna berezi bat behar dugula pentsatu genuen, hau da, ekoizpenean ezer instalatu beharrik ez duzula. Instalatu zure ordenagailu eramangarrian edo exekutatu egingo duzun behaketa zerbitzari batean. Eta gauza asko aztertuko ditu: sistema eragilea, fitxategi sistema eta Postgres bera, produkziora zuzenean exekutatu daitezkeen eta ezerk huts egingo duen kontsulta arin batzuk eginez.
Postgres-checkup deitu genion. Medikuntzari dagokionez, osasun-kontrol arrunta da. Automobilgintzaren gaia bada, mantentzea bezalakoa da. Sei hilean edo urtean behin egiten diozu mantentze-lanak autoari, markaren arabera. Mantentze-lanak egiten al diozu zure baseari? Hau da, ikerketa sakonak egiten dituzu aldian-aldian? Egin behar da. Segurtasun-kopiak egiten badituzu, gero egiaztapen bat egin, hau ez da gutxiagorako.
Eta badugu halako tresna bat. Duela hiru hilabete inguru hasi zen aktiboki sortzen. Gaztea da oraindik, baina asko dago.
Kontsulta talde "eragingarrienak" biltzea - ββsalatu K003 Postgres-checkup-en
Eta txosten talde bat dago K. Orain arte hiru txosten. Eta badago K003 txosten bat. pg_stat_statements-en goiko aldea dago, total_time arabera ordenatuta.
Eskaera taldeak denbora_totalaren arabera ordenatzen ditugunean, goialdean gure sistema gehien kargatzen duen taldea ikusiko dugu, hau da, baliabide gehiago kontsumitzen dituena. Zergatik jartzen diet izena kontsulta-taldeei? Parametroak bota ditugulako. Hauek jada ez dira eskaerak, eskaera-taldeak baizik, hau da, abstrakzioak dira.
Eta goitik behera optimizatzen badugu, gure baliabideak arinduko ditugu eta berritu behar dugun momentua atzeratuko dugu. Hau oso modu ona da dirua aurrezteko.
Agian hau ez da oso modu ona erabiltzaileak zaintzeko, agian ez ditugulako pertsona batek 15 segundo itxaron duen kasu arraroak, baina oso gogaikarriak ikusiko. Guztira, hain dira arraroak, ez ditugu ikusten, baina baliabideekin ari gara.
Zer gertatu da taula honetan? Bi argazki atera genituen. Postgres_checkup-ek delta bat emango dizu metrika bakoitzeko: denbora osoa, deiak, errenkadak, shared_blks_read, etab. Hori da, delta kalkulatu da. pg_stat_statements-en arazo handia da ez duela gogoratzen noiz berrezarri zen. pg_stat_database gogoratzen bada, orduan pg_stat_statements ez da gogoratzen. Ikusten duzu 1ko kopurua dagoela, baina ez dakigu nondik zenbatu garen.
Eta hemen badakigu, hemen ditugu bi argazki. Badakigu kasu honetan delta 56 segundokoa zela. Oso tarte laburra. Total_time arabera ordenatuta. Eta gero bereiz ditzakegu, hau da, metrika guztiak iraupenaren arabera zatitzen ditugu. Neurri bakoitza iraupenaren arabera zatitzen badugu, segundoko dei kopurua izango dugu.
Ondoren, segundoko total_time da nire metrika gogokoena. Segundotan neurtzen da, segundoko, hau da, zenbat segundo behar izan dituen gure sistemak eskaera talde hau segundoko exekutatzeko. Bertan segundoko segundo bat baino gehiago ikusten baduzu, esan nahi du nukleo bat baino gehiago eman behar izan duzula. Hau oso metrika ona da. Uler dezakezu lagun honek, adibidez, gutxienez hiru nukleo behar dituela.
Hau da gure ezagutza, ez dut inoiz horrelakorik ikusi inon. Kontuan izan - oso gauza sinplea da - segundoko segundoko. Batzuetan, zure CPU % 100 denean, orduan ordu erdi segundoko, hau da, ordu erdi ematen zenuen eskaera hauek egiten.
Ondoren, segundoko errenkadak ikusiko ditugu. Badakigu segundoko zenbat errenkada itzuli dituen.
Eta gero gauza interesgarri bat ere badago. Zenbat shared_buffer irakurtzen ditugun segundoko shared_buffers bertatik. Jada hor zeuden arrakastak, eta sistema eragilearen cachetik edo diskotik hartu genituen errenkadak. Lehenengo aukera azkarra da, eta bigarrena azkarra izan daiteke edo ez, egoeraren arabera.
Eta bereizteko bigarren bidea talde honetako eskaera kopurua banatzea da. Bigarren zutabean beti izango duzu kontsulta bana banatuta. Eta gero interesgarria da - zenbat milisegundo zeuden eskaera honetan. Kontsulta honek batez beste nola jokatzen duen badakigu. 101 milisegundo behar ziren eskaera bakoitzeko. Hau da ulertu behar dugun metrika tradizionala.
Zenbat errenkada itzuli ditu batez beste kontsulta bakoitzak? 8 talde hau itzultzen ikusten dugu. Batez beste, cachetik zenbat atera eta irakurri zen. Dena ondo gordeta dagoela ikusten dugu. Arrakasta sendoak lehen taldearentzat.
Eta lerro bakoitzeko laugarren azpikatea guztizkoaren zein ehunekoa da. Deiak ditugu. Demagun 1. Eta talde honek zer ekarpen egiten duen uler dezakegu. Ikusten dugu kasu honetan lehenengo taldeak %000 baino gutxiagoko ekarpena egiten duela. Hau da, hain motela da, ez dugula irudi orokorrean ikusten. Eta bigarren taldea %000ekoa da deietan. Hau da, dei guztien %0,01 bigarren taldea da.
Total_time ere interesgarria da. Gure lan-denboraren % 14 lehen eskaeren taldean eman dugu. Eta bigarrenarentzat -% 11, etab.
Ez naiz xehetasunetan sartuko, baina hor badaude sotiltasunak. Errore bat bistaratzen dugu goiko aldean, izan ere, konparatzen dugunean, instantΓ‘neak flotatzen egon daitezke, hau da, eskaera batzuk erori eta bigarrenean ezin dira egon, eta berri batzuk ager daitezkeen bitartean. Eta hor kalkulatzen dugu errorea. 0 ikusten baduzu, ona da. Ez dago akatsik. Errore-tasa %20rainokoa bada, ondo dago.
Ondoren, gure gaira itzuliko gara. Lan karga landu behar dugu. Goitik behera hartzen dugu eta %80 edo %90era iritsi arte joaten gara. Normalean 10-20 talde izaten dira. Eta pgbench-erako fitxategiak egiten ditugu. Han ausazkoa erabiltzen dugu. Batzuetan honek, zoritxarrez, ez du funtzionatzen. Eta Postgres 12-n aukera gehiago egongo dira ikuspegi hau erabiltzeko.
Eta, ondoren, %80-90 irabazten dugu guztira_denboran horrela. Zer jarri behar dut "@"ren ondoren? Deiak aztertu, zenbat interesa dagoen ikusi eta hemen hainbeste interes zor diogula ulertzen dugu. Ehuneko horietatik abiatuta, fitxategi bakoitza nola orekatu behar den uler dezakegu. Horren ostean pgbench erabiltzen dugu eta lanera goaz.
K001 eta K002 ere baditugu.
K001 lau azpikate dituen kate handi bat da. Hau gure karga osoaren ezaugarri bat da. Ikusi bigarren zutabea eta bigarren azpilerroa. Segundu eta erdi inguru ikusten dugu, hau da, bi nukleo badaude, ona izango da. Gutxi gorabehera %75eko edukiera izango da. Eta horrela funtzionatuko du. 10 nukleo baditugu, orokorrean lasai egongo gara. Horrela baliabideak ebaluatu ahal izango ditugu.
K002 nik kontsulta klaseak deitzen ditudana da, hau da, HAUTATU, TXERTATU, EGUNERATU, EZABATU. Eta bereizita HAUTATU EGUNERATZEKO, sarraila bat delako.
Eta hemen ondorioztatu dezakegu SELECT irakurle arruntak direla - dei guztien % 82, baina aldi berean - % 74 denbora_totalean. Hau da, asko deitzen zaie, baina baliabide gutxiago kontsumitzen dute.
Eta galderara itzultzen gara: "Nola aukera ditzakegu shared_buffers egokiak?" Erreferentzia gehienak ideian oinarritzen direla ikusten dut; ikus dezagun zein izango den errendimendua, hau da, zein izango den. Normalean TPS edo QPSn neurtzen da.
Eta autotik segundoko ahalik eta transakzio gehien ateratzen saiatzen gara sintonizazio parametroak erabiliz. Hona hemen zehatz-mehatz 311 segundoko hautatzeko.
Baina inork ez du lanera eta etxera bueltatzen abiadura osoan. Hau tontoa da. Berdin datu-baseekin. Ez dugu abiadura bizian gidatu behar, eta inork ez du egiten. Inor ez da ekoizpenean bizi, %100eko CPUa duena. Nahiz eta, agian norbait bizi da, baina hau ez da ona.
Ideia da normalean ahalmenaren ehuneko 20an gidatzen dugula, ahal dela % 50 baino gehiagotan. Eta gure erabiltzaileen erantzun-denbora optimizatzen saiatzen gara batez ere. Hau da, gure botoiak piztu behar ditugu, %20ko abiaduran gutxieneko latentzia egon dadin, baldintzatuta. Gure esperimentuetan ere erabiltzen saiatzen garen ideia da.
Eta azkenik, gomendioak:
- Ziurtatu Database Lab egiten duzula.
- Ahal izanez gero, egin eskaeraren arabera pixka bat zabal dadin - jolastu eta bota. Hodeiak badituzu, esan gabe doa, hau da, zutik asko eduki.
- Izan jakin-mina. Eta zerbait gaizki badago, egiaztatu esperimentuekin nola jokatzen duen. Nancy zure burua entrenatzeko erabil daiteke oinarriak nola funtzionatzen duen egiaztatzeko.
- Eta erantzun denbora gutxieneko helburua.
- Eta ez izan Postgres iturrien beldur. Iturriekin lan egiten duzunean, ingelesa jakin behar duzu. Iruzkin asko daude hor, dena azaltzen da.
- Eta egiaztatu datu-basearen osasuna aldizka, gutxienez hiru hilean behin, eskuz edo Postgres-checkup.
Zure galderak
Mila esker! Oso gauza interesgarria.
Bi pieza.
Bai, bi pieza. Nik bakarrik ez nuen ondo ulertu. Nancyk eta biok lan egiten dugunean, parametro bakarra edo talde osoa molda dezakegu?
Delta konfigurazio parametroa dugu. Hara nahi adina buelta dezakezu aldi berean. Baina ulertu behar duzu gauza asko aldatzen dituzunean ondorio okerrak atera ditzakezula.
Bai. Zergatik galdetu nuen? Parametro bakarra duzunean esperimentuak egitea zaila delako. Estutzen duzu, ikusi nola funtzionatzen duen. atera nuen. Ondoren, hurrengoa hasten duzu.
Aldi berean estutu dezakezu, baina egoeraren araberakoa da, noski. Baina hobe da ideia bat probatzea. Ideia bat izan genuen atzo. Egoera oso estua genuen. Bi konfigurazio zeuden. Eta ezin genuen ulertu zergatik zegoen alde handia. Eta ideia sortu zen dikotomia erabili behar dela koherentziaz ulertu eta desberdintasuna zein den aurkitzeko. Berehala egin dezakezu parametroen erdia berdina, gero laurdena, etab. Dena malgua da.
Eta galdera bat gehiago dago. Proiektua gaztea eta garatzen ari da. Dokumentazioa prest dago jada, deskribapen zehatzik al dago?
Berariaz parametroen deskribapenerako esteka bat egin nuen bertan. Hor dago. Baina gauza asko ez daude oraindik. Antzeko jendearen bila nabil. Eta antzezten dudanean aurkitzen ditut. Hau oso polita da. Norbait dagoeneko lanean ari da nirekin, norbaitek lagundu eta zerbait egin zuen bertan. Eta gai hau interesatzen bazaizu, eman iritzia falta denari buruz.
Laborategia eraikitzen dugunean, agian iritzia egongo da. Ikus dezagun. Eskerrik asko!
Kaixo! Eskerrik asko erreportajeagatik! Amazonen laguntza dagoela ikusi nuen. Ba al dago GSP laguntzeko planik?
Galdera ona. Egiten hasi ginen. Eta oraingoz izoztu dugu dirua aurreztu nahi dugulako. Hau da, localhost-en exekutatu erabiltzeko laguntza dago. Zuk zeuk sor dezakezu instantzia bat eta lokalean lan egin. Bide batez, horixe egiten dugu. Nik hau Getlab-en egiten dut, han GSP-n. Baina oraindik ez diogu zentzurik ikusten horrelako orkestrazioa egiteari, Google-k ez baitu leku merkerik. Badago ??? kasuak, baina mugak dituzte. Lehenik eta behin, beti %70eko deskontua besterik ez dute izaten eta ezin duzu han prezioarekin jolastu. Lekuetan, prezioa % 5-10 igotzen dugu, ostiko bat jasateko probabilitatea murrizteko. Hau da, lekuak gordetzen dituzu, baina edozein unetan ken diezazukezu. Besteek baino apur bat gehiago eskaintzen baduzu, geroago hil egingo zara. Google-k zehaztasun guztiz desberdinak ditu. Eta beste muga oso txarra dago: 24 orduz bakarrik bizi dira. Eta batzuetan esperimentu bat egin nahi dugu 5 egunez. Baina hori lekuetan egin dezakezu; lekuek batzuetan hilabete irauten dute.
Kaixo! Eskerrik asko erreportajeagatik! Kontrola aipatu duzu. Nola kalkulatzen dituzu stat_statements erroreak?
Oso galdera ona. Xehetasun handiz erakutsi eta kontatu dezaket. Laburbilduz, eskaera-taldeen multzoa nola mugitu den ikusiko dugu: zenbat erori diren eta zenbat berri agertu. Eta gero bi metrika aztertuko ditugu: denbora_totala eta deiak, beraz, bi akats daude. Eta talde flotatzaileen ekarpenari erreparatzen diogu. Bi azpitalde daude: joan zirenak eta iritsitakoak. Ikus dezagun zein den haien ekarpena irudi orokorrari.
Ez al zara beldurrik argazkien artean bi edo hiru aldiz bueltatuko ote den?
Hau da, berriro izena eman zuten edo zer?
Esate baterako, eskaera hori lehendik behin izan da, gero etorri eta berriro aurrea hartu da, gero berriro etorri eta berriro aurrea hartu da. Eta hemen kalkulatu duzu zerbait, eta non dago dena?
Galdera ona, begiratu beharko dugu.
Antzeko gauza bat egin nuen. Sinpleagoa zen, noski, bakarrik egin nuen. Baina berrezarri behar izan nuen, stat_statements berrezarri eta argazkiaren momentuan zati jakin bat baino gutxiago zegoela irudikatu behar izan nuen, oraindik ez baitzen stat_statements han pila zezakeen sabaira iristen. Eta nire ulermena da, ziurrenik, ezer ez zela lekuz aldatu.
Bai bai.
Baina ez dut ulertzen nola egin fidagarriki bestela.
Zoritxarrez, ez dut zehatz gogoratzen kontsulta testua hor edo queryid pg_stat_statements-ekin erabiltzen dugun eta horretan zentratu. Queryid-en zentratzen bagara, teorian gauza konparagarriak alderatzen ari gara.
Ez, argazkien artean hainbat aldiz kanporatu eta berriro etor daiteke.
Id berdinarekin?
Bai.
Hau aztertuko dugu. Galdera ona. Aztertu behar dugu. Baina oraingoz, ikusten duguna 0 idatzita dago...
Hau, noski, kasu arraroa da, baina harrituta geratu nintzen stat_statemetns-ek hara desplazatu daitezkeela jakin nuenean.
Pg_stat_statements-en gauza asko egon daitezke. Track_utility = aktibatuta baduzu, zure multzoak ere jarraipena egiten direla ikusi dugu.
Bai, jakina.
Eta java hibernate baduzu, ausazkoa dena, hash taula bertan kokatzen hasten da. Eta oso kargatutako aplikazio bat itzali bezain laster, 50-100 talderekin geratzen zara. Eta han dena gutxi gorabehera egonkorra da. Horri aurre egiteko modu bat pg_stat_statements.max handitzea da.
Bai, baina zenbat jakin behar duzu. Eta nolabait hari begira egon behar dugu. Horixe egiten dudana. Hau da, pg_stat_statements.max daukat. Eta ikusten dut argazkiaren momentuan ez nintzela %70era iritsi. Ados, beraz, ez dugu ezer galdu. Berrezarri dezagun. Eta berriro gordetzen dugu. Hurrengo argazkia 70 baino txikiagoa bada, ziurrenik ez duzu berriro ezer galdu.
Bai. Lehenetsia 5 da orain. Eta hori nahikoa da jende askorentzat.
Normalean bai.
Video:
PS Nire izenean, gehituko dut Postgres-ek datu konfidentzialak baditu eta ezin bada proba-ingurunean sartu, orduan erabil dezakezu . Eskema gutxi gorabehera honako hau da:
Iturria: www.habr.com