Индустриален подход за настройка на PostgreSQL: експерименти с бази данни.“ Николай Самохвалов

Предлагам ви да прочетете стенограмата на доклада на Николай Самохвалов „Индустриален подход за настройка на PostgreSQL: експерименти върху бази данни“

Shared_buffers = 25% – много ли е или малко? Или точно така? Как да разберете дали тази - доста остаряла - препоръка е подходяща във вашия конкретен случай?

Време е да подходим към въпроса за избора на параметри на postgresql.conf „като възрастен“. Не с помощта на слепи "авто тунери" или остарели съвети от статии и блогове, а въз основа на:

1. строго проверени експерименти върху бази данни, извършвани автоматично, в големи количества и при условия, максимално близки до „бойните“,
2. дълбоко разбиране на характеристиките на СУБД и ОС.

Използване на Nancy CLI (https://gitlab.com/postgres.ai/nancy), ще разгледаме конкретен пример - прословутите shared_buffers - в различни ситуации, в различни проекти и ще се опитаме да разберем как да изберем оптималната настройка за нашата инфраструктура, база данни и натоварване.

Ще говорим за експерименти с бази данни. Това е история, която продължава малко повече от шест месеца.

Малко за мен. Опит с Postgres повече от 14 години. Създадени са редица компании за социални мрежи. Postgres беше и се използва навсякъде.

Също така групата RuPostgres на Meetup, 2-ро място в света. Бавно наближаваме 2 души. RuPostgres.org.

И на компютри на различни конференции, включително Highload, аз отговарям за бази данни, по-специално Postgres от самото начало.

И през последните няколко години рестартирах консултантската си практика в Postgres 11 часови зони от тук.

И когато направих това преди няколко години, имах известна пауза в активната ръчна работа с Postgres, вероятно от 2010 г. Бях изненадан колко малко се е променила работната рутина на DBA и колко ръчен труд все още трябва да се използва. И веднага си помислих, че тук нещо не е наред, трябва да автоматизирам повече от всичко.

И тъй като всичко беше дистанционно, повечето клиенти бяха в облаците. И много вече са автоматизирани, очевидно. Повече за това по-късно. Тоест всичко това доведе до идеята, че трябва да има редица инструменти, т.е. някаква платформа, която да автоматизира почти всички действия на DBA, така че да могат да се управляват голям брой бази данни.

Този отчет няма да включва:

• „Сребърни куршуми“ и твърдения като - задайте 8 GB или 25% shared_buffers и ще се оправите. Няма да има много за shared_buffers.
• Хардкор "вътрешности".

Какво ще се случи?

• Ще има принципи за оптимизация, които прилагаме и развиваме. Ще има всякакви идеи, които възникват по пътя, и различни инструменти, които създаваме в по-голямата си част в Open Source, т.е. ние правим основата в Open Source. Освен това имаме билети, цялата комуникация е практически с отворен код. Можете да видите какво правим сега, какво ще бъде в следващото издание и т.н.
• Ще има и известен опит в използването на тези принципи, тези инструменти в редица компании: от малки стартиращи фирми до големи компании.

Как се развива всичко това?

Първо, основната задача на DBA, в допълнение към осигуряването на създаване на екземпляри, внедряване на резервни копия и т.н., е да намира тесни места и да оптимизира производителността.

Сега е настроен така. Гледаме мониторинга, виждаме нещо, но ни липсват някои подробности. Започваме да копаем по-внимателно, обикновено с ръце, и разбираме какво да правим с него по един или друг начин.

И има два подхода. Pg_stat_statements е решението по подразбиране за идентифициране на бавни заявки. И анализ на регистрационни файлове на Postgres с помощта на pgBadger.

Всеки подход има сериозни недостатъци. При първия подход сме изхвърлили всички параметри. И ако видим групите SELECT * FROM таблица, където колоната е равна на "?" или “$” от Postgres 10. Не знаем дали това е сканиране на индекс или сканиране на seq. Много зависи от параметъра. Ако замените рядко срещана стойност там, това ще бъде сканиране на индекс. Ако замените стойност, която заема 90% от таблицата там, сканирането на seq ще бъде очевидно, защото Postgres знае статистиката. И това е голям недостатък на pg_stat_statements, въпреки че е в ход известна работа.

Най-големият недостатък на анализа на журнала е, че не можете да си позволите "log_min_duration_statement = 0" като правило. И ще говорим и за това. Съответно не виждате цялата картина. И някои заявки, които са много бързи, може да консумират огромно количество ресурси, но вие няма да ги видите, защото са под вашия праг.

Как администраторите на бази данни решават проблемите, които откриват?

Например, открихме някакъв проблем. Какво се прави обикновено? Ако сте разработчик, тогава ще правите нещо на някакъв екземпляр, който не е със същия размер. Ако сте DBA, тогава имате етап. И може да бъде само един. И той изостана с шест месеца. И мислиш, че ще отидеш на производство. И дори опитни администратори на бази данни след това проверяват производството на реплика. И се случва да създадат временен индекс, да се уверят, че помага, да го изпуснат и да го дадат на разработчиците, за да могат да го поставят във файловете за миграция. Ето такива глупости се случват сега. И това е проблем.

• Настройка на конфигурации.
• Оптимизирайте набора от индекси.
• Променете самата SQL заявка (това е най-трудният метод).
• Добавете капацитет (най-лесният начин в повечето случаи).

Има много неща, които се случват с тези неща. В Postgres има много манипулатори. Има много да се знае. В Postgres има много индекси, благодарение и на организаторите на тази конференция. И всичко това трябва да се знае и това кара не-DBA да се чувстват сякаш DBA практикуват черна магия. Тоест трябва да учиш 10 години, за да започнеш да разбираш всичко това нормално.

И аз съм борец срещу тази черна магия. Искам да направя всичко така, че да има технология и да няма интуиция във всичко това.

Примери от живота

Наблюдавах това в поне два проекта, включително моя собствен. Друга публикация в блога ни казва, че стойност от 1 за default_statistict_target е добра. Добре, нека го пробваме в производството.

И ето ни тук, използвайки нашия инструмент две години по-късно, с помощта на експерименти върху базите данни, за които говорим днес, можем да сравним какво е било и какво е станало.

И за това трябва да създадем експеримент. Състои се от четири части.

• Първият е околната среда. Имаме нужда от хардуер. И когато дойда в някоя фирма и подпиша договор, им казвам да ми дадат същия хардуер, както е в производство. За всеки от вашите учители ми трябва поне един хардуер като този. Или това е екземплярна виртуална машина в Amazon или Google, или имам нужда от абсолютно същия хардуер. Тоест искам да пресъздам средата. И в концепцията за среда включваме основната версия на Postgres.
• Втората част е обект на нашето изследване. Това е база данни. Може да се създаде по няколко начина. Ще ти покажа как.
• Третата част е натоварването. Това е най-трудният момент.
• И четвъртата част е какво проверяваме, т.е. какво с какво ще сравним. Да кажем, че можем да променим един или повече параметри в конфигурацията или можем да създадем индекс и т.н.

Започваме експеримент. Ето pg_stat_statements. Отляво е какво се случи. Вдясно - какво се случи.

Отляво default_statistics_target = 100, отдясно = 1. Виждаме, че това ни помогна. Като цяло всичко се подобри с 000%.

Но ако превъртим надолу, ще има групи от заявки от pgBadger или от pg_stat_statements. Има две възможности. Ще видим, че някои заявки са намалели с 88%. И тук идва инженерният подход. Можем да копаем още вътре, защото се чудим защо е потънало. Трябва да разберете какво се случи със статистиката. Защо повече кофи в статистиката водят до по-лоши резултати.

Или можем да не копаем, но да направим „ALTER TABLE ... ALTER COLUMN“ и да върнем 100 кофи обратно към статистиката на тази колона. И след това с друг експеримент можем да се уверим, че този пластир е помогнал. Всичко. Това е инженерен подход, който ни помага да видим голямата картина и да вземем решения въз основа на данни, а не на интуиция.

Няколко примера от други области. В продължение на много години има CI тестове. И нито един проект със здрав ум не би оцелял без автоматизирани тестове.

В други индустрии: в авиацията, в автомобилната индустрия, когато тестваме аеродинамиката, ние също имаме възможност да правим експерименти. Няма да изстреляме нещо от чертеж директно в космоса или няма веднага да изведем кола на пистата. Например, има аеродинамичен тунел.

Можем да направим изводи от наблюдения на други индустрии.

Първо, имаме специална среда. Близо е до производство, но не е близо. Основната му характеристика е, че трябва да бъде евтин, повторяем и възможно най-автоматизиран. Освен това трябва да има специални инструменти за извършване на подробен анализ.

Най-вероятно, когато стартираме самолет и летим, имаме по-малко възможности да изучаваме всеки милиметър от повърхността на крилото, отколкото имаме в аеродинамичен тунел. Имаме още инструменти за диагностика. Можем да си позволим да носим повече тежки неща, които не можем да си позволим да качим в самолет във въздуха. Същото с Postgres. В някои случаи може да активираме пълно регистриране на заявки по време на експерименти. И ние не искаме да правим това в производството. Може дори да планираме да активираме това с помощта на auto_explain.

И както казах, високо ниво на автоматизация означава, че натискаме бутона и повтаряме. Така трябва да бъде, за да има много експерименти, за да е на поток.

Nancy CLI - основата на „лабораторията за бази данни“

И така направихме това нещо. Тоест аз говорих за тези идеи през юни, преди почти година. И вече имаме така наречения Nancy CLI в Open Source. Това е основата за изграждане на лаборатория за база данни.

хомосексуалист — Това е с отворен код, в Gitlab. Можете да го кажете, можете да го опитате. Предоставих връзка в слайдовете. Можете да щракнете върху него и той ще бъде там помощ във всички отношения.

Разбира се, има още много в процес на разработка. Има много идеи там. Но това е нещо, което използваме почти всеки ден. И когато имаме идея - защо когато изтрием 40 000 000 реда, всичко се свежда до IO, тогава можем да направим експеримент и да разгледаме по-подробно, за да разберем какво се случва и след това да се опитаме да го поправим в движение. Тоест правим експеримент. Например, настройваме нещо и виждаме какво ще се случи накрая. И ние не правим това в производството. Това е същността на идеята.

Къде може да работи това? Това може да работи локално, т.е. можете да го направите навсякъде, можете дори да го стартирате на MacBook. Имаме нужда от докер, да вървим. Това е всичко. Можете да го стартирате в някакъв случай на част от хардуер или във виртуална машина, навсякъде.

Освен това има възможност за дистанционно стартиране в Amazon в EC2 инстанция, на места. И това е много готина възможност. Например, вчера проведохме повече от 500 експеримента на екземпляр i3, започвайки с най-младия и завършвайки с i3-16-xlarge. И 500 експеримента ни струват $64. Всеки продължи по 15 минути. Тоест, поради факта, че там се използват спотове, е много евтино - 70% отстъпка, таксуване на секунда на Amazon. Можете да направите много. Можете да направите истинско проучване.

Поддържат се и три основни версии на Postgres. Не е толкова трудно да завършите някои стари и новата 12-та версия също.

Можем да дефинираме обект по три начина. Това:

• Dump/sql файл.
• Основният начин е да клонирате директорията PGDATA. По правило се взема от резервния сървър. Ако имате нормални двоични архиви, можете да правите клонинги от там. Ако имате облаци, тогава облачен офис като Amazon и Google ще направи това вместо вас. Това е най-важният начин за клониране на реално производство. Ето как се разгръщаме.
• И последният метод е подходящ за изследване, когато искате да разберете как работи нещо в Postgres. Това е pgbench. Можете да генерирате с помощта на pgbench. Това е само една опция "db-pgbench". Ти му кажи какъв мащаб. И всичко ще бъде генерирано в облака, както е посочено.

И зареди:

• Можем да изпълним зареждането в една SQL нишка. Това е най-примитивният начин.
• И ние можем да емулираме товара. И можем да го емулираме първо по следния начин. Трябва да съберем всички трупи. И това е болезнено. Ще ти покажа защо. И използвайки pgreplay we play, който е вграден в Nancy.
• Или друг вариант. Така нареченото занаятчийско натоварване, което правим с определено усилие. Анализирайки нашето текущо натоварване на бойната система, ние изваждаме най-добрите групи заявки. И с помощта на pgbench можем да емулираме това натоварване в лабораторията.

• Или трябва да извършим някакъв вид SQL, т.е. проверяваме някакъв вид миграция, създаваме индекс там, изпълняваме ANALAZE там. И ние гледаме какво се е случило преди вакуума и след вакуума. Като цяло всеки SQL.
• Или променяме един или повече параметри в конфигурацията. Можем да ни кажем да проверим, например, 100 стойности в Amazon за нашата терабайтова база данни. И след няколко часа ще имате резултата. Като правило ще ви отнеме няколко часа, за да разположите терабайтова база данни. Но има кръпка в процес на разработка, имаме възможни серии, т.е. можете последователно да използвате едни и същи pgdata на същия сървър и да проверявате. Postgres ще се рестартира и кешовете ще бъдат нулирани. И можете да карате товара.

• Пристига директория с куп различни файлове, като се започне от моментни снимки на pgStat***. И най-интересното нещо там е pg_stat_statements, pg_stat_kcacke. Това са две разширения, които анализират заявки. И pg_stat_bgwriter съдържа не само статистика на pgwriter, но също и контролна точка и как самите бекендове изместват мръсните буфери. И всичко това е интересно да се види. Например, когато настройваме shared_buffers, е много интересно да видим колко са заменили всички.
• Пристигат и регистрационни файлове на Postgres. Два лога – дневник за подготовка и дневник за възпроизвеждане на зареждане.
• Сравнително нова функция е FlameGraphs.
• Освен това, ако сте използвали опциите pgreplay или pgbench за възпроизвеждане на товара, тогава техният изход ще бъде естествен. И ще видите латентност и TPS. Ще може да се разбере как са го видели.
• Системна информация.
• Основни проверки на процесора и IO. Това е повече за екземпляр на EC2 в Amazon, когато искате да стартирате 100 идентични екземпляра в нишка и да изпълните 100 различни изпълнения там, тогава ще имате 10 000 експеримента. И трябва да сте сигурни, че няма да попаднете на погрешен екземпляр, който вече е потискан от някого. Други са активни на тази част от хардуера и вие имате малко останал ресурс. По-добре е да отхвърлите такива резултати. И с помощта на sysbench от Алексей Копитов правим няколко кратки проверки, които ще дойдат и могат да бъдат сравнени с други, т.е. ще разберете как се държи процесорът и как се държи IO.

Какви са техническите трудности въз основа на примера на различни компании?

Да кажем, че искаме да повторим реалното натоварване с помощта на регистрационни файлове. Страхотна идея е, ако е написано на pgreplay с отворен код. Ние го използваме. Но за да работи добре, трябва да активирате пълно регистриране на заявки с параметри и време.

Има някои усложнения с продължителността и времевия печат. Ще изпразним цялата тази кухня. Основният въпрос е дали можете да си го позволите или не?

https://gist.github.com/NikolayS/08d9b7b4845371d03e195a8d8df43408

Проблемът е, че може да не е наличен. На първо място, трябва да разберете какъв поток ще бъде записан в дневника. Ако имате pg_stat_statements, можете да използвате тази заявка (връзката ще бъде налична в слайдовете), за да разберете приблизително колко байта ще бъдат записани в секунда.

Гледаме дължината на заявката. Пренебрегваме факта, че няма параметри, но знаем дължината на заявката и знаем колко пъти в секунда е била изпълнена. По този начин можем да изчислим приблизително колко байта в секунда. Може да сгрешим два пъти повече, но със сигурност ще разберем реда по този начин.

Виждаме, че тази заявка се изпълнява 802 пъти в секунда. И виждаме, че bytes_per sec – 300 kB/s ще бъде записано плюс или минус. И като правило можем да си позволим такъв поток.

Но! Факт е, че има различни системи за регистриране. И хората по подразбиране обикновено са "syslog".

И ако имате syslog, тогава може да имате снимка като тази. Ще вземем pgbench, ще активираме записването на заявки и ще видим какво ще се случи.

Без логване - това е колоната отляво. Имаме 161 000 TPS. Със syslog - това е в Ubuntu 16.04 на Amazon, получаваме 37 000 TPS. И ако променим два други метода за регистриране, тогава ситуацията е много по-добра. Тоест очаквахме да спадне, но не в същата степен.

И на CentOS 7, в който journald също участва, превръщайки регистрационни файлове в двоичен формат за лесно търсене и т.н., тогава това е кошмар там, пускаме 44 пъти в TPS.

И това е, с което хората живеят. И често в компании, особено големи, това е много трудно да се промени. Ако можете да се измъкнете от syslog, моля, махнете се от него.

• Оценете IOPS и потока на запис.
• Проверете вашата система за регистриране.
• Ако предвиденото натоварване е прекалено голямо, помислете за вземане на проби.

Имаме pg_stat_statements. Както казах, трябва да е там. И можем да вземем и опишем всяка група заявки по специален начин във файл. И тогава можем да използваме много удобна функция в pgbench - това е възможността да вмъкнете няколко файла с помощта на опцията „-f“.

Разбира много "-f". И можете да кажете с помощта на “@” в края какъв дял трябва да има всеки файл. Тоест можем да кажем, че правете това в 10% от случаите, а това в 20%. И това ще ни доближи до това, което виждаме в производството.

Как ще разберем какво имаме в производството? Какъв дял и как? Това е малко настрана. Имаме още един продукт postgres-проверка. Също така база в Open Source. И сега активно го развиваме.

Той е роден по малко по-различни причини. Поради причини, че наблюдението не е достатъчно. Тоест идвате, разглеждате базата, разглеждате проблемите, които съществуват. И като правило правите проверка на здравето. Ако сте опитен DBA, тогава правете health_check. Разгледахме използването на индекси и т.н. Ако имате OKmeter, тогава страхотно. Това е страхотен мониторинг за Postgres. OKmeter.io – моля, инсталирайте го, там всичко е направено много добре. Платено е.

Ако нямате такъв, тогава обикновено нямате много. При мониторинга обикновено има CPU, IO и след това с резерви и това е всичко. И имаме нужда от повече. Трябва да видим как работи автовакуумът, как работи контролната точка, в io трябва да отделим контролната точка от bgwriter и от задните части и т.н.

Проблемът е, че когато помагаш на голяма компания, тя не може да внедри нещо бързо. Те не могат бързо да купят OKmeter. Може би ще го купят след шест месеца. Те не могат бързо да доставят някои пакети.

И ние стигнахме до идеята, че имаме нужда от специален инструмент, който не изисква нищо да бъде инсталирано, т.е. не е нужно да инсталирате нищо в производството. Инсталирайте го на вашия лаптоп или на сървър за наблюдение, откъдето ще го стартирате. И ще анализира много неща: операционната система, файловата система и самия Postgres, като прави някои леки заявки, които могат да бъдат стартирани директно в производството и нищо няма да се провали.

Нарекохме го Postgres-checkup. От медицинска гледна точка това е редовен здравен преглед. Ако е на автомобилна тематика, тогава е като поддръжка. Правите поддръжка на колата си на всеки шест месеца или година, в зависимост от марката. Правите ли поддръжка на вашата база? Тоест правите ли задълбочени изследвания редовно? Трябва да се направи. Ако правите резервни копия, след това направете проверка, това е не по-малко важно.

И ние имаме такъв инструмент. Започна активно да се появява едва преди около три месеца. Той е още млад, но има много неща.

Събиране на най-„влиятелните“ групи от заявки - отчет K003 в Postgres-checkup

И има група доклади K. Три доклада досега. И има такъв доклад K003. Има горната част от pg_stat_statements, сортирани по total_time.

Когато сортираме групите заявки по total_time, най-отгоре виждаме групата, която натоварва системата ни най-много, т.е. консумира повече ресурси. Защо наименувам групи заявки? Защото изхвърлихме параметрите. Това вече не са заявки, а групи от заявки, т.е. те са абстрахирани.

И ако оптимизираме отгоре надолу, ще облекчим ресурсите си и ще отложим момента, в който трябва да надстроим. Това е много добър начин да спестите пари.

Може би това не е много добър начин да се грижим за потребителите, защото може да не видим редки, но много досадни случаи, когато човек чака 15 секунди. Като цяло те са толкова редки, че не ги виждаме, но имаме работа с ресурси.

Какво се случи в тази таблица? Направихме две моментни снимки. Postgres_checkup ще ви даде делта за всеки показател: общо време, повиквания, редове, shared_blks_read и т.н. Това е, делтата е изчислена. Големият проблем с pg_stat_statements е, че той не помни кога е бил нулиран. Ако pg_stat_database помни, тогава pg_stat_statements не помни. Виждате, че има число от 1 000 000, но не знаем откъде броим.

И тук знаем, тук имаме две моментни снимки. Знаем, че делтата в този случай е 56 секунди. Много кратък интервал. Сортирано по total_time. И тогава можем да диференцираме, т.е. разделяме всички показатели по продължителност. Ако разделим всеки показател на продължителност, ще имаме броя обаждания в секунда.

След това, total_time per second е любимият ми показател. Измерва се в секунди за секунда, т.е. колко секунди са отнели на системата ни да изпълни тази група заявки за секунда. Ако видите повече от секунда в секунда там, това означава, че трябва да дадете повече от едно ядро. Това е много добър показател. Можете да разберете, че този приятел например се нуждае от поне три ядра.

Това е нашето ноу-хау, такова нещо не съм виждал никъде. Моля, обърнете внимание - това е много просто нещо - секунда в секунда. Понякога, когато вашият процесор е 100%, тогава половин час в секунда, тоест сте прекарали половин час, изпълнявайки само тези заявки.

След това виждаме редове в секунда. Знаем колко реда в секунда е върнало.

И тогава има и нещо интересно. Колко shared_buffers четем за секунда от самите shared_buffers. Попаденията вече бяха налице и ние взехме редовете от кеша на операционната система или от диска. Първият вариант е бърз, а вторият може да бъде или да не е бърз, в зависимост от ситуацията.

И вторият начин за диференциране е да се раздели броят на заявките в тази група. Във втората колона винаги ще имате по една заявка, разделена на заявка. И тогава е интересно - колко милисекунди са били в тази заявка. Знаем как се държи тази заявка средно. За всяка заявка бяха необходими 101 милисекунди. Това е традиционната метрика, която трябва да разберем.

Колко реда е върнала средно всяка заявка? Виждаме 8, че тази група се завръща. Средно колко е взето от кеша и прочетено. Виждаме, че всичко е кеширано добре. Солидни попадения за първа група.

И четвъртият подниз във всеки ред е какъв процент от общата сума. Имаме обаждания. Да кажем 1 000 000. И можем да разберем какъв принос има тази група. Виждаме, че в този случай първата група допринася с по-малко от 0,01%. Тоест толкова е бавен, че не го виждаме в общата картина. И втората група е 5% на разговори. Тоест 5% от всички обаждания са втората група.

Total_time също е интересно. Прекарахме 14% от общото си работно време за първата група заявки. А за второто - 11% и т.н.

Няма да навлизам в подробности, но има тънкости. Показваме грешка в горната част, тъй като когато сравняваме, моментните снимки може да изплуват, т.е. някои заявки може да изпаднат и вече не могат да присъстват във втората, докато някои нови могат да се появят. И там изчисляваме грешката. Ако видите 0, това е добре. Няма никакви грешки. Ако процентът на грешка е до 20%, всичко е наред.

След това се връщаме към нашата тема. Трябва да изработим натоварването. Взимаме го отгоре надолу и вървим, докато достигнем 80% или 90%. Обикновено това са 10-20 групи. И ние правим файлове за pgbench. Ние използваме произволни там. Понякога това, за съжаление, не се получава. И в Postgres 12 ще има повече възможности за използване на този подход.

И след това печелим 80-90% общо време по този начин. Какво следва да поставя след „@“? Ние гледаме обажданията, гледаме колко лихви има и разбираме, че дължим толкова много лихви тук. От тези проценти можем да разберем как да балансираме всеки от файловете. След това използваме pgbench и отиваме на работа.

Имаме и K001 и K002.

K001 е един голям низ с четири подниза. Това е характеристика на целия ни товар. Вижте втората колона и втория подред. Виждаме, че около една секунда и половина в секунда, т.е. ако има две ядра, тогава ще е добре. Ще има приблизително 75% капацитет. И ще работи така. Ако имаме 10 ядра, тогава като цяло ще сме спокойни. По този начин можем да оценим ресурсите.

K002 е това, което аз наричам класове на заявки, т.е. ИЗБЕРЕТЕ, ВМЪКНЕТЕ, АКТУАЛИЗИРАНЕ, ИЗТРИВАНЕ. И отделно SELECT FOR UPDATE, защото е заключване.

И тук можем да заключим, че SELECT е обикновен читател - 82% от всички обаждания, но в същото време - 74% в total_time. Тоест, те се наричат ​​​​много, но консумират по-малко ресурси.

И се връщаме на въпроса: „Как можем да изберем правилните shared_buffers?“ Забелязвам, че повечето бенчмаркове се основават на идеята - да видим каква ще бъде пропускателната способност, т.е. каква ще бъде пропускателната способност. Обикновено се измерва в TPS или QPS.

И ние се опитваме да изтръгнем възможно най-много транзакции в секунда от колата, използвайки параметри за настройка. Ето точно 311 в секунда за избрани.

Но никой не кара до работа и обратно вкъщи с пълна скорост. Това е глупаво. Същото с базите данни. Не е нужно да караме с пълна скорост и никой не го прави. Никой не живее в производство, което има 100% CPU. Въпреки че може би някой живее, но това не е добре.

Идеята е, че обикновено караме с 20 процента от капацитета, за предпочитане не повече от 50%. И ние се опитваме да оптимизираме времето за реакция преди всичко за нашите потребители. Тоест трябва да си завъртим копчетата, за да има минимална латентност при 20% скорост, условно. Това е идея, която ние също се опитваме да използваме в нашите експерименти.

И накрая препоръки:

• Задължително направете Database Lab.
• Ако е възможно, направете го при поискване, така че да се разгъне за известно време - играйте и го изхвърлете. Ако имате облаци, тогава това се разбира, т.е. имайте много правостоящи.
• Бъди любопитен. И ако нещо не е наред, проверете с експерименти как се държи. Нанси може да се използва, за да се обучите, за да проверите как работи базата.
• И се стремете към минимално време за реакция.
• И не се страхувайте от източниците на Postgres. Когато работите с източници, трябва да знаете английски. Там има много коментари, там всичко е обяснено.
• И проверявайте изправността на базата данни редовно, поне веднъж на всеки три месеца, ръчно или Postgres-checkup.

Въпроси

Благодаря много! Много интересно нещо.

Две парчета.

Да, два броя. Само дето не разбрах много. Когато Нанси и аз работим, можем ли да променяме само един параметър или цяла група?

Имаме делта конфигурационен параметър. Можете да се обърнете там колкото искате наведнъж. Но трябва да разберете, че когато промените много неща, можете да направите грешни изводи.

да Защо попитах? Защото е трудно да се провеждат експерименти, когато имате само един параметър. Стегнете го, вижте как работи. Изгоних го. След това започвате следващия.

Можете да го стегнете едновременно, но зависи от ситуацията, разбира се. Но е по-добре да тествате една идея. Вчера ни хрумна идея. Имахме много близка ситуация. Имаше две конфигурации. И не можахме да разберем защо има голяма разлика. И възникна идеята, че трябва да използвате дихотомията, за да разберете последователно и да откриете каква е разликата. Можете веднага да направите половината от параметрите еднакви, след това една четвърт и т.н. Всичко е гъвкаво.

И има още един въпрос. Проектът е млад и се развива. Документацията вече е готова, има ли подробно описание?

Специално направих линк там към описанието на параметрите. Там ли е. Но много неща все още ги няма. Търся съмишленици. И ги намирам, когато изпълнявам. Това е много яко. Някой вече работи с мен, някой помогна и направи нещо там. И ако се интересувате от тази тема, дайте обратна връзка какво липсва.

След като изградим лабораторията, може би ще има обратна връзка. Да видим. Благодаря ти!

Здравейте! Благодаря за доклада! Видях, че има поддръжка на Amazon. Има ли планове за подкрепа на GSP?

Добър въпрос. Започнахме да го правим. И ние го замразихме засега, защото искаме да спестим пари. Тоест има поддръжка за използване на run on localhost. Можете сами да създадете екземпляр и да работите локално. Между другото, това е, което правим. Правя това в Getlab, там в GSP. Но все още не виждаме смисъл да правим точно такава оркестрация, защото Google няма евтини места. Има ??? случаи, но те имат ограничения. Първо, те винаги имат само 70% отстъпка и не можете да си играете с цената там. На спотове увеличаваме цената с 5-10%, за да намалим вероятността да бъдете ритнати. Тоест спестявате петна, но те могат да ви бъдат отнети по всяко време. Ако наддавате малко по-високо от другите, ще бъдете убит по-късно. Google има съвсем друга специфика. И има още едно много лошо ограничение - живеят само 24 часа. И понякога искаме да проведем експеримент за 5 дни. Но можете да направите това на петна; петната понякога продължават с месеци.

Здравейте! Благодаря за доклада! Споменахте преглед. Как изчислявате грешките на stat_statements?

Много добър въпрос. Мога да ви покажа и разкажа много подробно. Накратко, разглеждаме как се е движил наборът от групи заявки: колко са паднали и колко нови са се появили. След това разглеждаме два показателя: total_time и calls, така че има две грешки. И ние разглеждаме приноса на плаващите групи. Има две подгрупи: заминали и пристигнали. Да видим какъв е приносът им към общата картина.

Не се ли страхувате, че ще се обърне там два или три пъти през времето между моментните снимки?

Тоест пак ли се регистрираха или какво?

Например, тази заявка вече е била изпреварвана веднъж, след това е пристигнала и е била изпреварена отново, след това е дошла отново и е била изпреварена отново. И ти си изчислил нещо тук и къде е всичко?

Добър въпрос, ще трябва да потърсим.

Аз направих подобно нещо. Беше по-просто, разбира се, направих го сам. Но трябваше да нулирам, да нулирам stat_statements и да разбера по време на моментната снимка, че има по-малко от определена част, която все още не достига тавана на това колко stat_statements могат да се натрупат там. И моето разбиране е, че най-вероятно нищо не е изместено.

Да да.

Но не разбирам как иначе да го направя надеждно.

За съжаление, не помня точно дали използваме текста на заявката там или queryid с pg_stat_statements и се фокусираме върху него. Ако се фокусираме върху queryid, тогава на теория сравняваме сравними неща.

Не, той може да бъде изгонен няколко пъти между моментните снимки и да дойде отново.

Със същия идентификатор?

Да.

Ще проучим това. Добър въпрос. Трябва да го проучим. Но засега това, което виждаме, е или написано 0...

Това, разбира се, е рядък случай, но бях шокиран, когато разбрах, че stat_statemetns може да измести там.

Може да има много неща в Pg_stat_statements. Натъкнахме се на факта, че ако сте включили track_utility =, вашите набори също се проследяват.

Да, разбира се.

И ако имате java hibernate, което е произволно, тогава хеш-таблицата започва да се намира там. И щом изключите много натоварено приложение, накрая имате 50-100 групи. И там всичко е повече или по-малко стабилно. Един от начините за борба с това е да увеличите pg_stat_statements.max.

Да, но трябва да знаете колко. И по някакъв начин трябва да го държим под око. Аз това правя. Тоест имам pg_stat_statements.max. И виждам, че към момента на моментната снимка не бях достигнал 70%. Добре, значи не сме загубили нищо. Да нулираме. И пак спестяваме. Ако следващата снимка е по-малка от 70, най-вероятно не сте загубили нищо отново.

да По подразбиране вече е 5. И това е достатъчно за много хора.

Обикновено да.

Video:

PS От свое име ще добавя, че ако Postgres съдържа поверителни данни и не може да бъде включен в тестовата среда, можете да използвате Анонимизатор на PostgreSQL. Схемата е приблизително следната:

Източник: www.habr.com