Налаштування PostgreSQL для продуктивності запису

Один з моїх серверів PostgreSQL розміщує декілька (1-3) баз даних, які отримують постійний потік даних. Дані не особливо структуровані, вони становлять поточний час та різноманітність спостережуваних даних на конкретний момент. Швидкість передачі даних досить висока; він працює приблизно на один гігабайт на день для однієї бази даних, приблизно десяту частину - для іншої. Я не очікую, що цей показник зросте. Продуктивність читання є значно нижчим пріоритетом і наразі є прийнятною.

У журналах я маю це повідомлення:

LOG:  checkpoints are occurring too frequently (15 seconds apart)
HINT:  Consider increasing the configuration parameter "checkpoint_segments".

Наразі це значення встановлено на 16, що люб'язно pgtune.

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

Редагувати: я зараз використовую PostgreSQL 9.0, але планую оновити до 9.1. Я не публікую деталі обладнання, тому що, хоча я визнаю їх важливість, мені в кінцевому підсумку знадобиться зробити цю оптимізацію на кількох машинах з дуже різноманітним обладнанням. Якщо обладнання є важливим для відповіді, будь ласка, дайте мені загальну інформацію, щоб я міг застосувати відповідь до машин з різною конфігурацією обладнання.

1 гігабайт на день - не надто велике навантаження на запис. Розподіляється протягом дня, що виходить приблизно на 50 кбайт в секунду. З цим може впоратися повільний USB-накопичувач. Я припускаю, що це більш лопнуло. Як пропонує a_horse_with_no_name, збільште сегменти контрольної точки. 100 або близько того не є звичайним.

Потім збільшить checkpoint_timeoutдо 1 години, а також погляньте на збільшення свого рівня checkpoint_completion_targetдо 1,0 (100%). Ціль завершення повідомляє PostgreSQL про те, як агресивно писати у фоновому режимі, щоб він завершився на x% перед запуском контрольної точки, яка змусить усі дані виписатись відразу з WAL і сповільнить систему сканування, поки це відбувається.

Причина, яку ви зазвичай не встановлюєте на 100%, полягає в тому, що досить часто писати в один і той же блок не один раз, а відкладаючи WAL, виписуючи в основний магазин, ви запобігаєте тому, щоб той самий блок два рази записувався без жодної причини.

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

У дуже «письмовій вазі» система, ймовірно, обмежена швидкістю, яку WAL може записувати під час пікової активності.

Якщо ви дійсно можете "прийняти втрату деяких останніх даних у випадку невдачі", ви можете вимкнути синхронну комісію, яка:

може бути корисною альтернативою, коли ефективність важливіша, ніж точна впевненість щодо довговічності транзакції

Якщо ви можете змінити обладнання, ви можете розглянути будь-яке з них для оптимізації записів:

• RAID10 за RAID5
• Багато шпинделів (наприклад, може означати 2,5 "замість 3,5")
• SAS через SATA
• 15K понад 10 К накопичувачів
• SSD

--edit

Виходячи з Вашого коментаря до відмінної відповіді @ Скотта : "Обсяг запису насправді майже повністю рівномірний", і мається на увазі швидкість передачі даних "50 кбайт в секунду", я сумніваюся, що Вам потрібно зробити все, що загрожує втратою даних. Можливо, це допоможе дізнатися, для чого встановлено деякі інші параметри конфігурації.

Ви також можете перевірити частоту / розмір ваших комітетів: нещодавно я зіткнувся з проблемою, в якій я намагався оновити> 1 мільйон записів за одну транзакцію. Я отримав повідомлення журналу, подібні до описаних в ОП, але транзакцію не вдалося виконати навіть через кілька годин. Коли я розбив запис на кілька менших транзакцій (10 000 записів або близько того), загальний необхідний час знизився приблизно до 15 хвилин.

Я думаю, що трапилось те, що Postgres витратив стільки часу на написання журналів, що минув checkpoint_timeout, перш ніж він міг досягти значного прогресу в збереженні записів. Я не впевнений, чи може це пояснити. Я все ще отримую попередження, але всі записи з часом обробляються. Однак мені знадобився (і знайшов) програмне рішення, а не одне, що вимагає переналаштування бази даних.

Дивіться також http://www.postgresql.org/docs/9.3/static/wal-configuration.html