Postgres DISK IO дуже високий. Що я можу зробити, щоб негайно її зменшити?

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

Моє налаштування shared_buffers становить 24 Мб, хоча сервер має 16 ГБ оперативної пам’яті, які не використовуються повністю. Моя перша думка полягала в тому, щоб дати базі даних стільки оперативної пам'яті, скільки це може зайняти, але я не впевнений, як це зробити (це виділений сервер бази даних).

Будь-яке рішення, яке не потребує перезавантаження, є кращим, але я візьму те, що я можу отримати в цей момент.

Спасибі!

Налаштування 24_B shared_buffers є консервативним за замовчуванням, я б сказав, що для спеціальної бази даних з 16 ГБ оперативної пам’яті вона повинна бути набагато вище. Але так, вам доведеться перезапустити сервер, щоб змінити його розмір. http://wiki.postgresql.org/wiki/Performance_Optimization - це гарне місце для початку використання інструкцій щодо налаштування продуктивності. Встановлення розділених_буферів на 4 ГБ або 6 ГБ здається більш розумним.

Зауважте, що в Linux вам потрібно відрегулювати налаштування sysctl kernel.shmmax (в /etc/sysctl.conf або просто записати / proc / sys / kernel / shmmax), щоб виділити блок цієї великої загальної пам'яті. Якщо ви не отримаєте помилку із зазначенням кількості запиту, вам доведеться встановити kernel.shmmax вище, ніж це.

Оскільки у вас багато пам’яті, ви можете також розглянути можливість встановлення типового work_mem вище, що зробить такі речі, як сорти та хеші (група / порядок / різний тощо), як правило, працювати в пам'яті, а не використовувати тимчасові файли. Для цього вам не потрібно перезавантажувати сервер, просто оновіть конфігураційний файл, перезавантажте сервіс і нові сеанси отримають нове налаштування. Робоча пам’ять за замовчуванням для сеансу становить 1 МБ, ви можете обчислити максимум, який може бути використаний одночасно, work_mem * max_client_connectionsі оцінити, який вплив буде мати.

Ви також повинні збільшити эффективный_cache_size, щоб вказати планувальнику, що рівень FS ядра, ймовірно, кешує багато сторінок у пам'яті поза спільними буферами postgresql.

і т. д. і ін. сподіваюся, що це змусить вас вдало почати.

Перемонтують диски з noatime

Окрім запропонованих тут пропозицій, ви також можете переглянути свої параметри автоматичного вакуумування. За замовчуванням він запуститься після приблизно 50 оновлень, і якщо у вашій базі даних буде зроблено багато оновлень / вставок, це може викликати непотрібну кількість вакуумних висловлювань, що дасть багато IO.

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

Детальніше дивіться тут .

Якщо diskio у postgresql дуже високий, слід перевірити запущені оператори, особливо для операторів, роблячи "сортування на диску" та встановлення належних індексів.

Просто в Google для "Настроювання продуктивності Postgresql", ви знайдете достатню кількість перешкод, з чого почати.