Промисловий підхід до тюнінгу 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 крім забезпечення створення instances, розгортання бекапів і т. д., - це пошук вузьких місць та оптимізація продуктивності.

Зараз це влаштовано таким чином. Ми дивимося моніторинг, щось бачимо, якихось подробиць нам не вистачає. Ми починаємо копатися уважніше, зазвичай руками і розуміємо, що з цим робити так чи інакше.

І є два підходи. 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 вирішує знайдені проблеми?

Наприклад, ми знайшли якусь проблему. Що зазвичай робиться? Якщо ви розробник, то ви будете щось робити на якомусь instance, який не такого розміру. Якщо ви є DBA, то у вас є staging. І він може бути лише один. І він відстав на півроку. І ви думаєте, що підете на виробництво. І навіть досвідчені DBA перевіряють потім на production, на репліці. І буває, що створюють тимчасовий індекс, переконуються, що він допомагають, дропають його і віддають розробникам, щоб вони його в міграційні файли засунули. Ось таке марення відбувається зараз. І це біда.

• Тюнити конфігурації.
• Оптимізувати набір індексів.
• Змінювати сам SQL-запит (це найскладніший спосіб).
• Додавати потужностей (найпростіший спосіб у більшості випадків).

Із цими речами дуже багато всього. Там багато ручок у Postgres. Потрібно багато знати. Багато індексів у Postgres, завдяки тому що організаторам цієї конференції. І все це потрібно знати, і саме це у DBA викликає відчуття, що DBA займаються чорною магією. Т. е. потрібно років 10 займатися, щоб почати розуміти все це нормально.

І я – борець із цією чорною магією. Я хочу зробити все так, щоби була технологія, а не було інтуїції у всьому цьому.

Приклади з життя

Це я спостерігав мінімум у двох проектах, включаючи свій. Черговий пост у блозі повідомляє нам, що значення 1 для default_statistict_target – це добре. Добре, давайте спробуємо у production.

І тут ми, використовуючи наш інструмент через два роки за допомогою експериментів над базами даних, про які сьогодні мова, ми можемо порівняти що було і що стало.

І для цього нам потрібно створити експеримент. Він складається із чотирьох частин.

• Перша – це оточення. Нам потрібна залізниця. І коли я приходжу в якусь компанію і укладаю контракт, то я говорю, щоб мені дали таку ж залізку як на production. Для кожного з ваших Майстрів мені потрібна хоча б одна залізниця така сама. Або це віртуальна машина instance в Амазоні або Google, або мені саме така ж залізниця потрібна. Т. е. я хочу відтворити оточення. І поняття оточення ми вкладаємо мажорну версію Postgres.
• Друга частина – це об'єкт наших досліджень. Це база даних. Її можна створити кількома способами. Я покажу як.
• Третя частина – це навантаження. Це найскладніший момент.
• І четверта частина – це те, що ми перевіряємо, тобто що із чим порівнювати будемо. Допустимо, ми можемо в конфізі змінити один або кілька параметрів, а можемо індекс створити і т.д.

Ми запускаємо експеримент. Ось pg_stat_statements. Ліворуч – те, що було. Справа – що стало.

Зліва default_statistics_target = 100, праворуч = 1. Ми бачимо, що нам це допомогло. На 000% загалом усе краще стало.

Але якщо ми промотаємо вниз, там будуть групи запитів з pgBadger або з pg_stat_statements. Тут два варіанти. Ми побачимо, що якийсь запит просів на 88%. І тут уже інженерний підхід. Ми можемо далі копати всередину, бо цікаво, чому він просів. Потрібно розуміти, що там було зі статистикою. Чому більше бакетів у статистиці призводять до найгіршого результату.

А можемо не копати, а зробити «ALTER TABLE… ALTER COLUMN» і йому назад 100 бакетів повернемо до статистики цієї колонки. І далі ще експериментом ми можемо переконатися, що ця латка допомогла. Всі. Ось це інженерний підхід, який допомагає нам бачити картину та приймати рішення на основі даних, а не на основі інтуїції.

Пара прикладів з інших галузей. У тестах є CI тести вже багато років. І жоден уже проект здорового глузду не житиме без автоматичних тестів.

В інших галузях: в авіації, в автомобілебудуванні, коли відчуваємо аеродинаміку, ми також маємо можливість робити експерименти. Ми не будемо щось із креслення одразу в космос запускати чи не буде якусь машину одразу виводити на трасу. Наприклад, є аеродинамічна труба.

Зі спостережень за іншими галузями ми можемо зробити висновки.

По-перше, ми маємо спеціальне оточення. Воно близьке до production, але не близько. Головна його особливість у тому, що має бути дешево, повторювано та максимально автоматизовано. І ще мають бути спеціальні засоби для детального аналізу.

Швидше за все, коли ми літак запустили і летимо, ми маємо менше можливостей вивчати кожен міліметр поверхні крила, ніж є в аеродинамічній трубі. Ми маємо більше засобів для діагностики. Ми можемо собі дозволити навісити якнайбільше важкого, що не можемо дозволити собі відвідати літак у повітрі. Також і з Postgres. У деяких випадках ми можемо включити повне логування запитів під час експериментів. І ми цього на виробництво робити не хочемо. Ми, можливо, навіть із планами це включимо за допомогою auto_explain.

І, як я вже сказав, високий рівень автоматизації означає, що ми натиснули кнопку і повторили. Отак має бути, щоб було багато експериментів, щоб це було на потоці.

Nancy CLI – фундамент "лабораторії БД"

І ось ми зробили таку штуку. Т. е. я про ці ідеї розповідав у червні, майже рік тому. І ми вже маємо в Open Source так звану Nancy CLI. Це фундамент для того, щоб зводити лабораторію бази даних.

Ненсі - Це в Open Source, на Gitlab. Можете сказати, можете спробувати. Я дав заслання у слайдах. На неї можна клацнути і там буде допомога за всіма параметрами.

Звичайно, там багато чого ще на стадії розробки. Там багато ідей. Але це вже те, що ми застосовуємо майже щодня. І коли у нас виникає ідея - а що це при delete 40 000 000 рядків у нас все вперлося в IO, то ми можемо провести експеримент і подивитись докладніше, щоб зрозуміти, що відбувається і надалі спробувати виправити це на ходу. Т. е. ми робимо експеримент. Наприклад, щось підкручуємо і дивимося, що в результаті виходить. Та ми це робимо не так на production. Це суть ідеї.

Де це може працювати? Це може працювати локально, тобто можна це робити будь-де, можна навіть на MacBook запустити. Потрібен докер, поїхали. І все. Можна запустити в будь-якому стані в залізці, або у віртуалці, де завгодно.

І ще є можливість запускати віддалено в Амазоні в EC2 Instance, в спотах. І це дуже класна нагода. Наприклад, вчора ми провели більше 500 експериментів на i3 instance, починаючи з наймолодшого і закінчуючи i3-16-xlarge. І нам 500 експериментів стали в 64 долари. Кожен тривав 15 хвилин. Т. е. за рахунок того, що там використовуються споти, це дуже дешево - знижка 70%, посекундна тарифікація Амазона. Ви можете робити дуже багато. Ви можете проводити реальне дослідження.

І три мажорні версії Postgres підтримуються. Не так складно допиляти якісь старі та нову 12-ту версію теж.

Об'єкт ми можемо трьома способами задавати. Це:

• Dump/SQL-файл.
• Головний спосіб – це клон PGDATA директорія. Як правило, береться з бекап-сервера. Якщо у вас є нормальні бінарні бекапи, звідти можете клони робити. Якщо у вас є хмари, то за вас це хмарна контора типу Амазона і Google сама робитиме. Це найголовніший спосіб для клонів реального виробництва. Ми таким чином якраз розвертаємо.
• І останній спосіб підходить для досліджень, коли є бажання розібратися, як у Postgres працює якась штука. Це pgbench. Ви можете згенерувати за допомогою pgbench. Це просто одна опція "db-pgbench". Кажеш йому, який scale. І все буде у хмарі згенеровано, як сказано.

І навантаження:

• Навантаження ми можемо виконувати в один потік SQL. Це найпримітивніший спосіб.
• А можемо емулювати навантаження. І емулювати ми передусім можемо її в такий спосіб. Нам потрібно збирати усі логи. І це болісно. Я покажу чому. І за допомогою pgreplay програємо, який вбудований у Nancy.
• Або інший варіант. Так зване крафтове навантаження, яке ми робимо з деякою кількістю зусиль. Аналізуючи наше поточне навантаження на бойову систему, ми висмикуємо топові групи запитів. І за допомогою pgbench можемо емулювати це навантаження в лабораторії.

• Або ми SQL якийсь маємо виконати, тобто міграцію якусь перевіряємо, індекс там створюємо, ANALAZE там виконуємо. І дивимося, що було до вакууму та після вакууму. Загалом будь-який SQL.
• Або ми у конфізі змінюємо один чи кілька параметрів. Ми можемо сказати, щоб нам перевірили, наприклад, 100 значень у Амазоні для нашої терабайтної бази. І за кілька годин у вас буде результат. Як правило, терабайтна база у вас розгортатиметься кілька годин. Але в розробці є патч, у нас можлива серія, тобто ви можете послідовно на тому самому сервері використовувати ту ж саму pgdata і перевіряти. Postgres буде рестартуватись, кеші скидатися. І ви можете ганяти навантаження.

• Приїжджає директорія, в якій купа всяких файликів, починаючи від снапшотів.stat***. І там найцікавіше це pg_stat_statements, pg_stat_kcacke. Це два розширення, що аналізують запити. pg_stat_bgwriter містить у собі не тільки pgwriter статистику, а ще й по checkpoint і по тому, як самі бекенди витісняють брудні буфера. І це все цікаво подивитись. Наприклад, коли ми shared_buffers налаштовуємо, дуже цікаво подивитися, скільки там хто витісняв.
• Також приїжджають логі Postgres. Два логи – лог підготовки та лог програвання навантаження.
• Щодо нову фічу – це FlameGraphs.
• Також, якщо ви використовували pgreplay або pgbench варіанти програвання навантаження, то буде їхній рідний висновок. І ви будете бачити latency та TPS. Можна буде зрозуміти, як вони це бачили.
• Інформація про систему.
• Базові перевірки CPU та IO. Це більше для EC2 instance в Амазоні, коли ви хочете в потоці запустити 100 однакових instances і там прогнати по 100 різних прогонів, то у вас буде 10 000 експериментів. І вам потрібно переконатися, що вам не потрапив ущербний instance, якого вже хтось утискує. На цій залізці інші активнічать і вам мало залишається ресурсу. Такі результати краще відкинути. І якраз за допомогою sysbench від Олексія Копитова ми робимо кілька коротеньких перевірок, які приїдуть і можна порівняти з іншими, тобто ви зрозумієте, як CPU поводиться і як IO поводиться.

Які технічні складності на прикладі різних компаній?

Допустимо, ми хочемо реальне навантаження за допомогою логів повторювати. Відмінна ідея, якщо це написано на Open Source pgreplay. Ми його використовуємо. Але щоб він добре працював, ви повинні включити повне логування запитів з параметрами та таймінгом.

Там є деякі складнощі щодо тривалості і 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. Ставте собі на ноутбук, або на observing server, звідки ви запускатимете. І він аналізуватиме багато чого: і операційну систему, і файлову систему, і сам 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 має велику проблему в тому, що він не пам'ятає, коли був reset. Якщо pg_stat_database пам'ятає, pg_stat_statements не пам'ятає. Ви бачите, що там 1 число, а звідки ми рахували, ми не знаємо.

А тут ми знаємо, тут у нас є два снапшоти. Ми знаємо, що дельта була у цьому випадку 56 секунд. Дуже невеликий проміжок. За total_time відсортували. І далі ми можемо диференціювати, тобто ми всі метрики ділимо на тривалість. Якщо ми кожну метрику розділимо на тривалість, ми матимемо кількість викликів за секунду.

Далі total_time per second – моя улюблена метрика. Вона вимірюється в секундах, в секунду, тобто скільки секунд знадобилося нашої системи виконання цієї групи запитів в секунду. Якщо ви бачите там більше секунди за секунду, це означає, що більше одного ядра вам потрібно було дати. Це дуже гарна метрика. Ви можете зрозуміти, що цьому товаришеві, наприклад, потрібно щонайменше три ядра.

Оце наше ноу-хау, я такого ніде не бачив. Зверніть увагу - це дуже проста річ - секунда на секунду. Іноді, коли у вас CPU 100%, то півгодини на секунду, тобто ви півгодини займалися лише цим запитом.

Далі ми бачимо rows за секунду. Ми знаємо, скільки рядків за секунду повернула.

І далі також цікава річ. Скільки ми 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% за total_time. Що далі підставляти після "@"? Ми дивимося на calls, дивимося, скільки відсотків і розуміємо, що ми ось тут маємо стільки відсотків. З цих відсотків ми можемо зрозуміти, як балансувати кожен із файликів. Після цього ми використовуємо pgbench та поїхали працювати.

Є ще у нас К001 та К002.

К001 – це один великий рядок із чотирма підрядками. Це характеристика всього нашого навантаження. Дивіться другу колонку і друге підрядження. Ми бачимо, що півтори секунди за секунду приблизно, тобто якщо буде два ядра, то буде добре. Буде приблизно 75% завантаження. І це так працюватиме. Якщо ми матимемо 10 ядер, то ми взагалі будемо спокійні. Так ми можемо оцінювати ресурси.

К002 – це називаю класи запитів, т. е. SELECT, INSERT, UPDATE, DELETE. І окремо SELECT FOR UPDATE, бо він лочить.

І тут ми можемо зробити висновок, що SELECT звичайні читачі - 82% від усіх викликів, але при цьому - 74% total_time. Т. е. вони багато викликаються, але менше споживають ресурс.

І повертаємося до запитання: "Як нам правильно підібрати shared_buffers?". Я спостерігаю, що більшість бенчмарків будуються на ідеї - давайте подивимося, якою буде через putput, тобто якою буде пропускна здатність. Вона в TPS зазвичай вимірюється або QPS.

І ми намагаємося вичавити від тачки за допомогою параметрів від тюнінгу якнайбільше транзакцій на секунду. Тут тільки 311 в секунду для select.

Але ніхто не їздить на роботу та назад додому на машині на повній швидкості. Це безглуздо. Так само і з базами даних. Ми не повинні їздити на повній швидкості, та ніхто цього не робить. Ніхто не живе у production, у якого 100% CPU. Хоча, може, хтось і живе, але це недобре.

Ідея така, що ми їздимо зазвичай відсотках на 20% від можливості, бажано не вище 50%. І ми намагаємося час відгуку оптимізувати для наших користувачів перш за все. Т. е. ми повинні наші ручки крутити так, щоб було мінімальне latency при 20% швидкості, умовно. Це така ідея, яку ми також намагаємося використати у наших експериментах.

І на завершення рекомендації:

• Обов'язково зробіть Database Lab.
• По можливості зробіть on demand, щоб розгорталося на якийсь час – пограли та викинули. Якщо у вас хмари, то це само собою, тобто майте багато standing.
• Будьте допитливими. І якщо щось не так, то перевіряйте експериментами, як воно поводиться. Nancy можна використовувати для навчання себе, щоб перевіряти, як працює база.
• І прицілюйтесь на мінімальний час відгуку.
• І не бійтеся вихідників Postgres. Коли ви працюєте з вихідними джерелами, ви повинні знати англійську. Там дуже багато коментарів, там усе пояснено.
• І перевіряйте здоров'я бази регулярно, хоча б раз на три місяці руками або Postgres-checkup.

Питання

Велике спасибі! Дуже цікава річ.

Дві штуки.

Так, дві штуки. Тільки я не зовсім зрозумів. Коли ми працюємо з Nancy, ми тільки один параметр може підкручувати або цілу групу?

У нас є дельта-конфіг параметр. Ви можете туди скільки завгодно одразу крутнути. Але треба розуміти, коли ви змінюєте багато всього, ви можете зробити неправильні висновки.

Так. Чому я спитав? Тому що складно проводити експерименти, коли ти маєш лише один параметр. Ти його підкручуєш, подивився, як працює. Виставив його. Потім наступний починаєш.

Можна одночасно підкручувати, але залежить від ситуації, звісно. Але краще одну ідею перевіряти. У нас учора виникла ідея. Ми мали дуже близьку ситуацію. Було два конфіги. І ми не могли зрозуміти чому велика різниця. І виникла ідея, що потрібно використовувати дихотомію, щоб послідовно зрозуміти та знайти у чомусь відмінність. Можна відразу половину параметрів зробити однаковими, потім чверть тощо. буд. Все гнучко.

І ще є питання. Проект молодий, що розвивається. Документація вже готова, чи є докладний опис?

Я там спеціально посилання зробив опис параметрів. Це є. Але багато чого немає поки що. Я шукаю однодумців. І я їх знаходжу, коли виступаю. Це дуже круто. Хтось уже зі мною працює, хтось допоміг та щось там зробив. І якщо вам цікава ця тема, дайте зворотний зв'язок – чого не вистачає.

Як зробимо лабораторію, можливо, буде зворотний зв'язок. Подивимося. Дякую!

Вітаю! Дякую за доповідь! Я побачив, що є підтримка Амазон. Чи планується підтримка GSP?

Гарне питання. Почали робити. І поки що заморозили, бо ми хочемо економити. Т. е. є підтримка за допомогою run on localhost. Ви можете самі створити instance і працювати локально. До речі, ми так робимо. У Getlab я так роблю, там на GSP. Але робити саме таку оркестрацію ми поки що не бачимо сенсу, тому що Google не має спотів дешевий. Там є ??? instances, але мають обмеження. По-перше, у них завжди лише знижка в 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_statemetns там може витіснити.

У Pg_stat_statements може бути багато чого. Ми стикалися з тим, що якщо у вас track_utility = on, то у вас мережі теж трекаються.

Так, звичайно.

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

Так, але треба знати, наскільки. І якось за ним треба стежити. Я так і роблю. Т. е. у мене є pg_stat_statements.max. І дивлюся, що я на момент снапшоту не дійшов відсотків 70%. Добре, отже, ми нічого не втратили. Робимо reset. І копимо знову. Якщо в наступному снапшоті менше 70, то, швидше за все, знову нічого не втратили.

Так. За замовчуванням зараз 5 000. І багатьом цього вистачає.

Зазвичай так.

Відео:

PS Від себе додам, що якщо в Postgres знаходяться конфедиційні дані і їм не можна потрапляти в тестове оточення, то можна скористатися PostgreSQL Anonymizer. Схема приблизно така:

Джерело: habr.com