Промишлен подход към настройването на 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 000 души. 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. И той може да бъде само един. А той е изостанал с половин година. И си мислите, че ще отидете на production. И дори опитните DBA проверяват после на production, на реплика. И понякога създават временно индекси, уверяват се, че помагат, след което ги премахват и ги дават на разработчиците, за да ги вкарат в миграционните файлове. Такова безумие се случва сега. И това е беда.

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

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

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

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

Това съм наблюдавал минимум в два проекта, включително моя. Още една публикация в блога ни информира, че стойността 1 000 за default_statistict_target е добра. Добре, нека опитаме в production.

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

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

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

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

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

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

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

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

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

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

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

Вероятно, когда мы запустили самолет и летим, у нас меньше возможностей исследовать каждый миллиметр поверхности крыла, чем в аэродинамической трубе. У нас больше инструментов для диагностики. Мы можем позволить себе установить больше всего тяжелого, что невозможно установить на самолет в воздухе. То же самое и с Postgres. В некоторых случаях мы можем включить полное логирование запросов во время экспериментов. И мы этого не хотим делать на production. Возможно, мы даже сделаем это с помощью auto_explain в некоторых планах.

Как я уже сказал, высокий уровень автоматизации означает, что мы нажали кнопку и повторили. Так это и должно быть, чтобы было много экспериментов в потоке.

Nancy CLI – это основа «лаборатории БД»

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

Nancy — Это в Open Source, на Gitlab. Можете сказать, можете попробовать. Я оставил ссылку в слайдах. На нее можно кликнуть и попасть туда. help по всем параметрам.

Конечно, многое еще находится в стадии разработки. Там много идей. Но это уже то, что мы применяем практически ежедневно. И когда у нас возникает идея – например, что произойдет при удалении 40 000 000 строк, когда мы упираемся в IO, мы можем провести эксперимент и посмотреть подробнее, чтобы понять, что происходит и попытаться исправить это на ходу. То есть, мы проводим эксперимент. Например, мы вносим изменения и смотрим, что в итоге получается. И это не на production. Это и есть суть идеи.

Где это может работать? Это может работать локально, то есть, можно это делать где угодно, даже на MacBook. Нужен Docker, поехали. И всё. Можно запустить в каком-нибудь инстансе на железке или в виртуалке, где угодно.

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

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

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

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

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

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

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

• Постъпва директория, в която има купчини файлове, започвайки от моментни снимки pgstat***. И там най-интересното – това са pg_stat_statements, pg_stat_cache. Това са две разширения, които анализират заявките. И pg_stat_bgwriter включва не само статистика pgwriter, а също така и информация за чекпойнтите и за начина, по който самите бекенди изхвърлят мръсни буфери. И е много интересно да се види всичко това. Например, когато настройваме shared_buffers, е много интересно да видим колко от тях някой е изхвърлил.
• Постъпват също и логове от Postgres. Два лога – лог за подготовка и лог за изпълнение на натоварване.
• Относително нова функция – FlameGraphs.
• Също така, ако сте използвали pgreplay или pgbench варианти за изпълнение на натоварване, ще имате оригиналния им изход. И можете да видите латентността и 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. Също базата е в Open Source. И в момента активно го развиваме.

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

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

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

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

Назовахме го Postgres-checkup. Ако говорим медицински, това е редовна проверка на здравословното състояние. Ако говорим в автомобилна тематика, това е като технически преглед. Правите технически преглед на колата си на всеки шест месеца или година, в зависимост от марката. А правите ли технически преглед на базата си? Т.е. правите ли дълбочинно изследване редовно? Трябва да го правите. Ако правите резервни копия, правете и 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 е, че той не помни кога е бил нулиран. Ако 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 %, е ОК.

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

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

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

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

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

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

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

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

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

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

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

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

Въпроси

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

Две неща.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Правих нещо аналогично. Разбира се, по-просто, направих го сам. Но ми се наложи да нулирам, да направя reset на stat_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%. Добре, значи не сме загубили нищо. Правим reset и отново натрупваме. Ако в следващата снимка е по-малко от 70, тогава вероятно отново не сме загубили нищо.

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

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

Видео:

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

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