По-перше, завжди використовуйте останню версію PostgreSQL. Покращення продуктивності завжди приходить, тому ви, мабуть, витрачаєте свій час, якщо налаштовуєте стару версію. Наприклад, PostgreSQL 9.2 значно покращує швидкістьTRUNCATE і, звичайно, додає сканування, що стосуються лише індексу. Навіть незначні випуски завжди слід дотримуватися; див. політику щодо версій .
Не треба
Ви НЕ покласти табличного на Ramdisk або інший нетривалого зберігання .
Якщо ви втратите простір таблиць, вся база даних може бути пошкоджена і важка у використанні без значних робіт. Перевага в цьому порівняно з просто використанням UNLOGGEDтаблиць і з великою кількістю оперативної пам’яті для кешу в цьому випадку дуже мала .
Якщо ви справді хочете використовувати систему на базі ramdisk, initdbцілий новий кластер на ramdisk, initdbвикористовуючи новий екземпляр PostgreSQL на ramdisk, тож у вас є повністю одноразовий екземпляр PostgreSQL.
Конфігурація сервера PostgreSQL
Під час тестування ви можете налаштувати ваш сервер на нетривалу, але більш швидку роботу .
Це одне з єдиних прийнятних застосувань для fsync=offналаштування в PostgreSQL. Цей параметр в значній мірі говорить PostgreSQL не турбуватися із замовленим записом або будь-яким іншим неприємним захистом цілісності даних та безпекою аварій, що дає йому змогу повністю втратити ваші дані, якщо ви втратите електроенергію або збилися ОС.
Потрібно говорити, що ви ніколи не вмикаєте fsync=offу виробництві, якщо ви не використовуєте Pg як тимчасову базу даних для даних, які ви можете знову генерувати з інших місць. Якщо і тільки якщо ви робите, щоб вимкнути функцію fsync, також можна full_page_writesвимкнути, оскільки це вже не приносить користі. Остерігайтеся цього fsync=offі full_page_writesзастосовуйте їх на рівні кластера , щоб вони впливали на всі бази даних у вашому екземплярі PostgreSQL.
Для виробничого використання ви, можливо, можете використовувати synchronous_commit=offта встановити значення commit_delay, оскільки ви отримаєте багато тих же переваг, що й fsync=offбез гігантського ризику пошкодження даних. У вас є невелике вікно втрати останніх даних, якщо ви вмикаєте асинхронну передачу - але це все.
Якщо у вас є можливість трохи змінити DDL, ви також можете використовувати UNLOGGEDтаблиці в Pg 9.1+, щоб повністю уникнути журналу WAL та отримати реальний приріст швидкості за рахунок стирання таблиць у випадку збою сервера. Немає опції конфігурації, щоб зробити всі таблиці незаблокованими, вона повинна бути встановлена під час CREATE TABLE. Окрім того, що ви корисні для тестування, це зручно, якщо у вашій базі даних є повні генерованих або неважливих даних, які в іншому випадку містять речі, які вам потрібно бути безпечними.
Перевірте свої журнали і побачите, чи отримуєте ви попередження про занадто багато контрольних пунктів. Якщо ви є, вам слід збільшити ваші контрольні_сегменти . Ви також можете налаштувати контрольну точку_комплектування_цілі, щоб згладити її.
Налаштуйтеся, shared_buffersщоб відповідати вашому навантаженню. Це залежить від ОС, залежить від того, що ще відбувається з вашою машиною, і вимагає деяких проб і помилок. Значення за замовчуванням надзвичайно консервативні. Можливо, вам доведеться збільшити максимальний ліміт спільної пам'яті ОС, якщо ви збільшуєтесь shared_buffersна PostgreSQL 9.2 і нижче; 9.3 і вище змінили те, як вони використовують спільну пам'ять, щоб уникнути цього.
Якщо ви використовуєте лише пару з’єднань, які роблять багато роботи, збільште їх, work_memщоб дати їм більше оперативної пам’яті, щоб грати для різного роду тощо. Остерігайтеся, що занадто висока work_memнастройка може спричинити проблеми із пам'яттю, оскільки це не так за з'єднання, тому один запит може мати багато вкладених типів. Збільшити вас дійсно доведеться лише в тому work_memвипадку, якщо ви можете побачити сортування, що проливаються на диск EXPLAINабо ввійшли в систему з log_temp_filesналаштуваннями (рекомендовано), але більш високе значення також може дати Pg вибрати розумніші плани.
Як сказав інший плакат, тут розумно розміщувати xlog та основні таблиці / індекси на окремих жорстких дисках, якщо це можливо. Окремі розділи є досить безглуздим, вам дуже потрібні окремі диски. Такий поділ має набагато меншу користь, якщо ви працюєте з, fsync=offі майже немає, якщо використовуєте UNLOGGEDтаблиці.
Нарешті, налаштуйте свої запити. Переконайтеся, що ваша random_page_costта seq_page_costвідображає продуктивність вашої системи, переконайтеся, що ви effective_cache_sizeправильні тощо. Використовуйте EXPLAIN (BUFFERS, ANALYZE)для вивчення окремих планів запитів та ввімкніть auto_explainмодуль, щоб повідомити про всі повільні запити. Ви можете часто покращити ефективність запитів, просто створивши відповідний індекс або налаштувавши параметри вартості.
AFAIK немає способу встановити цілу базу даних або кластер як UNLOGGED. Цікаво було б це зробити. Розгляньте запитання у списку розсилки PostgreSQL.
Налаштування ОС хоста
Ви також можете виконати налаштування на рівні операційної системи. Головне, що ви можете зробити, це переконати операційну систему не змивати записи на диск агресивно, оскільки вам насправді все одно, коли / якщо вони змусять його на диск.
У Linux ви можете контролювати це з підсистемою віртуальної пам'яті «сек dirty_*настройки, як dirty_writeback_centisecs.
Єдине питання, коли налаштування запису для зворотного зв'язку буде занадто слабким, полягає в тому, що флеш якоїсь іншої програми може призвести до того, що всі накопичені буфери PostgreSQL також будуть змиті, що спричинить великі зупинки, поки все блокується на записі. Ви можете полегшити це, запустивши PostgreSQL в іншій файловій системі, але деякі помилки можуть бути на рівні пристрою або на цілому хості, а не на рівні файлової системи, тому ви не можете на це покладатися.
Ця настройка дійсно вимагає розібратися з налаштуваннями, щоб побачити, що найкраще підходить для вашої роботи.
На нових ядрах ви можете переконатися, що vm.zone_reclaim_modeвін встановлений на нулі, оскільки це може спричинити серйозні проблеми з роботою з системами NUMA (більшість систем сьогодні) через взаємодію з тим, як управляє PostgreSQL shared_buffers.
Налаштування запитів та навантаження
Це речі, які дійсно потребують змін коду; вони можуть вам не підходити. Деякі речі ви можете застосувати.
Якщо ви не займаєтеся великими операціями, почніть. Багато дрібних трансакцій коштують дорого, тому вам слід купувати речі, коли це можливо та практично. Якщо ви використовуєте команду async, це менш важливо, але все-таки настійно рекомендується.
По можливості використовуйте тимчасові таблиці. Вони не генерують WAL-трафік, тому вони набагато швидші для вставок та оновлень. Іноді варто притискати купу даних до тимчасової таблиці, маніпулювати нею, проте потрібно, а потім зробити INSERT INTO ... SELECT ...копіювати її до підсумкової таблиці. Зауважте, що тимчасові таблиці проводяться за сеансом; якщо ваш сеанс закінчується або ви втрачаєте зв’язок, тоді таблиця темп відключається, і жодне інше з'єднання не може бачити вміст темп-таблиць сеансів.
Якщо ви використовуєте PostgreSQL 9.1 або новішу версію, ви можете використовувати UNLOGGEDтаблиці для даних, які ви можете дозволити втратити, як-от стан сеансу. Вони видно на різних сесіях і зберігаються між з'єднаннями. Вони врізаються, якщо сервер закривається нечисто, тому їх не можна використовувати для нічого, що ви не можете створити заново, але вони чудово підходять для кешів, матеріалізованих подань, таблиць стану тощо.
Загалом, не варто DELETE FROM blah;. Використовувати TRUNCATE TABLE blah;замість цього; це набагато швидше, коли ви скидаєте всі рядки в таблицю. Обріжте багато таблиць за один TRUNCATEдзвінок, якщо можете. Існує застереження, якщо ви робите багато TRUNCATESмаленьких столиків знову і знову; див.: Швидкість усікання Postgresql
Якщо у вас немає індексів зовнішніх ключів, DELETEвключення первинних ключів, на які посилаються ці іноземні ключі, буде жахливо повільним. Не забудьте створити такі індекси, якщо ви коли-небудь очікуєте, що DELETEце згадана таблиця (и). Індекси не потрібно для TRUNCATE.
Не створюйте індекси, які вам не потрібні. Кожен індекс має вартість обслуговування. Спробуйте використовувати мінімальний набір індексів, і дозвольте скануванню растрових індексів поєднувати їх, а не підтримувати занадто багато величезних, дорогих багатоколонкових індексів. Там, де потрібні індекси, спробуйте спочатку заповнити таблицю, а потім створити індекси в кінці.
Обладнання
Маючи достатньо оперативної пам’яті, щоб вмістити всю базу даних, це величезний виграш, якщо ви зможете керувати нею.
Якщо вам не вистачає оперативної пам’яті, тим швидше ви можете зберігати місця. Навіть дешевий SSD робить величезну різницю в порівнянні з прядильною іржею. Не довіряйте дешевим SSD для виробництва, хоча вони часто не є безпечними і можуть з'їсти ваші дані.
Навчання
Книга Грега Сміта, PostgreSQL 9.0 High Performance залишається актуальною, не дивлячись на дещо старішу версію. Це має бути корисною довідкою.
Приєднуйтесь до загального списку розсилки PostgreSQL і дотримуйтесь його.
Читання: