{"id":78742,"date":"2020-04-21T19:42:46","date_gmt":"2020-04-21T17:42:46","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/promyshlennyj-podhod-k-tyuningu-postgresql-eksperimenty-nad-bazami-dannyh-nikolaj-samohvalov"},"modified":"2020-04-21T19:42:46","modified_gmt":"2020-04-21T17:42:46","slug":"promyshlennyj-podhod-k-tyuningu-postgresql-eksperimenty-nad-bazami-dannyh-nikolaj-samohvalov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/promyshlennyj-podhod-k-tyuningu-postgresql-eksperimenty-nad-bazami-dannyh-nikolaj-samohvalov","title":{"rendered":"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser&#187;. Nikolai Samokhvalov","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><strong>Jeg pr\u00e6senterer en gennemgang af Nikolai Samokhvalovs rapport \"En industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser\"<\/strong><\/p>\n<p><\/p>\n<p>Shared_buffers = 25% \u2013 er det meget, lidt eller lige tilpas? Hvordan kan man finde ud af, om denne \u2013 ret for\u00e6ldede \u2013 anbefaling er relevant i dit specifikke tilf\u00e6lde?<\/p>\n<p><\/p>\n<p>Det er tid til at tage sp\u00f8rgsm\u00e5let om valg af parametre i postgresql.conf \"seri\u00f8st\". Ikke ved hj\u00e6lp af blinde \"autotunere\" eller for\u00e6ldede r\u00e5d fra artikler og blogs, men baseret p\u00e5:<\/p>\n<p><\/p>\n<ol>\n<li>strengt kontrollerede eksperimenter p\u00e5 databaser, udf\u00f8rt automatisk, i stor skala og under forhold, der er s\u00e5 t\u00e6t som muligt p\u00e5 \"kampe\",<\/li>\n<li>en dyb forst\u00e5else af databasens og operativsystemets funktioner.<\/li>\n<\/ol>\n<p><\/p>\n<p>Ved at bruge Nancy CLI (<noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/postgres.ai\/nancy\">https:\/\/gitlab.com\/postgres.ai\/nancy<\/a><\/noindex>), vil vi se p\u00e5 et konkret eksempel \u2013 de berygtede shared_buffers \u2013 i forskellige situationer, i forskellige projekter og fors\u00f8ge at finde ud af, hvordan man v\u00e6lger den optimale indstilling til vores infrastruktur, database og belastning.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/a15b93734b6563abaec4a713c975732a.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Vi vil tale om eksperimenter med databaser. Dette er en historie, der har varet lidt mere end et halvt \u00e5r. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/e77255c4abaa2a01ae37fe888fe67db7.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Lidt om mig selv. Jeg har mere end 14 \u00e5rs erfaring med Postgres. Jeg har grundlagt en r\u00e6kke sociale netv\u00e6rk. Postgres er blevet brugt, og bliver stadig brugt, overalt.<\/p>\n<p><\/p>\n<p>Derudover har RuPostgres-gruppen p\u00e5 Meetup, 2. plads i verden. Vi n\u00e6rmer os langsomt 2000 medlemmer. RuPostgres.org.<\/p>\n<p><\/p>\n<p>Og til forskellige konferencer, inklusive Highload, har jeg ansvaret for databaser, is\u00e6r Postgres, siden grundl\u00e6ggelsen.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/fa009b50f1c0293eee80fc03fd2c05f0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og de seneste par \u00e5r har jeg genoptaget min praksis inden for Postgres-konsulentarbejde i 11 tidszoner herfra.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/550c3ddcd516adca14d2b3de9c34b7ff.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Da jeg gjorde dette for et par \u00e5r siden, havde jeg haft en vis pause i aktivt h\u00e5ndarbejde med Postgres, nok siden 2010. Jeg blev overrasket over, hvor lidt der var \u00e6ndret i DBA'ernes arbejdsmilj\u00f8, og hvor meget h\u00e5ndarbejde der stadig var n\u00f8dvendigt. Jeg t\u00e6nkte straks, at der m\u00e5tte v\u00e6re noget galt \u2013 der er behov for at automatisere s\u00e5 meget som muligt.<\/p>\n<p><\/p>\n<p>Og da alt dette var fjernt, var de fleste kunder i skyen. Og allerede meget var \u00e5benlyst automatiseret. Mere om det senere. Med andre ord f\u00f8rte alt dette til ideen om, at der skulle v\u00e6re et s\u00e6t v\u00e6rkt\u00f8jer, alts\u00e5 en platform, der ville automatisere stort set alle DBA-handlinger for at kunne h\u00e5ndtere et stort antal databaser.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/b02097f0bb23fa9d7c30e38ab9f3de7b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>I denne rapport vil der ikke v\u00e6re:<\/p>\n<p><\/p>\n<ul>\n<li>Der vil ikke v\u00e6re \"s\u00f8lvkugler\" og udsagn som \u2013 s\u00e6t 8 GB eller 25 % shared_buffers, s\u00e5 vil alt v\u00e6re godt. Der vil ikke v\u00e6re s\u00e5 meget om shared_buffers. <\/li>\n<li>Hardcore 'indretningsdelene'. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/ccea359ec78a967c150ddcedc3e50a88.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hvad sker der?<\/p>\n<p><\/p>\n<ul>\n<li>Der vil v\u00e6re optimeringsprincipper, som vi anvender og udvikler. Der vil komme forskellige ideer, som opst\u00e5r undervejs, og forskellige v\u00e6rkt\u00f8jer, som vi i h\u00f8j grad udvikler i Open Source, dvs. vores grundlag er i Open Source. Desuden har vi billetter, alt kommunikation foreg\u00e5r praktisk taget i Open Source. Du kan se, hvad vi arbejder p\u00e5 nu, hvad der kommer i n\u00e6ste udgivelse osv. <\/li>\n<li>Og der vil ogs\u00e5 v\u00e6re en vis erfaring med anvendelsen af disse principper og v\u00e6rkt\u00f8jer i en r\u00e6kke virksomheder: fra sm\u00e5 startups til store firmaer. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/86e6f379726dec814aca616a30d36a2f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hvordan udvikler det sig?<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/c1422d9f2945e717c6ebb31f5fef6329.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>For det f\u00f8rste er hovedopgaven for DBA ud over at sikre oprettelsen af instanser, implementeringen af backups osv. at finde flaskehalse og optimere ydeevnen.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/8e682ca8666e94d6688348ebe4540327.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>I \u00f8jeblikket er det struktureret p\u00e5 denne m\u00e5de. Vi ser p\u00e5 overv\u00e5gning, ser noget, men mangler nogle detaljer. Vi begynder at grave dybere, typisk manuelt, og forst\u00e5r, hvad vi skal g\u00f8re med det.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/04599422ea6b6d57c79a4e48ba2db8b7.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Der er to tilgange. Pg_stat_statements \u2013 den standardl\u00f8sning, der bruges til at identificere langsomme foresp\u00f8rgsler. Og loganalyse af Postgres ved hj\u00e6lp af pgBadger.<\/p>\n<p><\/p>\n<p>Hver af tilgange har alvorlige mangler. Den f\u00f8rste tilgang kaster alle parametre v\u00e6k. Og hvis vi ser grupper af SELECT * FROM table where kolonne er lig med ? eller $ med starten fra version 10 af Postgres. Vi ved ikke - er det en index scan eller seq scan. Det afh\u00e6nger meget af parameteren. Hvis du inds\u00e6tter en sj\u00e6ldent forekommende v\u00e6rdi, vil det v\u00e6re en index scan. Inds\u00e6tter du en v\u00e6rdi, der udg\u00f8r 90 % af tabellen, vil det \u00e5benlyst v\u00e6re en seq scan, fordi Postgres kender statistikken. Dette er en stor ulempe ved pg_stat_statements, selvom der er gjort nogle fors\u00f8g p\u00e5 at forbedre det.<\/p>\n<p><\/p>\n<p>Den st\u00f8rste ulempe ved loganalyser er, at du typisk ikke kan tillade 'log_min_duration_statement = 0'. Og det vil vi ogs\u00e5 tale om. Derfor ser du ikke det komplette billede. Og en foresp\u00f8rgsel, der er meget hurtig, kan forbruge en enorm m\u00e6ngde ressourcer, men du vil ikke se den, fordi den er under din t\u00e6rskel.<\/p>\n<p><\/p>\n<p><strong>Hvordan l\u00f8ser DBA'er de problemer, de finder?<\/strong><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/5e57fefdec6256f82045aaac037b516c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>For example, we found some problem. What is usually done? If you're a developer, you'll do something on some instance that isn't that large. If you're a DBA, you have a staging. And there can only be one. And it's six months behind. And you think you're going to go into production. Even experienced DBAs check in production, on a replica. Sometimes they create a temporary index, ensure it helps, drop it, and hand it over to developers so they can stick it into migration files. This kind of nonsense is happening now. And it's a disaster.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/402e80c7e5fbca6a054c0c9ec61e5fe3.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Tuning configurations.<\/li>\n<li>Optimizing the set of indexes. <\/li>\n<li>Modifying the SQL query itself (this is the most complex method).<\/li>\n<li>Adding capacity (the simplest method in most cases).<\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/8a6b3cd56e0df5c7908714926ba1eb05.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>There are many things with these. There are many knobs in Postgres. You need to know a lot. Many indexes in Postgres, thanks in part to the organizers of this conference. And you need to understand all this, and this is what gives DBAs the feeling that they're practicing black magic. That is, you need to work for about 10 years to start understanding all of this properly.<\/p>\n<p><\/p>\n<p>And I am a fighter against this black magic. I want to do everything so that there is technology, not intuition in all of this.<\/p>\n<p><\/p>\n<p><strong>Real-life examples<\/strong><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/70b11c3df9c41c66570635d5f309ed24.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>I have observed this in at least two projects, including my own. Another blog post informs us that a value of 1,000 for default_statistict_target is good. Good, let's try it in production.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/0b4c2bd6f73df06967c94d5d78b07279.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>And here we are, using our tool two years later through experiments on the databases we're discussing today, we can compare what was and what is now. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/3564eade6532003d2279c2736ab6d733.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>And for this, we need to create an experiment. It consists of four parts. <\/p>\n<p><\/p>\n<ul>\n<li>The first is the environment. We need hardware. And when I come to a company and sign a contract, I say to provide me with hardware that is the same as in production. For each of your Masters, I need at least one piece of hardware like that. Whether it's a virtual machine instance on Amazon or Google, or I need exactly that same hardware. That is, I want to recreate the environment. And when we say environment, we include the major version of Postgres. <\/li>\n<li>The second part is the object of our research. This is the database. It can be created in several ways. I will show how. <\/li>\n<li>The third part is the load. This is the most difficult moment. <\/li>\n<li>Den fjerde del handler om, hvad vi kontrollerer, dvs. hvad vi sammenligner. Lad os sige, at vi kan \u00e6ndre en eller flere parametre i konfigurationen, eller vi kan oprette en indeks, osv. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/8ccd09ac4cdd336618413375617c10a6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vi starter et eksperiment. Her er pg_stat_statements. Til venstre \u2013 hvad der var. Til h\u00f8jre \u2013 hvad der blev.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/6f82d7e25a77b700f2ddb01f42a861a2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Til venstre default_statistics_target = 100, til h\u00f8jre = 1 000. Vi kan se, at det hjalp os. Generelt blev alt bedre med 8 %.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/52dda8fb5fbcb9beecaa1eda8443a374.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Men hvis vi ruller ned, vil der v\u00e6re gruppeforesp\u00f8rgsler fra pgBadger eller fra pg_stat_statements. Der er to muligheder. Vi kan se, at en foresp\u00f8rgsel er faldet med 88 %. Og her kommer det ingeni\u00f8rm\u00e6ssige aspekt ind. Vi kan dykke dybere, fordi det er interessant at finde ud af, hvorfor den faldt. Vi skal forst\u00e5, hvad der skete med statistikken. Hvorfor flere buckets i statistikken f\u00f8rer til et d\u00e5rligere resultat.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/4e6dfc04af4b3fc2b626dd46c08bdf66.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Eller vi kan v\u00e6lge ikke at dykke dybere, men i stedet udf\u00f8re \"ALTER TABLE \u2026 ALTER COLUMN\" og tilbagef\u00f8re 100 buckets til statistikken for denne kolonne. Og derefter kan vi gennem yderligere eksperimenter bekr\u00e6fte, at denne l\u00f8sning hjalp. Det er det ingeni\u00f8rm\u00e6ssige tilgang, som hj\u00e6lper os med at se hele billedet og tr\u00e6ffe beslutninger baseret p\u00e5 data, ikke intuition.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/c87df172b994a4523478beebaf4a0275.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/9e766aa4348bd1a77b697e3179d84bbd.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Her er nogle eksempler fra andre omr\u00e5der. Tests har haft CI-tests i mange \u00e5r. Og ingen projekt i sund fornuft vil eksistere uden automatiserede tests.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/b6c21981dc8b2b285973ae42199e2b4c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>I andre industrier, s\u00e5som luftfart og bilproduktion, n\u00e5r vi tester aerodynamik, har vi ogs\u00e5 mulighed for at lave eksperimenter. Vi vil ikke umiddelbart sende noget fra tegningen direkte ud i rummet eller tage en bil ud p\u00e5 vejen. For eksempel har vi en vindtunnel. <\/p>\n<p><\/p>\n<p>Fra observationer i andre brancher kan vi drage konklusioner. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/cef02ea9280e5795d1e593c600f0541b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>For det f\u00f8rste har vi et specielt milj\u00f8. Det er t\u00e6t p\u00e5 produktionen, men ikke helt. Dets vigtigste kendetegn er, at det skal v\u00e6re billigt, gentageligt og s\u00e5 automatiseret som muligt. Der skal ogs\u00e5 v\u00e6re specielle v\u00e6rkt\u00f8jer til at udf\u00f8re en detaljeret analyse.<\/p>\n<p><\/p>\n<p>Sandsynligvis har vi f\u00e6rre muligheder for at unders\u00f8ge hver millimeter af overfladen p\u00e5 en vinge, n\u00e5r vi har startet en flyvning og er i luften, end vi har i en vindtunnel. Vi har bedre diagnosticeringsv\u00e6rkt\u00f8jer. Vi kan tillade os at tilf\u00f8je mere tungt udstyr, som vi ikke kan installere p\u00e5 et fly i luften. Det samme g\u00e6lder for Postgres. I nogle tilf\u00e6lde kan vi aktivere fuld foresp\u00f8rgselslogging under eksperimenter. Og vi \u00f8nsker ikke at g\u00f8re dette i produktion. M\u00e5ske vil vi endda aktivere det gennem auto_explain i vores planer.<\/p>\n<p><\/p>\n<p>Og som jeg allerede har sagt, betyder et h\u00f8jt niveau af automation, at vi trykker p\u00e5 en knap og gentager processen. S\u00e5dan skal det v\u00e6re, s\u00e5 der kan laves mange eksperimenter, og s\u00e5 det bliver en rutine.<\/p>\n<p><\/p>\n<p>Nancy CLI \u2013 fundamentet for \"database-laboratoriet\"<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/f8303df21f309fb209929acec260b757.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og her er vi kommet med denne l\u00f8sning. Det vil sige, jeg talte om disse id\u00e9er i juni, for n\u00e6sten et \u00e5r siden. Og vi har allerede i Open Source den s\u00e5kaldte Nancy CLI. Dette er fundamentet for at bygge et database-laboratorium.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/0ed3c72461123745be4fa9e58455baa0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/postgres-ai\/nancy\">Nancy<\/a><\/noindex> \u2013 Det er i Open Source, p\u00e5 Gitlab. Du kan sige, du kan pr\u00f8ve det. Jeg har givet et link i slides. Du kan klikke p\u00e5 det, og s\u00e5 vil der v\u00e6re <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/postgres-ai\/nancy\/-\/blob\/master\/help\/nancy_run.md\">help<\/a><\/noindex> for alle parametre.<\/p>\n<p><\/p>\n<p>Selvf\u00f8lgelig er der stadig meget under udvikling. Der er mange id\u00e9er i spil. Men dette er allerede noget, vi anvender n\u00e6sten dagligt. Og n\u00e5r vi f\u00e5r en id\u00e9 \u2013 hvad nu hvis vi ved sletning af 40.000.000 r\u00e6kker, at alt g\u00e5r i IO, s\u00e5 kan vi lave et eksperiment og se n\u00e6rmere p\u00e5, hvad der sker, og derefter fors\u00f8ge at rette det i realtid. Det vil sige, vi laver et eksperiment. For eksempel justerer vi noget og ser, hvad resultatet bliver. Og vi g\u00f8r det ikke i produktion. Det er essensen af id\u00e9en.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/c22d332de4b45d604dfb9c5a95404fd6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hvor kan dette fungere? Det kan fungere lokalt, det vil sige, det kan g\u00f8res hvor som helst, jeg kan endda starte det p\u00e5 en MacBook. Du skal bruge Docker, s\u00e5 k\u00f8rer vi. Og det er det. Det kan k\u00f8re i en hvilken som helst instans p\u00e5 hardware eller i en virtuel maskine, hvor som helst.<\/p>\n<p><\/p>\n<p>Og der er ogs\u00e5 mulighed for at k\u00f8re eksternt i Amazon EC2 Instance, i spots. Og det er en rigtig god mulighed. For eksempel, i g\u00e5r gennemf\u00f8rte vi over 500 eksperimenter p\u00e5 i3 instance, fra den mindste og op til i3-16-xlarge. Og de 500 eksperimenter kostede os 64 dollars. Hvert eksperiment varede 15 minutter. Alts\u00e5, takket v\u00e6re brugen af spots er det meget billigt \u2013 70 % rabat, sekundtaxa fra Amazon. Du kan g\u00f8re rigtig meget. Du kan udf\u00f8re reelle unders\u00f8gelser.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/64c61cc9dd7181296b2ef5b815a17493.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og tre store versioner af Postgres underst\u00f8ttes. Det er ikke s\u00e5 sv\u00e6rt at tilpasse nogle af de gamle versioner og den nye 12. version ogs\u00e5.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/ee147c91014ab698cbd3c60e193bef23.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vi kan angive objektet p\u00e5 tre m\u00e5der. Det er:<\/p>\n<p><\/p>\n<ul>\n<li>Dump\/sql-fil. <\/li>\n<li>Den prim\u00e6re metode er at klone PGDATA-mappen. Som regel tages det fra backup-serveren. Hvis du har normale bin\u00e6re backups, kan du lave kloner derfra. Hvis du har cloud, s\u00e5 vil en cloud-udbyder som Amazon eller Google selv g\u00f8re det for dig. Dette er den vigtigste metode for kloner af reelt production. P\u00e5 denne m\u00e5de implementerer vi lige netop. <\/li>\n<li>Og den sidste metode er velegnet til forskning, n\u00e5r du har lyst til at finde ud af, hvordan en bestemt ting fungerer i Postgres. Det er pgbench. Du kan generere med pgbench. Det er bare en mulighed \u2018db-pgbench\u2019. Du fort\u00e6ller den, hvilken scale. Og alt vil blive genereret i skyen, som angivet.<\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/2bc3e30cb31a19f66c6b55480447126f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og belastningen:<\/p>\n<p><\/p>\n<ul>\n<li>Vi kan udf\u00f8re belastningen i \u00e9n SQL-tr\u00e5d. Dette er den mest primitive metode. <\/li>\n<li>Eller vi kan emulere belastningen. Og vi kan emulere den prim\u00e6rt p\u00e5 f\u00f8lgende m\u00e5de. Vi skal samle alle logs. Og det er smertefuldt. Jeg vil vise, hvorfor. Og med hj\u00e6lp af pgreplay, som er integreret i Nancy, afspiller vi. <\/li>\n<li>Eller en anden mulighed. Den s\u00e5kaldte h\u00e5ndlavede belastning, som vi laver med en vis m\u00e6ngde kr\u00e6fter. Ved at analysere vores nuv\u00e6rende belastning p\u00e5 systemet, tr\u00e6kker vi de mest fremtr\u00e6dende grupper af foresp\u00f8rgsler. Og med pgbench kan vi emulere denne belastning i laboratoriet. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/4adba12881faf9ad9d4f9e9f42c0f5c1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Eller vi skal udf\u00f8re en SQL-foresp\u00f8rgsel, dvs. kontrollere en eller anden migration, lave en indeks, k\u00f8re ANALAZE der. Og vi ser, hvad der var f\u00f8r vacuum og efter vacuum. Kort sagt, enhver SQL.<\/li>\n<li>Enten \u00e6ndrer vi en eller flere parametre i konfigurationen. Vi kan bede om at kontrollere for eksempel 100 v\u00e6rdier i Amazon for vores terabyte-database. Og efter et par timer har du resultatet. Som regel vil terabyte-database blive bygget op over flere timer. Men der er et patch i udviklingen, vi kan have en sekvens, det vil sige, du kan konsekvent bruge den samme pgdata p\u00e5 den samme server og udf\u00f8re kontroller. Postgres vil genstarte, caches vil blive nulstillet. Og du kan p\u00e5f\u00f8re belastning. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/02985b47bf0ab62e8f1c4cc3ea003f26.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Der kommer en mappe, hvor der ligger en masse forskellige filer, der starter med snapshots af pg<em>stat<\/em>***. Og det mest interessante der er pg_stat_statements, pg_stat_kcache. Dette er to udvidelser, som analyserer foresp\u00f8rgsler. Og pg_stat_bgwriter indeholder ikke kun pgwriter-statistik, men ogs\u00e5 statistik om checkpoint og hvordan backend-processer udskubber snavset buffers. Det hele er interessant at se p\u00e5. For eksempel, n\u00e5r vi konfigurerer shared_buffers, er det meget interessant at se, hvor meget de har udskudt.<\/li>\n<li>Der kommer ogs\u00e5 Postgres logs. To logs \u2013 forberedelsesloggen og belastningsafspilningsloggen. <\/li>\n<li>En forholdsvis ny funktion \u2013 det er FlameGraphs.<\/li>\n<li>Hvis du ogs\u00e5 har brugt pgreplay eller pgbench varianter til belastningsafspilning, vil deres output v\u00e6re tilg\u00e6ngeligt. Og du vil se latency og TPS. Du kan forst\u00e5, hvordan de opfattede det. <\/li>\n<li>Systeminformation. <\/li>\n<li>Grundl\u00e6ggende tests af CPU og IO. Dette er mere for EC2-instanser i Amazon, n\u00e5r du \u00f8nsker at starte 100 ens instanser i \u00e9n str\u00f8m og k\u00f8re 100 forskellige testl\u00f8b, s\u00e5 har du 10.000 eksperimenter. Og du skal sikre dig, at du ikke f\u00e5r en defekt instans, som allerede er belastet af nogen. P\u00e5 denne hardware er der andre, der aktiverer og der er ikke mange ressourcer tilbage til dig. S\u00e5danne resultater b\u00f8r du bedre kaste ud. Og netop med sysbench fra Alexey Kopytov laver vi flere korte tests, som bliver leveret, og du kan sammenligne med andre, det vil sige, du forst\u00e5r, hvordan CPU og IO opf\u00f8rer sig. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/c4ddf5283c3c79e3d4c2c061e7dd9e7d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hvilke tekniske udfordringer er der p\u00e5 eksempler fra forskellige virksomheder?<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/959690b464a01a4a3cb67ec497becff1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Lad os sige, at vi vil gentage en reel belastning ved hj\u00e6lp af logs. Det er en fremragende id\u00e9, hvis det er skrevet med Open Source pgreplay. Vi bruger det. Men for at det fungerer godt, skal du aktivere fuld logning af foresp\u00f8rgsler med parametre og timing.<\/p>\n<p><\/p>\n<p>Der er nogle vanskeligheder med varighed og tidsstempel. Vi ser bort fra det hele. Det vigtigste sp\u00f8rgsm\u00e5l er \u2013 har du r\u00e5d til det eller ej? <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/5d08fadbaf67b8a137212302b6adf48a.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/gist.github.com\/NikolayS\/08d9b7b4845371d03e195a8d8df43408\">https:\/\/gist.github.com\/NikolayS\/08d9b7b4845371d03e195a8d8df43408<\/a><\/noindex><\/p>\n<p><\/p>\n<p>Problemet er, at det m\u00e5ske ikke er tilg\u00e6ngeligt. Du skal f\u00f8rst forst\u00e5, hvilken str\u00f8m der vil blive skrevet i loggen. Hvis du har pg_stat_statements, kan du med denne foresp\u00f8rgsel (linket vil v\u00e6re tilg\u00e6ngeligt i slides) forst\u00e5, hvor mange byte der omtrent vil blive skrevet per sekund.<\/p>\n<p><\/p>\n<p>Vi ser p\u00e5 l\u00e6ngden af foresp\u00f8rgslen. Vi ignorerer det faktum, at der ikke er parametre, men vi kender l\u00e6ngden af foresp\u00f8rgslen og ved, hvor mange gange per sekund den blev udf\u00f8rt. P\u00e5 den m\u00e5de kan vi ansl\u00e5, hvor mange byte der omtrent skrives per sekund. Vi kan tage fejl med det dobbelte, men ordren vil vi helt sikkert forst\u00e5 p\u00e5 denne m\u00e5de.<\/p>\n<p><\/p>\n<p>Vi kan se, at denne foresp\u00f8rgsel udf\u00f8res 802 gange per sekund. Og vi ser, at bytes_per sec \u2013 300 kB\/s vil blive skrevet plus minus. Og som regel kan vi tillade os en s\u00e5dan str\u00f8m. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/218f905073a8519115adf5c65825b74d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Men! Sagen er, at der er forskellige logningssystemer. Og som standard har folk normalt \u2018syslog\u2019.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/66054682083ba2ada174afb5e7ee3973.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og hvis du har syslog, kan du f\u00e5 et billede som dette. Vi tager pgbench, aktiverer logning af foresp\u00f8rgsler og ser, hvad der sker.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/a05723dcf10a7733f054ba108bb0f107.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Uden logning \u2013 det er s\u00f8jlen til venstre. Vi fik 161.000 TPS. Med syslog \u2013 det giver os 37.000 TPS i Ubuntu 16.04 p\u00e5 Amazon. Og hvis vi \u00e6ndrer til de to andre logningsmetoder, er situationen meget bedre. Det vil sige, vi forventede, at det ville falde, men ikke s\u00e5 meget.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/a7d90af9d29761d3b80eb09bf050760f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og i CentOS 7, hvor journald ogs\u00e5 deltager og konverterer logfiler til bin\u00e6rt format for nemmere s\u00f8gning osv., falder vi faktisk med 44 gange i TPS.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/86d2af18a0e6364f297a62378b6ede56.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og det er det, folk lever med. Og ofte i virksomheder, is\u00e6r store, er det meget sv\u00e6rt at \u00e6ndre. Hvis du kan bev\u00e6ge dig v\u00e6k fra syslog, s\u00e5 g\u00f8r det venligst.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/a167a6fac7f28c7541515f7eff30bdb4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Vurder IOPS og skriveflow. <\/li>\n<li>Tjek dit logningssystem. <\/li>\n<li>Hvis den forventede belastning er overdrevet h\u00f8j, overvej muligheden for sampling. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/127fa1296578ba0ba6eac2b44c5c5398.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vi har pg_stat_statements. Som jeg sagde, skal det n\u00f8dvendigvis v\u00e6re der. Og vi kan tage og beskrive hver gruppe af foresp\u00f8rgsler p\u00e5 en speciel m\u00e5de i en fil. Og herefter kan vi bruge en meget praktisk funktion i pgbench \u2013 muligheden for at inds\u00e6tte flere filer ved hj\u00e6lp af optionen '-f'.<\/p>\n<p><\/p>\n<p>Han forst\u00e5r meget af \"-f\". Og man kan angive med \"@\" i slutningen, hvilken andel hver fil skal have. S\u00e5ledes kan vi sige, at dette skal udf\u00f8res i 10 % af tilf\u00e6ldene, og dette i 20 %. Dette vil bringe os t\u00e6ttere p\u00e5, hvad vi ser i produktion.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/b91d18a9861abdc36bfda54cd72a142f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hvordan kan vi vide, hvad vi har i produktion? Hvilken andel og hvad er det? Her g\u00e5r vi lidt ud af kurs. Vi har et andet produkt. <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/postgres-ai\/postgres-checkup\">postgres-checkup<\/a><\/noindex>. Ogs\u00e5 baseret p\u00e5 Open Source. Og vi udvikler det aktivt lige nu.<\/p>\n<p><\/p>\n<p>Det blev skabt af lidt andre \u00e5rsager. P\u00e5 grund af, at overv\u00e5gning ikke er tilstr\u00e6kkelig. Det vil sige, at n\u00e5r du kommer, kigger p\u00e5 databasen, ser p\u00e5 de problemer, der er. Og som regel laver du en health_check. Hvis du er en erfaren DBA, laver du en health_check. Du kigger p\u00e5 brugen af indekser mv. Hvis du har OKmeter, er det fantastisk. Det er en fremragende overv\u00e5gning for Postgres. OKmeter.io \u2013 rabat, det er virkelig godt lavet. Det er betalt.<\/p>\n<p><\/p>\n<p>Hvis du ikke har det, er der som regel ikke meget i overv\u00e5gning. Normalt er der CPU, IO og det med forbehold, og det er alt. Vi har brug for mere. Vi skal se, hvordan autovakuum fungerer, hvordan checkpoint fungerer, i io skal vi adskille checkpoint fra bgwriter og fra backend osv.<\/p>\n<p><\/p>\n<p>Problemet er, n\u00e5r du hj\u00e6lper en st\u00f8rre virksomhed, de kan ikke hurtigt implementere noget. De kan ikke hurtigt k\u00f8be OKmeter. M\u00e5ske k\u00f8ber de det om et halvt \u00e5r. De kan ikke hurtigt installere nogen pakker. <\/p>\n<p><\/p>\n<p>Og vi fik ideen om, at vi havde brug for et s\u00e6rligt v\u00e6rkt\u00f8j, der ikke kr\u00e6ver noget installation, det vil sige, at du slet ikke skal installere noget i produktionen. Du installerer det p\u00e5 din b\u00e6rbare computer eller p\u00e5 en observerende server, hvorfra du vil k\u00f8re det. Og det vil analysere mange elementer: b\u00e5de operativsystemet, filsystemet, og selve Postgres ved at udf\u00f8re nogle lette foresp\u00f8rgsler, som kan k\u00f8res direkte p\u00e5 produktion uden nedetid.<\/p>\n<p><\/p>\n<p>Vi kaldte det Postgres-checkup. Hvis vi taler medicinsk, er det en regelm\u00e6ssig sundhedsvurdering. Hvis vi taler om bilhold, er det som serviceeftersyn. Du f\u00e5r service p\u00e5 din bil hver sjette m\u00e5ned eller hvert \u00e5r, afh\u00e6ngigt af m\u00e6rket. G\u00f8r du service p\u00e5 din database? Det vil sige, laver du dybdeg\u00e5ende unders\u00f8gelser regelm\u00e6ssigt? Det skal g\u00f8res. Hvis du tager backups, s\u00e5 skal du ogs\u00e5 lave checkup, det er mindst lige s\u00e5 vigtigt.<\/p>\n<p><\/p>\n<p>Og vi har et s\u00e5dant v\u00e6rkt\u00f8j. Det begyndte f\u00f8rst at tage form for omkring tre m\u00e5neder siden. Det er stadig ungt, men der er allerede meget i det.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/514d00b5cb710a7997af0a5dde55b5a8.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vi samler de mest 'indflydelsesrige' foresp\u00f8rgselsgrupper \u2013 rapport K003 i Postgres-checkup<\/p>\n<p><\/p>\n<p>Og der er en gruppe rapporter K. Der er tre rapporter indtil videre. Og der er denne rapport K003. Den viser toppen af pg_stat_statements, sorteret efter total_time.<\/p>\n<p><\/p>\n<p>N\u00e5r vi sorterer foresp\u00f8rgselsgrupper efter total_time, ser vi p\u00e5 toppen en gruppe, der bruger vores system mest, dvs. forbruger flest ressourcer. Hvorfor kalder jeg dem foresp\u00f8rgselsgrupper? Fordi vi har udelukket parametrene. Det er ikke l\u00e6ngere foresp\u00f8rgsler, men grupper af foresp\u00f8rgsler, dvs. de er abstraherede.<\/p>\n<p><\/p>\n<p>Og hvis vi optimerer fra toppen og ned, vil vi lette vores ressourcer og forsinke det tidspunkt, hvor vi skal opgradere. Det er en meget god m\u00e5de at spare penge p\u00e5.<\/p>\n<p><\/p>\n<p>M\u00e5ske er det ikke den bedste metode til at tage sig af brugerne, fordi vi muligvis ikke ser sj\u00e6ldne, men meget irriterende situationer, hvor en person ventede i 15 sekunder. Samlet set er de s\u00e5 sj\u00e6ldne, at vi ikke ser dem, men vi tager os af ressourcerne.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/d16abc423573e4d923b0c03683c2efee.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hvad skete der i denne tabel? Vi lavede to snapshots. Postgres_checkup vil give dig en delta for hver metric: total-time, calls, rows, shared_blks_read osv. Det er det, deltaen er blevet beregnet. Problemet med pg_stat_statements er, at den ikke husker, hvorn\u00e5r den blev nulstillet. Mens pg_stat_database husker, g\u00f8r pg_stat_statements ikke. Du ser, at der st\u00e5r 1.000.000, men vi ved ikke, hvorfra vi har regnet.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/c370bf1237675e03c0a3d362c025ac24.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og her ved vi, her har vi to snapshots. Vi ved, at deltaen i dette tilf\u00e6lde var 56 sekunder. En meget lille periode. Sorteret efter total_time. Og videre kan vi differentiere, dvs. vi deler alle metrics med duration. Hvis vi deler hver metric med duration, vil vi f\u00e5 antal opkald per sekund.<\/p>\n<p><\/p>\n<p>Dern\u00e6st total_time per sekund \u2013 det er min yndlingsmetrik. Den m\u00e5les i sekunder, pr. sekund, dvs. hvor mange sekunder vores system brugte p\u00e5 at udf\u00f8re denne gruppe foresp\u00f8rgsler pr. sekund. Hvis du ser, at det er mere end \u00e9n sekund pr. sekund, betyder det, at du skal give mere end \u00e9n kerne. Det er en meget god metrisk. Du kan forst\u00e5, at denne person for eksempel har brug for minimum tre kerner.<\/p>\n<p><\/p>\n<p>Dette er vores know-how, jeg har aldrig set noget lignende. Bem\u00e6rk \u2013 det er en meget simpel ting \u2013 sekunder pr. sekund. Nogle gange, n\u00e5r din CPU er 100 %, s\u00e5 er det halve time pr. sekund, dvs. du har kun arbejdet med disse foresp\u00f8rgsler i et halvt time. <\/p>\n<p><\/p>\n<p>Here we see rows per second. We know how many rows per second were returned.<\/p>\n<p><\/p>\n<p>And then there's another interesting thing. How much we read from shared_buffers per second from the shared_buffers itself. Hits were already there, and the rows were taken from the operating system cache or from the disk. The first option is fast, while the second may or may not be fast, depending on the situation. <\/p>\n<p><\/p>\n<p>The second way of differentiation is to divide the number of queries in this group. In the second column, you will always have one request divided by the request. And then it gets interesting \u2013 how many milliseconds were spent on this request. We know how this request typically performs. It took 101 milliseconds for each request. This is a traditional metric we need for understanding.<\/p>\n<p><\/p>\n<p>How many lines each request returned on average. We see that this group returns 8. How much was taken and read from the cache on average. We see that everything is nicely cached. Consistent hits for the first group. <\/p>\n<p><\/p>\n<p>The fourth substring in each line indicates the percentage of the total. We have calls, say, in 1,000,000. And we can understand what contribution this group makes. We see that in this case the first group contributes less than 0.01%. That is, it is so slow that we don\u2019t see it in the overall picture. The second group, however, accounts for 5% of the calls. That is, 5% of all calls are from the second group. <\/p>\n<p><\/p>\n<p>It\u2019s also interesting regarding total_time. We spent 14% of the total work time on the first group of requests. On the second, we spent 11%, and so on. <\/p>\n<p><\/p>\n<p>I won\u2019t go into details, but there are nuances. We show the error at the top because when we compare, snapshots can drift, meaning some requests might drop out and might not be present in the second snapshot while new ones might appear. We calculate the error there. If you see 0, that's good. There are no errors. If the error rate is up to 20%, that\u2019s OK. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/327bbf167bc21d37a3e1597b52528e6d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Next, we return to our topic. We need to craft the workload. We take a top-down approach until we reach 80% or 90%. Usually, this is 10-20 groups. And we create files for pgbench. We use random there. Sometimes, unfortunately, this doesn\u2019t work out. In Postgres 12, there will be more opportunities to use this approach. <\/p>\n<p><\/p>\n<p>S\u00e5dan n\u00e5r vi 80-90 % af total_time. Hvad skal vi derefter inds\u00e6tte efter \u00ab@\u00bb? Vi kigger p\u00e5 opkald, ser hvor mange procent og forst\u00e5r, at vi her skal have en bestemt procentdel. Fra disse procentdele kan vi bestemme, hvordan vi balancerer hver af filerne. Herefter bruger vi pgbench og g\u00e5r i gang med arbejdet. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/53edf787f49dcabb5e4731510839332d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vi har ogs\u00e5 K001 og K002. <\/p>\n<p><\/p>\n<p>K001 \u2013 det er en stor streng med fire understrenge. Det er karakteristikken af vores hele belastning. Se den anden kolonne og den anden understreng. Vi ser, at det er cirka halvanden sekund pr. sekund, det vil sige, at hvis der er to kerner, s\u00e5 er det godt. Belastningen vil v\u00e6re omkring 75 %. Og det vil fungere s\u00e5dan. Hvis vi har 10 kerner, s\u00e5 vil vi v\u00e6re helt rolige. S\u00e5dan kan vi evaluere ressourcerne.<\/p>\n<p><\/p>\n<p>K002 \u2013 det kalder jeg klasser af foresp\u00f8rgsler, dvs. SELECT, INSERT, UPDATE, DELETE. Og separat SELECT FOR UPDATE, fordi den l\u00e5ser. <\/p>\n<p><\/p>\n<p>Og her kan vi konkludere, at almindelige l\u00e6sende SELECT \u2013 udg\u00f8r 82 % af alle opkald, men de har 74 % af total_time. Det vil sige, at de bliver kaldt meget, men forbruger mindre ressourcer. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/0e0234e696ffe1c80f8b5acccc602dbd.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og vi vender tilbage til sp\u00f8rgsm\u00e5let: \u00abHvordan v\u00e6lger vi shared_buffers korrekt?\u00bb. Jeg har bem\u00e6rket, at de fleste benchmark-test er bygget p\u00e5 ideen \u2013 lad os se, hvilken throughput der vil v\u00e6re, det vil sige, hvad kapaciteten bliver. Den m\u00e5les som regel i TPS eller QPS.<\/p>\n<p><\/p>\n<p>Og vi fors\u00f8ger at presse s\u00e5 mange transaktioner pr. sekund som muligt ud af maskinen ved hj\u00e6lp af tuning-parametre. Her er det nemlig 311 pr. sekund for select.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/d5e73f2672d94bb92eed921ef3dfe0b7.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Men ingen k\u00f8rer til arbejde og tilbage hjem med bilen p\u00e5 fuld fart. Det ville v\u00e6re t\u00e5beligt. Det samme g\u00e6lder databaser. Vi b\u00f8r ikke k\u00f8re p\u00e5 fuld fart, og det g\u00f8r ingen. Ingen lever i et production-milj\u00f8 med 100 % CPU. Selvom der m\u00e5ske er nogen, der g\u00f8r, er det ikke godt. <\/p>\n<p><\/p>\n<p>Ideen er, at vi normalt k\u00f8rer p\u00e5 ca. 20 % af vores kapacitet, gerne ikke over 50 %. Og vi fors\u00f8ger f\u00f8rst og fremmest at optimere svartid for vores brugere. Det vil sige, vi skal justere vores parametre, s\u00e5 vi har minimal latency ved en hypotetisk 20 % hastighed. Det er den id\u00e9, som vi ogs\u00e5 fors\u00f8ger at anvende i vores eksperimenter.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/c32c2cfb76dce0ce6b50e929bbf914ac.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Og til slut nogle anbefalinger: <\/p>\n<p><\/p>\n<ul>\n<li>S\u00f8rg for at lave Database Lab.<\/li>\n<li>Hvis muligt, lav det on demand, s\u00e5 det kan blive opdelt i et stykke tid \u2013 leg med det og smid det derefter v\u00e6k. Hvis du har cloud, s\u00e5 er det selvf\u00f8lgelig, dvs. hav mange st\u00e5ende ressourcer. <\/li>\n<li>V\u00e6r nysgerrig. Og hvis noget ikke ser rigtigt ud, s\u00e5 tjek det med eksperimenter for at se, hvordan det opf\u00f8rer sig. Nancy kan bruges til at l\u00e6re sig selv og til at unders\u00f8ge, hvordan databasen fungerer.<\/li>\n<li>Og sigt efter minimal responstid. <\/li>\n<li>Og v\u00e6r ikke bange for Postgres-kildekoden. N\u00e5r du arbejder med kildekoden, skal du kunne engelsk. Der er mange kommentarer, der forklarer alt. <\/li>\n<li>Og tjek sundheden af databasen regelm\u00e6ssigt, mindst en gang hver tredje m\u00e5ned manuelt eller brug Postgres-checkup. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/8d2ac05f44bd245b879799862ce9e233.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Sp\u00f8rgsm\u00e5l<\/p>\n<p><\/p>\n<p><em>Tusind tak! Det er en meget interessant ting.<\/em> <\/p>\n<p><\/p>\n<p>To ting.<\/p>\n<p><\/p>\n<p><em>Ja, to ting. Jeg forstod bare ikke helt. N\u00e5r vi arbejder med Nancy, kan vi kun justere \u00e9n parameter eller en hel gruppe?<\/em><\/p>\n<p><\/p>\n<p>Vi har en delta-config parameter. Du kan justere s\u00e5 mange, som du \u00f8nsker, p\u00e5 \u00e9n gang. Men du skal forst\u00e5, at n\u00e5r du \u00e6ndrer mange ting, kan du drage forkerte konklusioner. <\/p>\n<p><\/p>\n<p><em>Ja. Derfor spurgte jeg? Fordi det er sv\u00e6rt at lave eksperimenter, n\u00e5r du kun har \u00e9n parameter. Du justerer den, ser hvordan det fungerer, stiller den ind, og s\u00e5 begynder du med den n\u00e6ste.<\/em><\/p>\n<p><\/p>\n<p>Du kan justere flere p\u00e5 \u00e9n gang, men det afh\u00e6nger selvf\u00f8lgelig af situationen. Men det er bedre at teste \u00e9n id\u00e9 ad gangen. Vi fik en id\u00e9 i g\u00e5r. Vi havde en meget lignende situation. Der var to konfigurationer. Og vi kunne ikke forst\u00e5, hvorfor der var s\u00e5 stor forskel. Og id\u00e9en opstod om, at vi skulle bruge dikotomi for systematisk at forst\u00e5 og finde ud af, hvad forskellen var. Du kan g\u00f8re halvdelen af parametrene ens p\u00e5 \u00e9n gang, derefter en fjerdedel osv. Alt er fleksibelt.<\/p>\n<p><\/p>\n<p><em>Og jeg har et sp\u00f8rgsm\u00e5l mere. Projektet er ungt og udvikler sig. Er dokumentationen allerede klar, og findes der en detaljeret beskrivelse?<\/em><\/p>\n<p><\/p>\n<p>Jeg har der lavet et link til beskrivelsen af parametrene. Det findes. Men der mangler stadig meget. Jeg leder efter ligesindede. Og jeg finder dem, n\u00e5r jeg taler. Det er rigtig fedt. Nogen arbejder allerede sammen med mig, nogen har hjulpet, og har gjort noget der. Og hvis du er interesseret i dette emne, s\u00e5 giv mig gerne feedback - hvad der mangler. <\/p>\n<p><\/p>\n<p><em>N\u00e5r vi f\u00e5r lavet laboratoriet, kan der m\u00e5ske komme feedback. Vi ser p\u00e5 det. Tak!<\/em><\/p>\n<p><\/p>\n<p><em>Hej! Tak for pr\u00e6sentationen! Jeg bem\u00e6rkede, at der er st\u00f8tte for Amazon. Er der planer om st\u00f8tte til GSP?<\/em><\/p>\n<p><\/p>\n<p>Det er et godt sp\u00f8rgsm\u00e5l. Vi er begyndt at arbejde p\u00e5 det. Og lige nu er det sat i bero, fordi vi \u00f8nsker at spare. Det vil sige, der er support via 'run on localhost'. Du kan selv oprette en instance og arbejde lokalt. For resten g\u00f8r vi det p\u00e5 den m\u00e5de. Jeg g\u00f8r det s\u00e5dan i Getlab, der k\u00f8rer p\u00e5 GSP. Men vi ser ikke umiddelbart nogen mening i at lave netop denne orkestrering, fordi Google ikke har billige spottjenester. De har status instances, men de har begr\u00e6nsninger. For det f\u00f8rste er der altid kun 70 % rabat, og der er ikke mulighed for at lege med prisen. Det er derfor, vi h\u00e6ver prisen p\u00e5 spottjenester med 5-10 % for at mindske risikoen for, at du bliver ramt. Det vil sige, at du sparer med spottjenesterne, men de kan til enhver tid fjernes. Hvis du s\u00e6tter prisen en smule h\u00f8jere end de andre, vil du blive sl\u00e5et ud senere. Google har en helt anden specifik. Og der er ogs\u00e5 en meget d\u00e5rlig begr\u00e6nsning \u2013 de lever kun i 24 timer. Nogle gange vil vi dog gerne k\u00f8re eksperimentet i 5 dage. Men det kan ske med spottjenester, som nogle gange lever i flere m\u00e5neder. <\/p>\n<p><\/p>\n<p><em>Hej! Tak for din pr\u00e6sentation! Du n\u00e6vnte om checkup. Hvordan beregner du fejlene i stat_statements?<\/em><\/p>\n<p><\/p>\n<p>Det er et meget godt sp\u00f8rgsm\u00e5l. Jeg kan vise og forklare det i detaljer. Kort sagt \u2013 vi ser p\u00e5, hvordan s\u00e6t af foresp\u00f8rgsler har \u00e6ndret sig: hvor mange der er faldet v\u00e6k, og hvor mange nye der er dukket op. Og derefter kigger vi p\u00e5 to metrikker: total_time og calls, s\u00e5 der er to fejl her. Vi ser p\u00e5, hvilket bidrag de \u00e6ndrede grupper har. Der er to undergrupper: de der er faldet v\u00e6k, og de der er kommet tilbage. Vi ser p\u00e5, hvilket bidrag de har til det samlede billede. <\/p>\n<p><\/p>\n<p><em>Er du ikke bange for, at den vil blive behandlet to-tre gange mellem snapshots?<\/em><\/p>\n<p><\/p>\n<p>Det vil sige, de registrerede sig igen, eller hvordan?<\/p>\n<p><\/p>\n<p><em>For eksempel, denne foresp\u00f8rgsel blev allerede udelukket \u00e9n gang, s\u00e5 kom den tilbage og blev udelukket igen, og s\u00e5 kom den tilbage igen og blev udelukket. Og hvad har du s\u00e5 talt med? Hvor er alt det?<\/em><\/p>\n<p><\/p>\n<p>Godt sp\u00f8rgsm\u00e5l, vi skal kigge p\u00e5 det. <\/p>\n<p><\/p>\n<p><em>Jeg har lavet noget lignende. Naturligvis var jeg alene om det, og det var simplere. Men jeg m\u00e5tte nulstille, lave reset stat_statements og orientere mig p\u00e5 tidspunktet for snapshot, s\u00e5 der var mindre end en bestemt andel, hvilket stadig ikke n\u00e5ede loftet, hvor mange stat_statements der kan akkumuleres. Og jeg orienterer mig efter, at der sandsynligvis ikke er noget, der er blevet udelukket.<\/em> <\/p>\n<p><\/p>\n<p>Ja- ja. <\/p>\n<p><\/p>\n<p><em>Men hvordan kan man ellers g\u00f8re det p\u00e5 en p\u00e5lidelig m\u00e5de, forst\u00e5r jeg ikke.<\/em><\/p>\n<p><\/p>\n<p>Desv\u00e6rre kan jeg ikke huske pr\u00e6cist \u2013 bruger vi teksten i foresp\u00f8rgslen eller queryid fra pg_stat_statements og orienterer os efter det. Hvis vi orienterer os efter queryid, s\u00e5 sammenligner vi principielt sammenlignelige ting. <\/p>\n<p><\/p>\n<p><em>Nej, den kan blive overskrevet flere gange mellem snapshots og komme tilbage igen.<\/em><\/p>\n<p><\/p>\n<p>Med denne id?<\/p>\n<p><\/p>\n<p><em>Ja.<\/em> <\/p>\n<p><\/p>\n<p>Vi vil unders\u00f8ge det. Godt sp\u00f8rgsm\u00e5l. Vi skal se n\u00e6rmere p\u00e5 det. Men indtil videre ser det ud til, at vi enten skriver 0\u2026<\/p>\n<p><\/p>\n<p><em>Det er selvf\u00f8lgelig en sj\u00e6lden situation, men jeg blev rystet, da jeg fandt ud af, at stat_statements kan blive overskrevet.<\/em> <\/p>\n<p><\/p>\n<p>Der kan v\u00e6re meget i Pg_stat_statements. Vi har oplevet, at hvis track_utility = on, s\u00e5 bliver dine sets ogs\u00e5 tracket. <\/p>\n<p><\/p>\n<p><em>Ja, selvf\u00f8lgelig.<\/em><\/p>\n<p><\/p>\n<p>Og hvis du har java hibernate, som er tilf\u00e6ldig, s\u00e5 begynder hash-tabellen at blive l\u00e5st. Og s\u00e5 snart du deaktiverer en meget belastet applikation, ender du med 50-100 grupper. Og s\u00e5 er alt mere eller mindre stabilt. En af m\u00e5derne at bek\u00e6mpe dette p\u00e5 er at \u00f8ge pg_stat_statements.max. <\/p>\n<p><\/p>\n<p><em>Ja, men det er vigtigt at vide, hvor meget. Og man skal holde \u00f8je med det. Det g\u00f8r jeg ogs\u00e5. Det vil sige, at jeg har pg_stat_statements.max. Og jeg ser, at jeg ikke n\u00e5ede 70 % ved snapshot tidspunktet. Godt, s\u00e5 vi har ikke mistet noget. Vi laver reset. Og samler op igen. Hvis det i det n\u00e6ste snapshot er under 70, s\u00e5 har vi sandsynligvis heller ikke mistet noget.<\/em><\/p>\n<p><\/p>\n<p>Ja. Som standard er det nu 5.000. Og mange har rigeligt med det. <\/p>\n<p><\/p>\n<p><em>Normalt \u2013 ja.<\/em> <\/p>\n<p><\/p>\n<p>Video:<\/p>\n<p>\n<center><div class=\"youtube-placeholder\" data-id=\"yvO1jjG-tDI\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/yvO1jjG-tDI\/hqdefault.jpg\" alt=\"Afspil video\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<p>P.S. Jeg vil tilf\u00f8je, at hvis der er fortrolige oplysninger i Postgres, som ikke m\u00e5 komme ind i testmilj\u00f8et, kan man benytte <noindex><a rel=\"nofollow\" href=\"https:\/\/labs.dalibo.com\/postgresql_anonymizer\">PostgreSQL Anonymizer<\/a><\/noindex>. Skemaet er cirka f\u00f8lgende:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser.&quot; Nikolai Samokhvalov\" src=\"\/wp-content\/uploads\/2020\/04\/cf9a2052364e09a20e68d2347dd0c25b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/498060\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u0441 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u043e\u0439 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u041d\u0438\u043a\u043e\u043b\u0430\u044f \u0421\u0430\u043c\u043e\u0445\u0432\u0430\u043b\u043e\u0432\u0430 &quot;\u041f\u0440\u043e\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u044b\u0439 \u043f\u043e\u0434\u0445\u043e\u0434 \u043a \u0442\u044e\u043d\u0438\u043d\u0433\u0443 PostgreSQL: \u044d\u043a\u0441\u043f\u0435\u0440\u0438\u043c\u0435\u043d\u0442\u044b \u043d\u0430\u0434 \u0431\u0430\u0437\u0430\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u0445&quot; Shared_buffers = 25% \u2013 \u044d\u0442\u043e \u043c\u043d\u043e\u0433\u043e \u0438\u043b\u0438 \u043c\u0430\u043b\u043e? \u0418\u043b\u0438 \u0432 \u0441\u0430\u043c\u044b\u0439 \u0440\u0430\u0437? \u041a\u0430\u043a \u043f\u043e\u043d\u044f\u0442\u044c, \u043f\u043e\u0434\u0445\u043e\u0434\u0438\u0442 \u043b\u0438 \u044d\u0442\u0430 \u2013 \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0443\u0441\u0442\u0430\u0440\u0435\u0432\u0448\u0430\u044f \u2013 \u0440\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0430\u0446\u0438\u044f \u0432 \u0432\u0430\u0448\u0435\u043c \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435? \u041f\u0440\u0438\u0448\u043b\u043e \u0432\u0440\u0435\u043c\u044f \u043f\u043e\u0434\u043e\u0439\u0442\u0438 \u043a \u0432\u043e\u043f\u0440\u043e\u0441\u0443 \u043f\u043e\u0434\u0431\u043e\u0440\u0430 \u043f\u0430\u0440\u0430\u043c\u0435\u0442\u0440\u043e\u0432 postgresql.conf &quot;\u043f\u043e-\u0432\u0437\u0440\u043e\u0441\u043b\u043e\u043c\u0443&quot;. \u041d\u0435 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0441\u043b\u0435\u043f\u044b\u0445 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":78743,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-78742","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u0441 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u043e\u0439 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u041d\u0438\u043a\u043e\u043b\u0430\u044f \u0421\u0430\u043c\u043e\u0445\u0432\u0430\u043b\u043e\u0432\u0430 &quot;\u041f\u0440\u043e\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u044b\u0439 \u043f\u043e\u0434\u0445\u043e\u0434 \u043a \u0442\u044e\u043d\u0438\u043d\u0433\u0443 PostgreSQL: \u044d\u043a\u0441\u043f\u0435\u0440\u0438\u043c\u0435\u043d\u0442\u044b \u043d\u0430\u0434 \u0431\u0430\u0437\u0430\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u0445&quot; Shared_buffers = 25% \u2013 \u044d\u0442\u043e \u043c\u043d\u043e\u0433\u043e \u0438\u043b\u0438 \u043c\u0430\u043b\u043e?\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/promyshlennyj-podhod-k-tyuningu-postgresql-eksperimenty-nad-bazami-dannyh-nikolaj-samohvalov\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u0440\u043e\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u044b\u0439 \u043f\u043e\u0434\u0445\u043e\u0434 \u043a \u0442\u044e\u043d\u0438\u043d\u0433\u0443 PostgreSQL: \u044d\u043a\u0441\u043f\u0435\u0440\u0438\u043c\u0435\u043d\u0442\u044b \u043d\u0430\u0434 \u0431\u0430\u0437\u0430\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u0445\u00bb. \u041d\u0438\u043a\u043e\u043b\u0430\u0439 \u0421\u0430\u043c\u043e\u0445\u0432\u0430\u043b\u043e\u0432 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u0441 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u043e\u0439 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u041d\u0438\u043a\u043e\u043b\u0430\u044f \u0421\u0430\u043c\u043e\u0445\u0432\u0430\u043b\u043e\u0432\u0430 &quot;\u041f\u0440\u043e\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u044b\u0439 \u043f\u043e\u0434\u0445\u043e\u0434 \u043a \u0442\u044e\u043d\u0438\u043d\u0433\u0443 PostgreSQL: \u044d\u043a\u0441\u043f\u0435\u0440\u0438\u043c\u0435\u043d\u0442\u044b \u043d\u0430\u0434 \u0431\u0430\u0437\u0430\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u0445&quot; Shared_buffers = 25% \u2013 \u044d\u0442\u043e \u043c\u043d\u043e\u0433\u043e \u0438\u043b\u0438 \u043c\u0430\u043b\u043e?\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/promyshlennyj-podhod-k-tyuningu-postgresql-eksperimenty-nad-bazami-dannyh-nikolaj-samohvalov\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-04-21T17:42:46+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-04-21T17:42:46+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser\u00bb. Nikolai Samokhvalov | ProHoster","description":"Jeg foresl\u00e5r, at I kigger p\u00e5 afkodningen af Nikolai Samokhvalovs foredrag \"Industriel tilgang til tuning af PostgreSQL: eksperimenter med databaser\" Shared_buffers = 25% \u2013 er det meget eller lidt?","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/promyshlennyj-podhod-k-tyuningu-postgresql-eksperimenty-nad-bazami-dannyh-nikolaj-samohvalov","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0440\u043e\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u044b\u0439 \u043f\u043e\u0434\u0445\u043e\u0434 \u043a \u0442\u044e\u043d\u0438\u043d\u0433\u0443 PostgreSQL: \u044d\u043a\u0441\u043f\u0435\u0440\u0438\u043c\u0435\u043d\u0442\u044b \u043d\u0430\u0434 \u0431\u0430\u0437\u0430\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u0445\u00bb. \u041d\u0438\u043a\u043e\u043b\u0430\u0439 \u0421\u0430\u043c\u043e\u0445\u0432\u0430\u043b\u043e\u0432 | ProHoster","og:description":"\u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u0441 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u043e\u0439 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u041d\u0438\u043a\u043e\u043b\u0430\u044f \u0421\u0430\u043c\u043e\u0445\u0432\u0430\u043b\u043e\u0432\u0430 &quot;\u041f\u0440\u043e\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u044b\u0439 \u043f\u043e\u0434\u0445\u043e\u0434 \u043a \u0442\u044e\u043d\u0438\u043d\u0433\u0443 PostgreSQL: \u044d\u043a\u0441\u043f\u0435\u0440\u0438\u043c\u0435\u043d\u0442\u044b \u043d\u0430\u0434 \u0431\u0430\u0437\u0430\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u0445&quot; Shared_buffers = 25% \u2013 \u044d\u0442\u043e \u043c\u043d\u043e\u0433\u043e \u0438\u043b\u0438 \u043c\u0430\u043b\u043e?","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/promyshlennyj-podhod-k-tyuningu-postgresql-eksperimenty-nad-bazami-dannyh-nikolaj-samohvalov","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-04-21T17:42:46+00:00","article:modified_time":"2020-04-21T17:42:46+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"78742","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 16:51:38","updated":"2022-09-28 02:51:26","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/78742","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=78742"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/78742\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/78743"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=78742"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=78742"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=78742"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}