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

Предлагам да се запознаете с интерпретацията на доклада на Николай Самохвалов "Промишлен подход към tuning на PostgreSQL: експерименти с бази данни"

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

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

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

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

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

Няколко думи за мен. Опитът ми с Postgres вече е повече от 14 години. Основах редица компании в социалните мрежи. Всякъде се използваше Postgres и все още се използва.

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

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

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

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

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

В този доклад няма да бъдат:

• «Сребърни куршуми» и заявления от типа – поставете 8 GB или 25 % shared_buffers и всичко ще е наред. За shared_buffers няма да говорим толкова много.
• Хардкорни «вътрешности».

Какво ще стане?

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

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

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

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

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

Всеки от подходите има сериозни недостатъци. Първият подход ни оставя без всички параметри. И ако видим групи SELECT * FROM table where колонка равно на знака «?» или «$» от версия Postgres 10 нататък, не знаем – дали е index scan или seq scan. Много зависи от параметъра. Ако поставите рядко срещано значение, ще бъде index scan. Ако поставите стойност, която заема 90 % от таблицата, очевидно ще бъде seq scan, защото Postgres познава статистиката. И това е голям недостатък на pg_stat_statements, въпреки че се работи по някои решения.

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

Как DBA решават откритите проблеми?

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

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

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

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

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

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

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

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

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

Стартираме експеримент. Ето pg_stat_statements. Отляво – какво беше. Отдясно – какво стана.

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

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

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

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

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

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

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

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

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

Nancy CLI – основата на „лабораторията на БД“

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

Nancy — Това е в Open Source, на Gitlab. Можете да кажете, можете да опитате. Дадох линк в слайдовете. Може да се кликне и там ще има help по всички параметри.

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

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

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

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

Обектът можем да зададем по три начина. Това е:

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

И натоварването:

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

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

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

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

Да предположим, че искаме да повтаряме реална натовареност с помощта на журнали. Отлична идея, ако е написана на Open Source pgreplay. Ние го използваме. Но, за да работи добре, трябва да включите пълното логиране на заявките с параметри и времеви показатели.

Има някои сложности относно duration и timestamp. Всичко това ще го пропуснем. Важният въпрос е – можете ли да си го позволите или не можете?

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 в Амазон имаме 37 000 TPS. А ако променим на два други начина на логиране, ситуацията става много по-добра. Т.е. очаквахме, че ще спадне, но не толкова.

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

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

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

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

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

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

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

Ако нямате такова нещо, обикновено нямате почти нищо. В мониторинга обикновено имате CPU, IO и то с уговорки, и това е всичко. А на нас ни трябва повече. Трябва да виждаме как работи автовакуум, как работи checkpoint, в IO трябва да отделим checkpoint от bgwriter и от бекендите и т.н.

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

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

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

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

Събираме най-влиятелните групи на заявки – отчет К003 в Postgres-checkup

И там има група отчети К. Три отчета до момента. И имаме такъв отчет К003. Там е върхът от pg_stat_statements, подреден по total_time.

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

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

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

Какво се случи в тази таблица? Направихме два снепшота. Postgres_checkup ще направи дельта за всяка метрика: по total-time, calls, rows, shared_blks_read и т.н. Всичко, дельтата е изчислена. Проблемът с pg_stat_statements е, че той не помни кога е бил reset. Ако pg_stat_database помни, то pg_stat_statements не помни. Виждате, че там е числото 1 000 000, а откъде сме го изчислявали, не знаем.

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

По-нататък, total_time на секунда – това е моята любима метрика. Тя се измерва в секунди, т.е. колко секунди е необходима нашата система за изпълнение на тази група заявки в секунда. Ако видите там повече от секунда на секунда, това означава, че се нуждаете от повече от едно ядро. Това е много добра метрика. Можете да разберете, че на този човек, например, му трябват минимум три ядра.

Ето това е нашето нововъведение, не съм виждал подобно никъде. Обърнете внимание – това е много проста вещ – секунда на секунда. Понякога, когато CPU е 100 %, значи половин час на секунда, т.е. половин час сте се занимавали само с тези заявки.

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

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

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

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

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

И по total_time също е интересно. За първата група заявки сме похарчили 14 % от цялото време на работа. А за втората – 11 % и т.н.

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

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

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

Имаме и К001 и К002.

К001 – това е един голям ред с четири подредки. Това е характеристика на нашето натоварване. Вижте втората колона и втората подредка. Наблюдаваме, че е около една и половина секунди в секунда, т.е. ако имаме два ядра, ще е добре. Ще имаме около 75 % натовареност. И така ще работи. Ако имаме 10 ядра, ще сме спокойни. Така можем да оценим ресурсите.

К002 – това ги наричам класове на запитвания, т.е. SELECT, INSERT, UPDATE, DELETE. И отделно SELECT FOR UPDATE, защото той заключва.

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

И се връщаме на въпроса: «Как да подберем правилно shared_buffers?». Наблюдавам, че повечето бенчмаркове се основават на идеята – нека видим каква ще е пропускната способност, т.е. какъв ще е throughput. Обикновено се измерва в TPS или QPS.

И се опитваме да изцедим от машината с параметрите за настройка колкото се може повече транзакции в секунда. Тук имаме 311 в секунда за select.

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

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

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

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

Въпроси

Много благодаря! Много интересна информация.

Две неща.

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

Имаме параметър delta-config. Можете да настроите колкото искате параметри наведнъж. Но трябва да разбирате, че когато променяте много неща, можете да направите неправилни заключения.

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

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

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

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

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

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

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

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

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

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

Т.е. те са се регистрирали отново или как?

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

Добър въпрос, трябва да се погледне.

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

Да-да.

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

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

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

С този ID?

Да.

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

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

В Pg_stat_statements може да има много неща. Случвало се е, че ако track_utility е включено, вашите раковини също ще бъдат проследявани.

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

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

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

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

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

Видео:

P.S. От себе си добавям, че ако в Postgres има конфиденциални данни и не трябва да попадат в тестовата среда, можете да използвате PostgreSQL Anonymizer. Схемата е приблизително следната:

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