Us suggereixo que llegiu la transcripció de l'informe de Nikolai Samokhvalov "Enfocament industrial per ajustar PostgreSQL: experiments sobre bases de dades"
Shared_buffers = 25%: és molt o poc? O simplement correcte? Com saps si aquesta recomanació, més aviat obsoleta, és adequada en el teu cas concret?
És hora d'abordar la qüestió de seleccionar els paràmetres postgresql.conf "com un adult". No amb l'ajuda de "sintonitzadors automàtics" cecs o consells obsolets d'articles i blocs, sinó basats en:
- experiments estrictament verificats sobre bases de dades, realitzats automàticament, en grans quantitats i en condicions el més properes possible a les de "combatre",
- comprensió profunda de les característiques del SGBD i el sistema operatiu.
Utilitzant la CLI de Nancy (), veurem un exemple concret, els coneguts shared_buffers, en diferents situacions, en diferents projectes i intentarem esbrinar com triar la configuració òptima per a la nostra infraestructura, base de dades i càrrega.
Parlarem d'experiments amb bases de dades. Aquesta és una història que dura una mica més de sis mesos.
Una mica sobre mi. Experiència amb Postgres durant més de 14 anys. S'han fundat diverses empreses de xarxes socials. Postgres va ser i s'utilitza a tot arreu.
També el grup RuPostgres a Meetup, 2n lloc del món. Poc a poc ens acostem a les 2 persones. RuPostgres.org.
I als ordinadors de diverses conferències, inclosa Highload, sóc responsable de les bases de dades, en particular de Postgres des del principi.
I en els últims anys, he reiniciat la meva pràctica de consultoria Postgres a 11 zones horàries des d'aquí.
I quan ho vaig fer fa uns anys, vaig tenir una pausa en el treball manual actiu amb Postgres, probablement des del 2010. Em va sorprendre el poc que ha canviat la rutina de treball d'un DBA i quanta mà d'obra encara s'ha d'utilitzar. I de seguida vaig pensar que hi havia alguna cosa malament aquí, necessito automatitzar més de tot.
I com que tot era remot, la majoria dels clients estaven als núvols. I molt ja s'han automatitzat, evidentment. Més sobre això més endavant. És a dir, tot plegat va donar lloc a la idea que hi hauria d'haver una sèrie d'eines, és a dir, algun tipus de plataforma que automatitzés quasi totes les accions DBA per poder gestionar un gran nombre de bases de dades.
Aquest informe no inclourà:
- "Baletes de plata" i declaracions com: establiu 8 GB o 25% de shared_buffers i anirà bé. No hi haurà gaire cosa sobre shared_buffers.
- "Innards" hardcore.
Què passarà?
- Hi haurà principis d'optimització que apliquem i desenvolupem. Hi haurà tot tipus d'idees que sorgiran al llarg del camí i diverses eines que creem majoritàriament en codi obert, és a dir, fem la base en codi obert. A més, tenim entrades, tota la comunicació és pràcticament de codi obert. Podeu veure què estem fent ara, què hi haurà a la propera versió, etc.
- També hi haurà experiència en l'ús d'aquests principis, aquestes eines en diverses empreses: des de petites startups fins a grans empreses.
Com es desenvolupa tot això?
En primer lloc, la tasca principal d'un DBA, a més de garantir la creació d'instàncies, el desplegament de còpies de seguretat, etc., és trobar colls d'ampolla i optimitzar el rendiment.
Ara està configurat així. Mirem el seguiment, veiem alguna cosa, però ens falten alguns detalls. Comencem a cavar amb més cura, normalment amb les mans, i entenem què fer-ne d'una manera o d'una altra.
I hi ha dos enfocaments. Pg_stat_statements és la solució predeterminada per identificar consultes lentes. I anàlisi dels registres de Postgres mitjançant pgBadger.
Cada enfocament té greus inconvenients. En el primer enfocament, hem llençat tots els paràmetres. I si veiem els grups SELECT * FROM taula on la columna és igual al "?" o "$" des de Postgres 10. No sabem si es tracta d'una exploració d'índex o una exploració seq. Depèn molt del paràmetre. Si substituïu un valor que no es trobeu allà, serà una exploració d'índex. Si substituïu un valor que ocupa el 90% de la taula allà, l'exploració seq. serà evident, perquè Postgres coneix les estadístiques. I aquest és un gran inconvenient de pg_stat_statements, tot i que s'està treballant.
El major desavantatge de l'anàlisi de registres és que no us podeu permetre "log_min_duration_statement = 0" per regla general. I d'això també en parlarem. En conseqüència, no veus tota la imatge. I alguna consulta, que és molt ràpida, pot consumir una gran quantitat de recursos, però no la veuràs perquè està per sota del teu llindar.
Com solucionen els DBA els problemes que troben?
Per exemple, hem trobat algun problema. Què es fa habitualment? Si sou un desenvolupador, fareu alguna cosa en algun cas que no tingui la mateixa mida. Si ets DBA, tens posada en escena. I només n'hi pot haver un. I es va endarrerir sis mesos. I penses que aniràs a la producció. I fins i tot DBA experimentats després registren la producció, en una rèplica. I passa que creen un índex temporal, s'asseguren que ajuda, el deixen anar i el donen als desenvolupadors perquè el posin als fitxers de migració. Aquest és el tipus de tonteria que està passant ara. I això és un problema.
- Sintonitza les configuracions.
- Optimitzar el conjunt d'índexs.
- Canvieu la consulta SQL en si (aquesta és la manera més difícil).
- Afegiu capacitat (la manera més senzilla en la majoria dels casos).
Passen moltes coses amb aquestes coses. Hi ha moltes manetes a Postgres. Hi ha molt per saber. Hi ha molts índexs a Postgres, gràcies també als organitzadors d'aquesta jornada. I tot això s'ha de saber, i això és el que fa que els que no són DBA se sentin que els DBA estan practicant màgia negra. És a dir, cal estudiar durant 10 anys per començar a entendre tot això amb normalitat.
I sóc un lluitador contra aquesta màgia negra. Vull fer-ho tot perquè hi hagi tecnologia, i no hi hagi intuïció en tot això.
Exemples de la vida real
Vaig observar això en almenys dos projectes, inclòs el meu. Una altra entrada al bloc ens diu que un valor de 1 per default_statistict_target és bo. D'acord, provem-ho en producció.
I aquí estem, fent servir la nostra eina dos anys més tard, amb l'ajuda d'experiments sobre les bases de dades de les que parlem avui, podem comparar què va ser i què s'ha convertit.
I per això hem de crear un experiment. Consta de quatre parts.
- El primer és el medi ambient. Necessitem una peça de maquinari. I quan vinc a alguna empresa i firmo un contracte, els dic que em donin el mateix maquinari que en producció. Per a cadascun dels vostres mestres, necessito almenys una peça de maquinari com aquesta. O bé es tracta d'una màquina virtual d'instància a Amazon o Google, o necessito exactament la mateixa peça de maquinari. És a dir, vull recrear l'entorn. I en el concepte d'entorn incloem la versió principal de Postgres.
- La segona part és l'objecte de la nostra recerca. Aquesta és una base de dades. Es pot crear de diverses maneres. Et mostraré com.
- La tercera part és la càrrega. Aquest és el moment més difícil.
- I la quarta part és què comprovem, és a dir, què compararem amb què. Suposem que podem canviar un o més paràmetres a la configuració, o podem crear un índex, etc.
Estem posant en marxa un experiment. Aquí teniu pg_stat_statements. A l'esquerra hi ha el que va passar. A la dreta, què va passar.
A l'esquerra default_statistics_target = 100, a la dreta = 1. Veiem que això ens va ajudar. En general, tot va millorar en un 000%.
Però si ens desplacem cap avall, hi haurà grups de peticions de pgBadger o de pg_stat_statements. Hi ha dues opcions. Veurem que alguna petició ha baixat un 88%. I aquí ve l'enfocament d'enginyeria. Podem cavar més dins perquè ens preguntem per què s'ha enfonsat. Cal entendre què va passar amb les estadístiques. Per què més cubs a les estadístiques condueixen a pitjors resultats.
O no podem excavar, però fem "ALTERA LA TAULA... ALTERA LA COLUMNA" i tornem 100 cubs a les estadístiques d'aquesta columna. I després amb un altre experiment ens podem assegurar que aquest pegat ha ajudat. Tots. Aquest és un enfocament d'enginyeria que ens ajuda a veure el panorama general i prendre decisions basant-se en dades més que en la intuïció.
Un parell d'exemples d'altres àmbits. Hi ha proves de CI durant molts anys. I cap projecte en el seu bon judici viuria sense proves automatitzades.
En altres indústries: a l'aviació, a l'automoció, quan posem a prova l'aerodinàmica, també tenim l'oportunitat de fer experiments. No llançarem res d'un dibuix directament a l'espai, o no agafarem un cotxe immediatament a la pista. Per exemple, hi ha un túnel de vent.
Podem extreure conclusions d'observacions d'altres indústries.
En primer lloc, tenim un entorn especial. Està a prop de la producció, però no a prop. La seva característica principal és que ha de ser barat, repetible i el més automatitzat possible. I també hi ha d'haver eines especials per dur a terme una anàlisi detallada.
El més probable és que quan llencem un avió i volem, tinguem menys oportunitats d'estudiar cada mil·límetre de la superfície de l'ala que les que tenim en un túnel de vent. Tenim més eines de diagnòstic. Ens podem permetre el luxe de portar més coses pesades que no ens podem permetre posar en un avió a l'aire. El mateix amb Postgres. En alguns casos, podem habilitar el registre complet de consultes durant els experiments. I no volem fer-ho en producció. Fins i tot podem planejar habilitar-ho mitjançant auto_explain.
I com he dit, un alt nivell d'automatització fa que premem el botó i repetim. Així ha de ser, perquè hi hagi molta experimentació, perquè estigui en marxa.
Nancy CLI - la base del "laboratori de bases de dades"
I així vam fer això. És a dir, vaig parlar d'aquestes idees al juny, fa quasi un any. I ja tenim l'anomenada Nancy CLI en codi obert. Aquesta és la base per construir un laboratori de bases de dades.
— Està en codi obert, a Gitlab. Ho pots dir, pots provar-ho. He proporcionat un enllaç a les diapositives. Podeu fer-hi clic i hi estarà en tots els aspectes.
Per descomptat, encara hi ha moltes coses en desenvolupament. Hi ha moltes idees allà. Però això és una cosa que fem servir gairebé cada dia. I quan tenim una idea: per què quan suprimim 40 de línies, tot es redueix a IO, podem fer un experiment i mirar amb més detall per entendre què està passant i després intentar arreglar-ho sobre la marxa. És a dir, estem fent un experiment. Per exemple, retoquem alguna cosa i veiem què passa al final. I això no ho fem en producció. Aquesta és l'essència de la idea.
On pot funcionar això? Això pot funcionar localment, és a dir, ho podeu fer a qualsevol lloc, fins i tot podeu executar-lo en un MacBook. Necessitem un docker, anem. Això és tot. Podeu executar-lo en algun cas en una peça de maquinari, o en una màquina virtual, a qualsevol lloc.
I també hi ha l'oportunitat d'executar-se de forma remota a Amazon a la instància EC2, en punts. I aquesta és una oportunitat molt maca. Per exemple, ahir vam realitzar més de 500 experiments amb la instància i3, començant pel més jove i acabant amb i3-16-xlarge. I 500 experiments ens van costar 64 dòlars. Cada un va durar 15 minuts. És a dir, pel fet que s'hi fan servir els spots, és molt barat: un descompte del 70%, la facturació per segon d'Amazon. Pots fer moltes coses. Pots fer una investigació real.
I s'admeten tres versions principals de Postgres. No és tan difícil acabar-ne alguns antics i també la nova 12a versió.
Podem definir un objecte de tres maneres. Això:
- Abocament/arxiu sql.
- La manera principal és clonar el directori PGDATA. Per regla general, es pren del servidor de còpia de seguretat. Si teniu còpies de seguretat binàries normals, podeu fer clons des d'allà. Si teniu núvols, una oficina al núvol com Amazon i Google ho farà per vosaltres. Aquesta és la manera més important de clonar la producció real. Així és com ens desenvolupem.
- I l'últim mètode és adequat per a la investigació quan voleu entendre com funciona alguna cosa a Postgres. Això és pgbench. Podeu generar utilitzant pgbench. És només una opció "db-pgbench". Digues-li quina escala. I tot es generarà al núvol, com s'ha dit.
I carregar:
- Podem executar la càrrega en un fil SQL. Aquesta és la manera més primitiva.
- I podem emular la càrrega. I podem emular-ho primer de tot de la següent manera. Hem de recollir tots els registres. I és dolorós. Et mostraré per què. I amb pgreplay juguem, que està integrat a Nancy.
- O una altra opció. L'anomenada càrrega d'artesania, que fem amb un cert esforç. Analitzant la nostra càrrega actual del sistema de combat, traiem els principals grups de sol·licituds. I amb pgbench podem emular aquesta càrrega al laboratori.
- O hem de realitzar algun tipus d'SQL, és a dir, comprovem algun tipus de migració, hi creem un índex, hi executem ANALAZE. I mirem què va passar abans del buit i després del buit. En general, qualsevol SQL.
- O canviem un o més paràmetres a la configuració. Podem dir-nos que comprovem, per exemple, 100 valors a Amazon per a la nostra base de dades de terabytes. I en poques hores tindreu el resultat. Per regla general, trigarà diverses hores a desplegar una base de dades de terabytes. Però hi ha un pedaç en desenvolupament, tenim una sèrie possible, és a dir, podeu utilitzar constantment la mateixa pgdata al mateix servidor i comprovar-ho. Postgres es reiniciarà i les memòries cau es restabliran. I pots conduir la càrrega.
- Arriba un directori amb un munt de fitxers diferents, començant per instantànies pgstat***. I el més interessant és pg_stat_statements, pg_stat_kcacke. Són dues extensions que analitzen les sol·licituds. I pg_stat_bgwriter no només conté estadístiques de pgwriter, sinó també sobre el punt de control i com els mateixos backends desplacen els buffers bruts. I tot és interessant de veure. Per exemple, quan configurem shared_buffers, és molt interessant veure quant ha substituït tothom.
- També arriben els registres de Postgres. Dos registres: un registre de preparació i un registre de reproducció de càrrega.
- Una característica relativament nova és FlameGraphs.
- A més, si heu utilitzat les opcions pgreplay o pgbench per reproduir la càrrega, la seva sortida serà nativa. I veureu latència i TPS. Serà possible entendre com ho van veure.
- Informació del sistema.
- Comprovacions bàsiques de CPU i E/S. Això és més per a la instància EC2 a Amazon, quan voleu llançar 100 instàncies idèntiques en un fil i executar-hi 100 execucions diferents, tindreu 10 experiments. I heu d'assegurar-vos que no us trobeu amb una instància defectuosa que ja està sent oprimida per algú. Altres estan actius en aquesta peça de maquinari i us queden pocs recursos. És millor descartar aquests resultats. I amb l'ajuda de sysbench d'Alexey Kopytov, fem diverses comprovacions breus que vindran i es poden comparar amb altres, és a dir, entendreu com es comporta la CPU i com es comporta l'IO.
Quines són les dificultats tècniques a partir de l'exemple de diferents empreses?
Suposem que volem repetir la càrrega real utilitzant registres. És una gran idea si està escrit a pgreplay de codi obert. El fem servir. Però perquè funcioni bé, heu d'habilitar el registre complet de consultes amb paràmetres i temps.
Hi ha algunes complicacions amb la durada i la marca de temps. Buidarem tota aquesta cuina. La pregunta principal és si t'ho pots permetre o no?
El problema és que pot ser que no estigui disponible. En primer lloc, heu d'entendre quin flux s'escriurà al registre. Si teniu pg_stat_statements, podeu utilitzar aquesta consulta (l'enllaç estarà disponible a les diapositives) per entendre aproximadament quants bytes s'escriuran per segon.
Mirem la durada de la sol·licitud. Descuidem el fet que no hi ha paràmetres, però sabem la durada de la sol·licitud i sabem quantes vegades per segon s'ha executat. D'aquesta manera podem estimar aproximadament quants bytes per segon. És possible que ens equivoquem el doble, però segur que entendrem l'ordre d'aquesta manera.
Podem veure que 802 vegades per segon s'executa aquesta sol·licitud. I veiem que bytes_per sec – 300 kB/s s'escriuran més o menys. I, per regla general, ens podem permetre aquest flux.
Però! El fet és que hi ha diferents sistemes de registre. I el valor predeterminat de la gent sol ser "syslog".
I si teniu syslog, potser tingueu una imatge com aquesta. Prenem pgbench, activarem el registre de consultes i veurem què passa.
Sense registrar - aquesta és la columna de l'esquerra. Tenim 161 TPS. Amb syslog: això és a Ubuntu 000 a Amazon, obtenim 16.04 TPS. I si canviem a altres dos mètodes de registre, la situació és molt millor. És a dir, esperàvem que baixés, però no en la mateixa mesura.
I a CentOS 7, en el qual també participa journald, convertint els registres en un format binari per a una cerca fàcil, etc., aleshores és un malson, caiem 44 vegades en TPS.
I això és el que viu la gent. I sovint a les empreses, especialment a les grans, això és molt difícil de canviar. Si podeu allunyar-vos de Syslog, si us plau, allunyeu-vos-ne.
- Avalueu l'IOPS i el flux d'escriptura.
- Comproveu el vostre sistema de registre.
- Si la càrrega projectada és excessivament gran, considereu el mostreig.
Tenim pg_stat_statements. Com he dit, deu ser-hi. I podem agafar i descriure cada grup de peticions d'una manera especial en un fitxer. I llavors podem utilitzar una característica molt convenient a pgbench: aquesta és la possibilitat d'inserir diversos fitxers mitjançant l'opció "-f".
Entén molt de "-f". I podeu dir amb l'ajuda de "@" al final quina ha de compartir cada fitxer. És a dir, podem dir que ho fan en un 10% dels casos, i això en un 20%. I això ens acostarà al que veiem a la producció.
Com entendrem el que tenim en producció? Quina participació i com? Això és una mica a part. Tenim un producte més . També una base en codi obert. I ara l'estem desenvolupant activament.
Va néixer per raons una mica diferents. Per raons que el seguiment no és suficient. És a dir, vens, mira la base, mira els problemes que hi ha. I, per regla general, feu un control de salut. Si sou un DBA experimentat, feu un control de salut. Hem analitzat l'ús d'índexs, etc. Si teniu OKmeter, genial. Aquest és un seguiment fantàstic per a Postgres. OKmeter.io: si us plau, instal·leu-lo, tot està fet molt bé allà. Es paga.
Si no en tens, normalment no en tens gaire. En el seguiment, normalment hi ha CPU, IO i després amb reserves, i això és tot. I en necessitem més. Hem de veure com funciona l'autovacuum, com funciona el punt de control, a io hem de separar el punt de control del bgwriter i dels backends, etc.
El problema és que quan ajudes a una gran empresa, no poden implementar alguna cosa ràpidament. No poden comprar ràpidament OKmeter. Potser el compraran en sis mesos. No poden lliurar ràpidament alguns paquets.
I ens va ocórrer la idea que necessitem una eina especial que no requereix instal·lar res, és a dir, no cal que instal·leu res en producció. Instal·leu-lo al vostre ordinador portàtil o en un servidor d'observació des d'on l'executareu. I analitzarà moltes coses: el sistema operatiu, el sistema de fitxers i el mateix Postgres, fent algunes consultes lleugeres que es poden executar directament a la producció i res fallarà.
L'hem anomenat Postgres-checkup. En termes mèdics, es tracta d'un control de salut regular. Si és de temàtica d'automoció, és com el manteniment. Fas el manteniment del teu cotxe cada sis mesos o un any, segons la marca. Fas manteniment de la teva base? És a dir, feu una investigació profunda regularment? S'ha de fer. Si feu còpies de seguretat i després feu una revisió, això no és menys important.
I tenim una eina així. Va començar a sorgir activament fa només uns tres mesos. Encara és jove, però hi ha moltes coses.
Recollida dels grups de consultes més "influents": informe K003 a Postgres-checkup
I hi ha un grup d'informes K. Tres informes fins ara. I hi ha aquest informe K003. Hi ha la part superior de pg_stat_statements, ordenada per total_time.
Quan ordenem els grups de sol·licituds per total_time, a la part superior veiem el grup que carrega més el nostre sistema, és a dir, consumeix més recursos. Per què dono un nom als grups de consultes? Perquè hem llençat els paràmetres. Ja no són peticions, sinó grups de peticions, és a dir, que s'abstracten.
I si optimitzem de dalt a baix, alleugerirem els nostres recursos i retardarem el moment en què necessitem actualitzar. Aquesta és una molt bona manera d'estalviar diners.
Potser aquesta no és una molt bona manera de tenir cura dels usuaris, perquè potser no veiem casos rars, però molt molests, en què una persona va esperar 15 segons. En total, són tan rars que no els veiem, però estem tractant amb recursos.
Què ha passat en aquesta taula? Hem fet dues instantànies. Postgres_checkup us donarà un delta per a cada mètrica: temps total, trucades, files, shared_blks_read, etc. Això és tot, el delta s'ha calculat. El gran problema amb pg_stat_statements és que no recorda quan es va restablir. Si pg_stat_database ho recorda, pg_stat_statements no ho recorda. Veus que hi ha un nombre de 1, però no sabem d'on hem comptat.
I aquí ho sabem, aquí tenim dues instantànies. Sabem que el delta en aquest cas era de 56 segons. Una bretxa molt curta. Ordenat per total_time. I després podem diferenciar, és a dir, dividim totes les mètriques per durada. Si dividim cada mètrica per la durada, tindrem el nombre de trucades per segon.
A continuació, total_time per segon és la meva mètrica preferida. Es mesura en segons, per segon, és a dir, quants segons ha trigat el nostre sistema a executar aquest grup de peticions per segon. Si hi veus més d'un segon per segon, vol dir que has de donar més d'un nucli. Aquesta és una molt bona mètrica. Pots entendre que aquest amic, per exemple, necessita almenys tres nuclis.
Aquest és el nostre saber fer, mai he vist res semblant enlloc. Si us plau, tingueu en compte que això és una cosa molt senzilla segons per segon. De vegades, quan la vostra CPU és al 100%, després mitja hora per segon, és a dir, heu passat mitja hora fent només aquestes sol·licituds.
A continuació, veiem files per segon. Sabem quantes files per segon ha tornat.
I després també hi ha una cosa interessant. Quants shared_buffers llegim per segon del mateix shared_buffers. Les visites ja hi eren, i vam agafar les files de la memòria cau del sistema operatiu o del disc. La primera opció és ràpida, i la segona pot ser ràpida o no, segons la situació.
I la segona manera de diferenciar és dividir el nombre de peticions d'aquest grup. A la segona columna sempre tindreu una consulta dividida per consulta. I aleshores és interessant: quants mil·lisegons hi havia en aquesta sol·licitud. Sabem com es comporta aquesta consulta de mitjana. Es van requerir 101 mil·lisegons per a cada sol·licitud. Aquesta és la mètrica tradicional que hem d'entendre.
Quantes files ha retornat cada consulta de mitjana? Veiem 8 que aquest grup torna. De mitjana, quant es va treure de la memòria cau i es va llegir. Veiem que tot està ben guardat a la memòria cau. Encerts sòlids per al primer grup.
I la quarta subcadena de cada línia és quin percentatge del total. Tenim trucades. Diguem 1. I podem entendre quina aportació fa aquest grup. Veiem que en aquest cas el primer grup aporta menys del 000%. És a dir, és tan lent que no ho veiem en el panorama general. I el segon grup és del 000% a les trucades. És a dir, el 0,01% de totes les trucades són del segon grup.
Total_time també és interessant. Hem dedicat el 14% del nostre temps de treball total al primer grup de sol·licituds. I per al segon - 11%, etc.
No entraré en detalls, però hi ha subtileses. Mostrem un error a la part superior, perquè quan comparem, les instantànies poden flotar, és a dir, algunes sol·licituds poden caure i ja no poden estar presents a la segona, mentre que poden aparèixer algunes de noves. I allà calculem l'error. Si veus 0, està bé. No hi ha errors. Si la taxa d'error és de fins al 20%, està bé.
Després tornem al nostre tema. Hem d'elaborar la càrrega de treball. Ho agafem de dalt a baix i anem fins arribar al 80% o al 90%. Normalment són 10-20 grups. I fem fitxers per a pgbench. Allà fem servir l'atzar. De vegades això, malauradament, no funciona. I a Postgres 12 hi haurà més oportunitats d'utilitzar aquest enfocament.
I després guanyem un 80-90% en total_time d'aquesta manera. Què he de posar després de "@"? Mirem les trucades, mirem quant d'interès hi ha i entenem que aquí ens devem tant d'interès. A partir d'aquests percentatges podem entendre com equilibrar cadascun dels fitxers. Després fem servir pgbench i anem a treballar.
També tenim K001 i K002.
K001 és una gran cadena amb quatre subcadenes. Aquesta és una característica de tota la nostra càrrega. Vegeu la segona columna i la segona subfila. Veiem que aproximadament un segon i mig per segon, és a dir, si hi ha dos nuclis, serà bo. Hi haurà aproximadament un 75% de l'aforament. I funcionarà així. Si tenim 10 nuclis, en general estarem tranquils. D'aquesta manera podem avaluar els recursos.
K002 és el que anomeno classes de consulta, és a dir, SELECT, INSERT, UPDATE, DELETE. I per separat SELECT FOR UPDATE, perquè és un pany.
I aquí podem concloure que SELECT són lectors normals: el 82% de totes les trucades, però al mateix temps, el 74% en total_time. És a dir, es diuen molt, però consumeixen menys recursos.
I tornem a la pregunta: "Com podem triar els shared_buffers adequats?" Observo que la majoria dels punts de referència es basen en la idea: vegem quin serà el rendiment, és a dir, quin serà el rendiment. Normalment es mesura en TPS o QPS.
I intentem extreure tantes transaccions per segon com sigui possible del cotxe mitjançant paràmetres d'ajust. Aquí hi ha exactament 311 per segon per seleccionar.
Però ningú condueix a la feina i torna a casa a tota velocitat. Això és ximple. El mateix amb les bases de dades. No hem de conduir a tota velocitat, i ningú ho fa. Ningú viu a la producció, que té una CPU al 100%. Encara que, potser algú viu, però això no és bo.
La idea és que normalment conduïm al 20% de la capacitat, preferiblement no més del 50%. I intentem optimitzar el temps de resposta dels nostres usuaris sobretot. És a dir, hem de girar els nostres poms perquè hi hagi una latència mínima al 20% de velocitat, condicionalment. Aquesta és una idea que també intentem utilitzar en els nostres experiments.
I finalment, recomanacions:
- Assegureu-vos de fer Database Lab.
- Si és possible, fes-ho sota demanda perquè es desenvolupi una estona: juga i llença-ho. Si teniu núvols, això no cal dir-ho, és a dir, teniu molt de peu.
- Sigues curiós. I si alguna cosa no funciona, comproveu amb experiments com es comporta. Nancy es pot utilitzar per entrenar-se per comprovar com funciona la base.
- I apuntar al mínim temps de resposta.
- I no tingueu por de les fonts de Postgres. Quan treballeu amb fonts, heu de saber anglès. Hi ha molts comentaris, allà s'explica tot.
- I comproveu l'estat de la base de dades amb regularitat, almenys una vegada cada tres mesos, manualment o Postgres-checkup.
Les vostres preguntes
Moltes gràcies! Una cosa molt interessant.
Dues peces.
Sí, dues peces. Només jo no ho vaig entendre bé. Quan la Nancy i jo treballem, podem modificar només un paràmetre o tot un grup?
Tenim un paràmetre de configuració delta. Hi pots girar tant com vulguis alhora. Però cal entendre que quan canvies moltes coses, pots treure conclusions equivocades.
Sí. Per què vaig preguntar? Perquè és difícil fer experiments quan només tens un paràmetre. Apreta-ho, veuràs com funciona. El vaig fer fora. Llavors comences el següent.
Podeu estrènyer-lo al mateix temps, però depèn de la situació, és clar. Però és millor provar una idea. Ahir vam tenir una idea. Vam tenir una situació molt propera. Hi havia dues configuracions. I no podíem entendre per què hi havia una gran diferència. I va sorgir la idea que cal utilitzar la dicotomia per entendre i trobar constantment quina és la diferència. Immediatament podeu fer que la meitat dels paràmetres siguin iguals, després una quarta part, etc. Tot és flexible.
I hi ha una pregunta més. El projecte és jove i en desenvolupament. La documentació ja està preparada, hi ha una descripció detallada?
Concretament hi vaig fer un enllaç a la descripció dels paràmetres. És allà. Però moltes coses encara no hi són. Busco gent amb idees afins. I els trobo quan actuo. Això és molt xulo. Algú ja treballa amb mi, algú m'ha ajudat i hi ha fet alguna cosa. I si esteu interessats en aquest tema, doneu comentaris sobre el que falta.
Un cop construïm el laboratori, potser hi haurà retroalimentació. A veure. Gràcies!
Hola! Gràcies pel reportatge! Vaig veure que hi ha suport d'Amazon. Hi ha plans per donar suport a GSP?
Bona pregunta. Vam començar a fer-ho. I de moment ho hem congelat perquè volem estalviar diners. És a dir, hi ha suport per utilitzar run on localhost. Podeu crear una instància vosaltres mateixos i treballar localment. Per cert, això és el que fem. Ho faig a Getlab, allà a GSP. Però encara no veiem el sentit de fer aquesta orquestració, perquè Google no té llocs barats. Hi ha??? casos, però tenen limitacions. En primer lloc, sempre només tenen un 70% de descompte i no hi pots jugar amb el preu. En els punts, augmentem el preu entre un 5 i un 10% per reduir la probabilitat que us expulsin. És a dir, estalvies taques, però te'ls poden treure en qualsevol moment. Si fas una oferta una mica més alta que els altres, et mataran més tard. Google té especificitats completament diferents. I hi ha una altra limitació molt dolenta: només viuen 24 hores. I de vegades volem fer un experiment durant 5 dies. Però podeu fer-ho en punts; de vegades les taques duren mesos.
Hola! Gràcies pel reportatge! Has mencionat la revisió. Com calculeu els errors de stat_statements?
Molt bona pregunta. Puc mostrar-te i explicar-te amb gran detall. En resum, observem com ha flotat el conjunt de grups de sol·licitud: quants han caigut i quants n'han aparegut de nous. I després mirem dues mètriques: total_time i trucades, de manera que hi ha dos errors. I ens fixem en l'aportació dels grups flotants. Hi ha dos subgrups: els que van marxar i els que van arribar. Vegem quina és la seva contribució al panorama general.
No teniu por que hi torni dues o tres vegades durant el temps entre instantànies?
És a dir, es van tornar a registrar o què?
Per exemple, aquesta sol·licitud ja s'ha preempat una vegada, després va venir i es va avançar una altra vegada, després va tornar a venir i es va avançar de nou. I vas calcular alguna cosa aquí, i on és tot?
Bona pregunta, haurem de mirar.
Vaig fer una cosa semblant. Era més senzill, és clar, ho vaig fer sol. Però vaig haver de restablir, restablir stat_statements i esbrinar en el moment de la instantània que hi havia menys d'una determinada fracció, que encara no arribava al sostre de quant stat_statements s'hi podia acumular. I el meu entendre és que, molt probablement, no es va desplaçar res.
Sí sí.
Però no entenc com fer-ho de manera fiable.
Malauradament, no recordo exactament si fem servir el text de la consulta o queryid amb pg_stat_statements i ens hi centrem. Si ens centrem en queryid, en teoria estem comparant coses comparables.
No, es pot forçar a sortir diverses vegades entre instantànies i tornar-hi.
Amb el mateix identificador?
Sí
Això ho estudiarem. Bona pregunta. Hem d'estudiar-ho. Però de moment, el que veiem és escrit 0...
Aquest és, per descomptat, un cas rar, però em va sorprendre quan vaig saber que stat_statemetns hi poden desplaçar-se.
Hi pot haver moltes coses a Pg_stat_statements. Hem trobat el fet que si teniu track_utility = on, també es fa un seguiment dels vostres conjunts.
Sí, per descomptat.
I si teniu java hibernate, que és aleatori, la taula hash comença a situar-se allà. I tan bon punt desactiveu una aplicació molt carregada, acabeu amb 50-100 grups. I allà tot és més o menys estable. Una manera de combatre això és augmentar pg_stat_statements.max.
Sí, però cal saber quant. I d'alguna manera hem de vigilar-lo. Això és el que faig. És a dir, tinc pg_stat_statements.max. I veig que en el moment de la instantània no havia arribat al 70%. D'acord, no hem perdut res. Reiniciem. I tornem a estalviar. Si la següent instantània és inferior a 70, és probable que no tornis a perdre res.
Sí. El valor predeterminat és ara 5. I això és suficient per a moltes persones.
Normalment sí.
Vídeo:
PD: En nom meu, afegiré que si Postgres conté dades confidencials i no es poden incloure a l'entorn de prova, podeu utilitzar . L'esquema és aproximadament el següent:
Font: www.habr.com