Розшифровка доповіді 2015 року Іллі Космодем'янського "Linux tuning to improve PostgreSQL performance"
Disclaimer: Зауважу, що доповідь ця датована листопадом 2015 року - минуло більше 4 років і пройшло багато часу. Версія 9.4, що розглядається в доповіді, вже не підтримується. За останні 4 роки вийшло 5 нових релізів PostgreSQL вийшло і 15 версій ядра Linux. Якщо переписувати ці місця, то вийде у результаті інший доповідь. Але тут розглянуто фундаментальний тюнінг Linux для PostgreSQL, який є актуальним і зараз.
Мене звуть Ілля Космодем'янський. Я працюю у компанії PostgreSQL-Consulting. І тепер розповідатиму трохи про те, що робити з Linux стосовно баз даних взагалі і до PostgreSQL зокрема, тому що принципи досить схожі.
Про що йтиметься? Якщо ви спілкуєтеся з PostgreSQL, то певною мірою потрібно бути UNIX'овим адміном. Що це означає? Якщо ми порівняємо Oracle і PostgreSQL, то Oracle має бути на 80 % DBA адміном бази даних і на 20 % адміном Linux.
З PostgreSQL трохи складніше. З PostgreSQL треба краще уявляти, як працює Linux. І при цьому трішки бігти за паровозом, тому що останнім часом досить здорово все апдейтиться. І нові ядра виходять, і новий функціонал з'являється, перформанс покращується і т.д.
Чому ми говоримо про Linux? Зовсім не тому, що ми на конференції Linux Пітер, а тому що в сучасних умовах одна з найвиправданіших ОС для експлуатації з базами даних взагалі і з PostgreSQL зокрема – це Linux. Тому що FreeBSD, на жаль, розвивається у якомусь дуже дивному напрямку. І будуть проблеми як із продуктивністю, так і з багатьма іншими речами. Продуктивність PostgreSQL на Windows - це взагалі окрема сувора тема, що упирає в те, що у Windows немає такої кулястої пам'яті як у UNIX, а у PostgreSQL все на цю справу зав'язано, тому що багатопроцесна система.
І екзотика типу Solaris, я думаю, меншою мірою всіх цікавить, тож поїхали.
Сучасний дистрибутив Linux має більше 1 000 параметрів syctl, залежно від того, як зібрати ядро. При цьому, якщо ми подивимося ще на різні гайки, то там можна ще багатьма способами щось налаштовувати. Існують параметри файлових систем, як монтувати. Якщо питання, як запустити: що в BIOS включити, як залізки налаштувати і т.д.
Це дуже великий обсяг, про який можна розповідати кілька днів, а не за одну коротку доповідь, але я зараз зупинюся на важливих речах, як уникнути тих граблів, які з гарантією не дадуть вам добре експлуатувати базу даних на Linux, якщо ви їх не виправите . І при цьому важливий такий момент, що багато параметрів дефолту включені не в такі налаштування, які правильні для бази даних. Т. е. за умовчанням працювати буде погано або працювати не буде взагалі.
Які традиційні tuning targets є в Linux? Я думаю, що оскільки ви маєте справу з адмініструванням Linux, то що таке targets пояснювати особливо не треба.
Можна тюнити:
- CPU.
- Пам'ять.
- Зберігання
- Інші. Про це ми поговоримо наприкінці на закуску. Навіть, наприклад, такі параметри, як політика енергозбереження можуть дуже непередбачуваним і не приємним чином вплинути на продуктивність.
Яка специфіка у PostgreSQL та у бази даних взагалі? Проблема в тому, що не можна потьмарити якусь окрему гайку і подивитися, що продуктивність у нас сильно покращала.
Так, такі гайки є, але база даних – це складна річ. Вона взаємодіє з усіма ресурсами, які є у сервера і воліє взаємодіяти на повну. Якщо ви подивіться на сучасні рекомендації Oracle щодо того, як використовувати хостову ОС, то це буде як в анекдоті про того монгольського космонавта - погодувати собаку і нічого не чіпати. Дамо базі всі ресурси, база даних сама все розрулить.
В принципі, до певної міри з PostgreSQL така сама ситуація. Різниця полягає в тому, що база ще й не всі ресурси сама вміє собі забирати, тобто десь потрібно на рівні Linux це розрулювати самостійно.
Основна ідея - не вибрати якийсь одиничний target і почати його тюнити, наприклад, пам'ять, CPU або щось таке, а проаналізувати workload і спробувати максимально покращити пропускну здатність, щоб через нашу базу даних максимально ефективно проходило те навантаження, яке добрі програмісти нам створили, зокрема й наші користувачі.
Ось таке зображення для пояснення того, що це таке. Є буфер ОС Linux і є куляста пам'ять і є кулінарні буфери PostgreSQL. PostgreSQL на відміну від Oracle працює безпосередньо тільки через буфер ядра, тобто щоб сторінка з диска потрапила в його кулясту пам'ять, вона повинна пройти через kernel buffer і назад така сама ситуація.
Під цією системою мешкають диски. Я це намалював як диски. Насправді там може бути RAID-контролер і т.д.
І ось це введення-висновок так чи інакше відбувається через цю справу.
PostgreSQL – це традиційна база даних. Там усередині сторінки. І все введення-виведення відбувається за допомогою сторінок. Ми сторінками піднімаємо блоки на згадку. І якщо нічого не сталося, ми їх просто прочитали, то поступово вони з цього кеша, з буферів шарудних тонуть і потрапляють назад на диск.
Якщо ми щось замінили, то у нас вся сторінка позначається як брудна. Я їх тут синім кольором наголосив. І це означає, що ця сторінка має бути синхронізована з блоковим сховищем. Т. е. ми, коли її зробили брудною, зробили запис у WAL. І в якийсь чудовий момент часу прийшло явище під назвою checkpoint. І в цей лог записалася інформація про те, що він прийшов. І це означає, що всі брудні сторінки, які тут були в цей момент у цих кулястих буферах, синхронізувалися з диском сховища за допомогою fsync через kernel buffer.
Навіщо це робиться? Якщо в нас зникла напруга, ми не отримали ситуацію, що всі дані зникли. Персистентна пам'ять, про яку нам все розповідали, це поки що в теорії баз даних – це світле майбутнє, якого ми, звичайно, прагнемо і воно нам подобається, але поки що вони живуть ще в мінус 20 років. І, звісно, за всім цим треба стежити.
І завдання максимізації пропускної спроможності – це потік на всіх цих етапах, щоб це все їздило туди-сюди швидко. Шатра пам'ять - це в основному сторінковий кеш. У PostgreSQL ми надіслали запит select щось там, він дістав ці дані з диска. Вони потрапили в кучеряві буфери. Відповідно, щоб це працювало краще, має бути багато пам'яті.
Для того, щоб це все працювало добре і швидко, вам потрібно правильно налаштувати на всіх етапах операційну систему. І вибрати збалансоване залізо, тому що якщо у вас в якомусь місці буде дисбаланс, то ви можете зробити дуже багато пам'яті, але обслуговуватиметься вона з недостатньою швидкістю.
І пройдемося по кожному із цих пунктів.
Щоб ці сторінки подорожували туди-сюди швидше, потрібно досягти наступного:
- По-перше, потрібно ефективніше працювати з пам'яттю.
- По-друге, ефективнішим має бути ось цей перехід, коли сторінки з пам'яті потрапляють на диск.
- І, по-третє, мають бути добрі диски.
Якщо у вас 512 GB оперативної пам'яті в сервері і все це у фіналі приїжджає на SATA жорсткий диск без жодного кешу, то весь сервер бази даних перетворюється не просто на гарбуз, а на гарбуз з SATA інтерфейсом. Ви впиратиметеся в це безпосередньо. І нічого вас не врятує.
Щодо першого пункту з пам'яттю, то є три речі, які можуть сильно ускладнити життя.
Перша їх – це NUMA. NUMA – це річ, яка зроблена для покращення продуктивності. Залежно від workload можна оптимізувати різні речі. І в новому її нинішньому вигляді вона для таких додатків, як база даних, що інтенсивно використовують page cache кулісні буфера, не дуже хороша.
В двох словах. Як зрозуміти, що з NUMA щось не те? У вас якийсь неприємний стукіт, раптово якийсь CPU виявляється перевантажений. При цьому ви аналізуєте запити в PostgreSQL і бачите, що нічого такого схожого там немає. Ці запити не повинні настільки інтенсивно споживати CPU. Ловити це можна довго. Простіше скористатися з самого початку правильною рекомендацією, як налаштувати NUMA для PostgreSQL.
Що насправді відбувається? NUMA – це Non-Uniform Memory Access. Сенс у чому? У вас є CPU, з ним поряд є пам'ять його локальна. І ця пам'ять міжконтактами може підтягувати пам'ять з інших CPU.
Якщо ви запустите numactl --hardware, то вам вийде таке велике простирадло. Серед іншого там буде поле distances. Будуть циферки – 10-20, щось таке. Ці циферки ні що інше, як кількість хопів, щоб цю віддалену пам'ять підчепити та використовувати локально. У принципі хороша ідея. Це добре прискорює продуктивність при низці навантажень.
Тепер уявіть, що у вас один CPU спочатку намагається використовувати свою локальну пам'ять, потім намагається підтягнути по interconnect іншу пам'ять собі для чогось. І на цей CPU потрапляє весь ваш page cache PostgreSQL - все, скільки там гігабайт. Ви завжди отримуєте найгірший випадок, тому що на CPU безпосередньо в цьому модулі пам'яті зазвичай мало. І вся пам'ять, яка обслуговується, ходить через ці міжконтакти. Виходить повільно та сумно. І у вас процесор, який обслуговує цей вузол постійно перевантажений. І час доступу цієї пам'яті – поганий, повільний. Ця ситуація, яку ви не хочете, якщо використовуєте цю справу для бази даних.
Тому правильніший варіант для бази даних, щоб операційна система Linux взагалі не знала, що там відбувається. Щоб вона зверталася до пам'яті, як звертається.
Чому так? Здавалося б, що має бути навпаки. Це відбувається з однієї простої причини, що пам'яті нам потрібно під page cache багато – десятки, сотні гігабайт.
І якщо ми це все виділили і прокешували наші дані там, то виграш від використання кешу буде значно більшим, ніж виграш від такого хитрого звернення до пам'яті. І ми таким чином виграємо не порівнянно порівняно з тим, що ми більш ефективно звертатимемося до пам'яті з використанням NUMA.
Тому підходи тут два зараз, поки світле майбутнє не настало, і база даних не вміє сама розбиратися на яких CPU вона працює і звідки їй щось потрібно підтягнути.
Тому правильний підхід – взагалі відключити NUMA.наприклад, при перезавантаженні. У більшості випадків виграші бувають на такі порядки, що взагалі не виникає питання, як краще.
Є інший варіант. Ми ним частіше користуємося, ніж першим, бо коли до нас приходить на підтримку клієнт, то для нього перезавантажити сервер – це ціла справа. У нього там бізнес крутиться. А проблеми через NUMA вони мають. Тому ми намагаємося відключити менш інвазивними способами, ніж reboot, але тут акуратніше перевіряйте, що вона вимкнулася. Тому що, як показує досвід, на батьківський процес PostgreSQL NUMA ми відключаємо, це добре, але зовсім не обов'язково, що це спрацює. Треба перевіряти та дивитися, що вона справді відключилася.
Є хороша посада Robert Haas. Це один із коммітерів PostgreSQL. Один із ключових розробників усіх низькорівневих потрухів. І якщо за посиланнями з цієї посади пройтися, то там описується кілька яскравих історій про те, як людям NUMA ускладнювала життя. Подивіться, вивчіть чек-лист сісадмінський, що потрібно налаштувати на сервері для того, щоб у нас база даних працювала добре. Ось ці налаштування потрібно записати та перевіряти, бо інакше буде не дуже добре.
Звертаю увагу, що це стосується всіх налаштувань, про які я говоритиму. Але зазвичай бази даних збирають у режимі master-slave для стійкості до відмови. Не забудьте внести ці налаштування на slave, тому що одного разу у вас трапиться аварія, і ви перемкнетеся на slave, і він стане майстром.
В аварійній ситуації, коли все дуже погано, у вас постійно дзвонить телефон і вдається начальник з великим ціпком, вам ніколи не буде думати про те, щоб перевірити. І результати можуть бути дуже плачевними.
Наступний момент – це huge pages. Huge pages складно протестувати окремо, та й сенсу в цьому немає, хоча є бенчмарки, які вміють це робити. Вони легко нагуглюються.
В чому сенс? У вас не дуже дорогий сервер, в якому багато оперативної пам'яті, наприклад більше 30 GB. У вас не використовується huge pages. Це означає, що у вас однозначно є overhead використання пам'яті. Та цей overhead далеко не найприємніший.
Чому так? І що відбувається? Операційна система дрібними шматочками виділяє пам'ять. Так зручно, так історично склалося. І якщо вдаватися до подробиць, то ОС має транслювати віртуальні адреси у фізичні. І це процес не найпростіший, тому ОС результат цієї операції кешує Translation Lookaside Buffer (TLB).
І оскільки TLB – це кеш, то у такій ситуації виникають усі притаманні кешу проблеми. По-перше, якщо у вас дуже багато оперативної пам'яті і вона вся виділена дрібними chunks, то цей буфер стає дуже великим. А якщо кеш великий, то шукати по ньому повільніше. Overhead здоровий і сам займає місце, т. е. оперативну пам'ять споживає щось щось неправильне. Це вкотре.
Два – чим більше розростається кеш у такій ситуації, тим більша ймовірність того, що у вас буде cache misses. І ефективність цього кешу стрімко падає із зростанням його розміру. Тому в операційних системах вигадали простий підхід. У Linux він давно використовується. У FreeBSD нещодавно з'явився. Але ми говоримо про Linux. Це huge pages.
І тут слід зазначити, що huge pages, як ідея, спочатку була продавлена спільнотами, що включали Oracle і IBM, тобто виробники баз даних міцно думали про те, що це стане в нагоді, для баз даних у тому числі.
І як це подружити з PostgreSQL? По-перше, у лінуксовому ядрі повинні бути включені huge pages.
По-друге, вони повинні бути в явному вигляді вказані sysctl параметром – скільки їх. Цифри тут із якогось старого сервера. Ви можете порахувати, скільки приблизно у вас shared buffers, щоб huge pages туди влазили.
І якщо у вас весь сервер відданий під PostgreSQL, то хороша відправна точка – це або 25% оперативної пам'яті віддати під кулінарні буфери, або 75%, якщо ви впевнені, що в ці 75% ваша база даних точно поміститься. Відправна точка перша. І вважайте, якщо у вас 256 GB оперативної пам'яті, то відповідно 64 GB у вас буде шердних буферів. Порахуйте приблизно з деяким запасом – у що має бути виставлена ця цифра.
До версії 9.2 (якщо не помиляюся, з версії 8.2) можна було за допомогою сторонньої бібліотеки подружити PostgreSQL із huge pages. А це завжди треба робити. По-перше, вам потрібно, щоб ядро вміло виділяти huge pages правильно. А по-друге, щоб програма, яка з ними працює, могла ними скористатися. Просто так воно не скористається. Оскільки PostgreSQL виділяв пам'ять у стилі system 5, це можна було зробити за допомогою libhugetlbfs — це повна назва бібліотеки.
У 9.3 покращили продуктивність PostgreSQL під час роботи з пам'яттю і відмовилися від system 5 методу виділення пам'яті. Всі дуже зраділи, тому що інакше намагаєшся запустити два instances PostgreSQL на одній машині, а він каже, що у мене кулястої пам'яті не вистачає. І каже, що потрібно виправити sysctl. А там такий sysctl, що потрібно ще перезавантажитись і т.д. Загалом, всі зраділи. Але виділення пам'яті mmap зламало використання huge pages. У нас більшість клієнтів використовують великі shared buffers. Та ми рекомендували не переходити на 9.3, тому що там overhead починався у гарних відсотках обчислюватися.
Зате community звернула увагу на цю проблему і в 9.4 дуже добре переробили цей захід. І в 9.4 з'явився параметр postgresql.conf, в якому можна включити try, on або off.
Try – найбезпечніший параметр. При старті PostgreSQL, коли він виділяє кулясту пам'ять, він намагається відхопити собі з huge pages цю пам'ять. І якщо не виходить, то відкочується на звичайне виділення. І якщо у вас FreeBSD або Solaris, ви можете поставити try, це завжди безпечно.
Якщо on, то він просто не стартує, якщо не зміг виділити з huge pages. Тут уже – кому і що миліше. Але якщо у вас стоїть try, то перевіряйте, що у вас справді те, що потрібно виділилося, тому що просторів для помилки там багато. Зараз цей функціонал працює лише на Linux.
Ще одне маленьке зауваження, перш ніж підемо далі. Transparent huge pages – це не про PostgreSQL поки що. Скористатися ними нормально він не може. І при Transparent huge pages для такого workload, коли потрібен великий шматок кулястої пам'яті, плюси наступають тільки за дуже великих обсягів. Якщо у вас є терабайти пам'яті, тоді це може відігравати роль. Якщо ми говоримо про більш життєві застосування, коли у вас 32, 64, 128, 256 GB пам'яті на машині, то звичайний huge pages - це Ok, а Transparent просто відключаємо.
І остання річ щодо пам'яті безпосередньо не пов'язана з фрупутом, вона може дуже сильно зіпсувати життя. Вся пропускна спроможність сильно постраждає від того, що сервер постійно впаде.
І це буде дуже неприємно у низці моментів. І основна неприємність полягає в тому, що в сучасних ядрах трішки відрізняється поведінка з старішими ядрами Linux. І ця річ, на яку наступати досить неприємно, бо коли ми говоримо про якусь роботу зі swap'ом, закінчується це не своєчасним приходом OOM-killer. І OOM-killer, який не вчасно прийшов та скинув PostgreSQL, це неприємно. Про це дізнаються усі, тобто до останнього користувача.
Що відбувається? У вас там багато оперативної пам'яті, все добре працює. Але чомусь сервер висить у swap'і та гальмує через це. Здавалося б, багато пам'яті, але так відбувається.
Раніше ми радили vm.swappiness ставити у нуль, тобто відключати swap. Раніше здавалося, що 32 GB оперативної пам'яті та шаредні буфери відповідні – це величезна кількість. Основне призначення swap'у, щоб було місце, куди кинути кірку, якщо ми відвалилися. І воно вже не надто виконувалося. І що потім з цією кіркою робитимеш? Це вже таке завдання, коли не дуже зрозуміло, навіщо потрібен swap, тим більше такого розміру.
Але в сучасніших, тобто в третіх версіях ядра поведінка змінилася. І якщо виставити swap в нуль, тобто вимкнути, то рано чи пізно навіть при залишку якоїсь оперативної пам'яті до вас приходитиме OOM-killer, щоб вбивати найбільш інтенсивних споживачів. Тому що він вважатиме, що за такого workload нам залишилося ще трошки і ми вискачемо, тобто не системний процес прибивати, а прибити щось менш важливе. Цим менш важливим виявиться інтенсивний споживач кулястої пам'яті, а саме postmaster. І після цього буде добре, якщо базу не доведеться відновлювати.
Тому зараз дефолтно, наскільки я пам'ятаю, більшість дистрибутивів – це десь 6, тобто коли починати використовувати swap залежно від того, скільки пам'яті залишилося. Ми зараз радимо ставити vm.swappiness = 1, тому що це практично його вимикає, але не дає таких ефектів, як з OOM-killer'ом, що несподівано прийшов, і всю цю справу прибили.
Що далі? Коли ми говоримо про перформанс баз даних і поступово-поступово схожим до дисків, всі починають хапатися за голову. Тому що істина про те, що диск повільний і швидка пам'ять, вона всім з дитинства знайома. І всі знають, що у базі даних будуть проблеми з дисковою продуктивністю.
Основна проблема з продуктивністю PostgreSQL, пов'язана з checkpoints spikes, виникає не через те, що диск повільний. Це швидше від того, що пропускна здатність пам'яті та диска не збалансована. При цьому вони можуть бути не збалансованими у різних місцях. PostgreSQL не налаштований, ОС не налаштована, залізо не налаштоване та залізо неправильне. І цієї проблеми не буває лише в тому випадку, якщо все відбувається як треба, тобто або навантаження немає, або налаштування та залізо добре підібрані.
Що це таке та як це виглядає? Зазвичай люди, які з PostgreSQL працюють у цю справу, вступали неодноразово. Я поясню. Як я казав, PostgreSQL періодично робить checkpoints, щоб брудні сторінки в кулястої пам'яті здампити на диск. Якщо у нас великий обсяг кулястої пам'яті, то checkpoint починає інтенсивно впливати на диск, тому що дампіт ці сторінки fsync. Він приїжджає до kernel buffer і пишеться на диски за допомогою fsync. І якщо обсяг цієї справи великий, ми можемо спостерігати неприємний ефект, а саме дуже велику утилізацію дисків.
Тут маю дві картинки. Я зараз поясню, що таке. Це два з корельованих за часом графіка. Перший графік – це дискова утилізація. Тут вона сягає майже 90 % у цей час. Якщо у вас випад бази даних з фізичними дисками, з RAID-контролером утилізація під 90%, це погані новини. Це означає, що ще трохи і настане 100 і введення-виведення зупиниться.
Якщо у вас дисковий масив, то там інша трохи історія. Там залежить від того, як він налаштований, що за масив тощо.
А паралельно тут налаштований графік із внутрішньої postgres'ової завірюхи, яка говорить, як відбувається checkpoint. І зеленим кольором тут показано, скільки буферів, цих брудних сторінок в цей момент приїхало в цьому checkpoint для синхронізації. І це головне, що тут треба знати. Ми бачимо, що у нас тут багато сторінок приїхало і в якийсь момент ми вперлися в плату, тобто писали-писали, тут дискова система дуже сильно зайнята. І у нас checkpoint дуже сильно впливає на диск. В ідеалі ситуація має виглядати, скоріше, ось так, тобто у нас тут було менше запису. І ми налаштуваннями можемо це полагодити, щоб далі так було. Т. е. утилізація невелика, але десь щось ми тут пишемо.
Що потрібно зробити, щоб перемогти цю проблему? Якщо у вас зупинилося IO під базою даних, це означає, що всі користувачі, які прийшли виконувати свої запити, будуть чекати.
Якщо подивитися з точки зору Linux, якщо ви взяли хороший hardware, правильно його налаштували, нормально налаштували PostgreSQL, щоб він рідше робив ці checkpoints, розмазував їх за часом один між одним, то ви настаєте в дефолтні параметри Debian. Для більшості дистрибутивів Linux така картина: vm.dirty_ratio=20, vm.dirty_background_ratio=10.
Що це означає? З ядра 2.6 з'явився один demon flushing'а. Pdglush залежно від того, хто який використовує, який займається background'ним скиданням брудних сторінок з kernel buffer і скиданням, коли треба будь-що скидати брудні сторінки, коли вже backgrouind'ное скидання не допомагає.
Коли настає background? Коли 10% від усієї оперативної пам'яті, яка є на сервері, зайнята брудними сторінками в kernel buffer, то викликається спеціальна функція списування в background'і. Чому вона background'на? Вона як параметр приймає у собі, скільки сторінок списати. І, скажімо, списує N сторінок. І на якийсь час ця штука засинає. І потім вона знову приходить і списує ще кілька сторінок.
Це дуже проста історія. Тут завдання як із басейном, коли в одну трубу виливається, в іншу вливається. У нас checkpoint прийшов і якщо він мало брудних сторінок відправив на скидання, то поступово з kernel buffer pgflush ця справа акуратно розсмокчеться.
Якщо продовжують накопичуватись ці брудні сторінки, вони накопичуються до 20 %, після цього в пріоритеті ОС всю цю справу списати на диск, тому що вилетить харчування, і у нас все буде погано. Ми втратимо ці дані, наприклад.
У чому трюк? Трюк полягає в тому, що ці параметри в сучасному світі 20 і 10 % від усієї оперативної пам'яті, яка є на машині, вони абсолютно жахливі точки зору пропускної спроможності будь-якої дискової системи, яка у вас є.
Уявіть собі, що у вас 128 Гб оперативної пам'яті. 12,8 GB приїжджають у вас у дискову систему. І який би кеш у вас там не стояв, який би масив у вас там не стояв, вони не витримають стільки.
Тому ми рекомендуємо ці цифри відразу налаштовувати можливості вашого RAID-контролера. У мене відразу тут дано рекомендацію для контролера, у якого 512 MB кешу.
Вважається все дуже просто. Можна vm.dirty_background у байтах поставити. І ці налаштування скасовують попередні два. Або ratio по дефолту, або активовані ті, що з байтами, то працюватимуть ті, що з байтами. Але оскільки я DBA-консультант і працюю з різними клієнтами, я намагаюся стелити соломки і тому якщо в байтах, то в байтах. Ніхто не дав жодної гарантії, що добрий адмін не підсипле пам'яті серверу, не перезавантажить його, а цифра залишиться тією ж. Просто розраховуйте ці цифри, щоб із гарантією все туди влізло.
Що станеться, якщо ви не влізете? У мене написано, що ефективно зупиняється будь-яка flushing, але насправді це фігура мови. Операційна система має велику проблему – у неї багато брудних сторінок, тому ефективно зупиняється той IO, які породжують ваші клієнти, тобто прийшов додаток sql-запит відправити до бази, воно чекає. Будь-яке введення-виведення до неї – у найнижчому пріоритеті, тому що база зайнята checkpoint. І коли вона його закінчить незрозуміло. І коли ви досягли не фонового, не бекграундного flushing'а, це означає, що у вас все IO зайняте ним. І доки воно не закінчиться, ви нічого не зробите.
Тут є ще два важливі моменти, які виходять за межі цієї доповіді. Ось цим налаштуванням повинні матчитися налаштування в postgresql.conf, тобто налаштування checkpoints. І ваша дискова система має бути адекватно налаштована. Якщо у вас є кеш на RAID, то на ньому має бути батарейка. Люди купують RAID з гарним кешем без батарейки. Якщо у вас SSD в RAID'ом, то вони мають бути серверними, там мають бути конденсатори. Тут розгорнутий чек-лист. За цим посиланням є моя доповідь про те, як налаштовувати диск перформанс в PostgreSQL. Там усі ці чек-листи є.
Що ще дуже може ускладнити життя? Це два параметри. Вони щодо нові. Вони по дефолту можуть бути включені до різних програм. І вони можуть ускладнити життя анітрохи не менше, якщо вони будуть включені неправильно.
Існують дві відносно нові штуки. Вони вже у третіх ядрах з'явилися. Це sched_migration_cost у наносекундах та sched_autogroup_enabled, який по дефолту один.
І як вони псують життя? Що таке sched_migration_cost? Linux scheduler може змігрувати процес з одного CPU на інший. І для PostgreSQL, який виконує запити, міграція на інший CPU зовсім незрозуміла навіщо. З точки зору операційної системи, коли ви перемикаєте вікна між OpenOffice і терміналом, то це, можливо, добре, але для бази даних – дуже погано. Тому розумна політика – поставити migration_cost у якесь велике значення хоча б кілька тисяч наносекунд.
Що це означатиме для scheduler? Вважатиме, що протягом цього часу цей процес все ще гарячий. Т. е. якщо у вас якась довга транзакція чимось довго займається, що scheduler це розумітиме. Він вважатиме, що доки не пройде цей тайм-аут, то мігрувати цей процес нікуди не треба. Якщо при цьому процес щось робить, він не буде нікуди змігрований, він спокійно доопрацює на тому CPU, який йому виділили. І результат виходить чудовий.
Другий момент – це autogroup. Є гарна ідея для специфічних workload, що не мають відношення до сучасних баз даних – це групувати процеси за тим віртуальним терміналом, з-під якого вони запущені. Це зручно для якихось завдань. На практиці PostgreSQL - це багатопроцесна система з prefork'ом, яка запускається з одного терміналу. У вас lock writer, checkpoint і всі ваші запити клієнтів згрупуються на один scheduler, на один CPU. І будуть там дружно чекати, коли він звільниться, щоб перешкодити один одному і позичати його довше. Це історія, яка зовсім не потрібна у разі такого навантаження і тому потрібно вимикати.
Мій колега Олексій Лесовський робив тести з простим pgbench'ом, де збільшував на порядок migration_cost та вимикав autogroup. Різниця на поганій залізці вийшла майже на 10%. Є обговорення в postgres'овій розсилці, де люди наводять результати, як подібні зміни на швидкість запиту впливали на 50%. Таких історій багато.
І насамкінець про power saving policy. Добре, що тепер можна використовувати Linux на ноутбуці. І він нібито добре витрачатиме батарейку. Але зненацька виявляється, що на сервері таке теж може бути.
Більше того, якщо ви берете сервера в оренду у якогось хостера, то «добрі» хостери не дбають про те, щоб у вас була краща продуктивність. Їхнє завдання зробити так, щоб у них залізо утилізувалося максимально ефективно. Тому вони за умовчанням можуть на операційній системі увімкнути ноутбучний режим економії енергії.
Якщо ви використовуєте на сервері з базою даних під інтенсивним навантаженням це добро, то ваш вибір - це acpi_cpufreq + permormance. Навіть із ondemand'ом вже будуть проблеми.
Intel_pstate - вже трохи інший драйвер. І зараз перевага віддається ось цьому, як до пізнішого і добре працює.
І, відповідно, влада тільки реалізує. Ondemand, powersave і все інше - це не про вас.
Результати по explain analyze PostgreSQL можуть відрізнятися на кілька порядків, якщо ви увімкнете Powersave, тому що практично у вас під базою буде шелушитися CPU абсолютно непередбачуваним способом.
Ці речі можуть бути включені за дефолтом. Уважно подивіться – чи не включили вони дефолтом. Це може бути справді великою проблемою.
І наприкінці я хотів подякувати хлопцям з нашої DBA-команди PosgreSQL-Consulting, а саме Максу Богуку та Олексію Лесовському, які щодня набивають на цій справі шишки. І для наших клієнтів ми намагаємося зробити максимально добре, щоб у них все це працювало. Тут як із інструкціями з авіаційної безпеки. Тут усе написано кров'ю. Кожна з цих гайок виявлена у процесі якоїсь проблеми. Я з радістю ними з вами ділюся.
Питання:
Дякую! Якщо, наприклад, компанія хоче заощадити та розміщувати на одному сервері базу даних та application логіку або, якщо компанія слідує модної тенденції мікросервісних архітектур, в яких PostgreSQL запускається в контейнері. У чому фішка? Sysctl глобально на все ядро афекту. Я не чув, щоб sysctl якось віртуалізувалися, щоб вони на контейнері працювали окремо. Є тільки cgroup і там тільки частина є контроль. Як це можна з цим жити? Або якщо хочете performance, то запускайте PostgreSQL на окремому залізному сервері і його тюньте?
Ми відповіли на ваше запитання приблизно трьома способами. Якщо йдеться не про залізний сервер, який можна тюнити і т. д., то розслабтеся, все добре без цих налаштувань працювати. Якщо у вас виникає таке навантаження, що потрібно робити ці налаштування, то до залізного сервера ви прийдете раніше, ніж до цих налаштувань.
В чому проблема? Якщо це віртуалка, то, швидше за все, у вас буде багато проблем, наприклад з тим, що на більшості віртуалок досить неконсистентна latency диска. Навіть якщо пропускна спроможність дисків хороша, то одна транзакція операції вводу-виводу, що збоїлася, не сильно впливає на середню пропускну здатність, яка трапилася в момент checkpoint або в момент запису в WAL, то база від цього буде сильно страждати. І ви це помітите раніше, ніж у ці проблеми упретеся.
Якщо у вас буде NGINX на тому самому сервері, то теж буде та сама проблема. Він битиметься за кулясту пам'ять. І до тих проблем, які тут описані, ви не дійдете.
Але з іншого боку деякі з цих параметрів все одно вам будуть актуальні. Наприклад, з sysctl поставити dirty_ratio, щоб був не такий божевільний - у будь-якому випадку це допоможе. Так чи інакше у вас взаємодія з диском буде. І воно буде за неправильною схемою. Це взагалі дефолт тих параметрів, які я показував. І у будь-якому разі їх краще поміняти.
А з NUMA можуть виникнути проблеми. VmWare, наприклад, добре працює з NUMA з рівно протилежними налаштуваннями. І тут треба вибирати – залізний сервер чи не залізний.
У мене питання, пов'язане з Amazon AWS. Вони мають image преднастроенные. Один з них називається Amazon RDS. Чи є там якісь кастомні налаштування для їхньої операційної системи?
Там є налаштування, але це інші налаштування. Тут ми налаштовуємо операційну систему з погляду того, як база даних цю справу використовуватиме. А там є параметри, які визначають, куди йти нам зараз, такий shaping. Т. е. нам потрібно стільки ресурсів, ми їх зараз виїдатимемо. Після цього Amazon RDS ці ресурси прикручує, і там падає продуктивність. Є окремі історії, як люди починають із цією справою хімічити. Іноді навіть досить успішно. Але це не має відношення до налаштувань ОС. Це ніби хакінг хмари. Це інша історія.
Чому Transparent huge pages не дають ефекту, ніж Huge TLB?
Не дають. Пояснити це можна багатьма способами. Але за фактом вони просто не дають його. Яка історія у PostgreSQL? Він при старті виділяє великий шматок кулястої пам'яті. Transparent вони при цьому чи не transparent – абсолютно не важливо. Той факт, що вони виділяються на старті, пояснює все. І якщо пам'яті дуже багато і потрібно перебудовувати shared_memory segment, то Transparent huge pages буде актуальним. У PostgreSQL він просто на старті виділений величезним шматком і все, і далі там нічого особливого не відбувається. Можна, звичайно, використовувати, але є шанс отримати curruption shared_memory, коли він перевиділяє що-небудь. PostgreSQL про це не знає.
Джерело: habr.com