Тюнінг PostgreSQL 9.4.2-1.1C для 1С: Підприємства 8.3: рельаний досвід налаштування

1. 1. Установка PostgreSQL і pgAdmin.
2. 2. Тюнінг PostgreSQL 9.4.2.

Як тільки розмір файлової бази даних 1С: Підприємство одного з наших клієнтів досяг розміру в 32Гб (так, 32Гб), в наслідок чого все поступово почало гальмувати, а потім і встало намертво, наші клієнти попросили нас вирішити цю проблеми. SSD Enterprise класу ненадовго підсолодив пігулку, але через деякий час все повернулося у вихідну точку. Ну що ж, тут і до ворожки не ходи - переходимо на SQL версію БД.

Оскільки ми затяті користувачі Windows, є нам тільки два варіанти СУБД - це MSSql і PostgreSQL. Перший хороший до божевілля, але вартість не порадувала. А ще більше не порадувала новина про додаткові ліцензії 1С для роботи з MSSQL. Тому PostgreSQL.

Детальна інструкція з відео доступна тут . У цій статті ми пройдемося по ключовим моментам.

Не забуваємо про резервне копіювання баз даних 1С!

Вихідні дані:

• ОС Windows Server 2008R2,
• Intel Core i7-2600K 3.40GHz,
• 32Gb RAM,
• Intel SSD DC3700 100Gb (тільки під БД, ОС на окремому SSD),
• від 10 до 20 користувачів в БД щодня,
• обмін з 5 вузлами розподіленої БД в тлі.

Зловісно, ​​чи не так? Приступимо.

1. Установка PostgreSQL і pgAdmin.

Ніяких одкровень з приводу того, звідки качати PostgreSQL не буде - це наш улюблений сайт https://releases.1c.ru , Розділ «Технологічні дистрибутиви». Викачуємо, ставимо. Не забуваємо встановити MICROSOFT VISUAL C ++ 2010 RUNTIME LIBRARIES WITH SERVICE PACK 1, який йде в архіві з дистрибутивом. Самі попалися на це: чи не встановили, зазнали багато болю.

Ставимо все на далі, далі, крім наступних моментів. Встановлюємо, як сервіс (галочка) і задаємо параметри облікового запису Windows, що не PostgreSQL.

Ініціалізіруем кластер бази даних (галочка). А ось тут задаємо параметри облікового запису для PostgreSQL! Важливо: у Вас повинна бути запущена служба «Secondary Logon» (або на локалізованих ОС: «Вторинний вхід в систему»). Кодування UTF8 - це теж важливо!

Далі нічого цікавого. Далі ...

pgAdmin в цій збірці застарий. йдемо на https://www.postgresql.org/ftp/pgadmin3/release/ . На момент написання статті найсвіжіша версія 1.22.1. Качаємо її, ставимо. Заходимо.

На процесі установки оснащення «Адміністрування серверів 1С Підприємства» не зупинятимемося. Це зовсім інша тема. Та й складного там нічого немає.

Створюємо SQL БД в цьому оснащенню, перевіряємо в pgAdmin - БД там з'явитися, якщо все вказано вірно.

2. Тюнінг PostgreSQL 9.4.2.

Далі вбиваємо себе в голову таке: перед будь-яким збереженням нових налаштувань, робіть резервні копії файлів:

• pg_hba.conf
• postgresql.conf
• pgpass.conf

які лежать тут:

C: \ Program Files \ PostgreSQL \ 9.4.2-1.1C \ data

Якщо Ви помилитеся хоч в одній букві, після поновлення конфігурації PostgreSQL не запуститься. З'ясувати що ж стало причиною буде складно, навіть дивлячись в журнали Windows. Тому не міняйте багато параметрів відразу і робіть резервні копії.

Для редагування конфіга є зручний інструмент, доступний прямо з головного вікна pgAdmin. Ось він:

Що ми тут змінюємо:

• shared_buffers - Кількість пам'яті, виділеної PgSQL для спільного кеша сторінок. Ця пам'ять поділяється між усіма процесами PgSQL. Ділимо доступну ОЗУ на 4. В нашому випадку це 8Gb.
• effective_cache_size - Оцінка розміру кешу файлової системи. Вважається так: ОЗУ - shared_buffers. У нашому випадку це 32Gb - 8Gb = 24Gb. Але особисто я залишаю цей параметр ще нижче, десь 20Gb - все-таки ОЗУ потрібна не тільки для PostgreSQL.
• random_page_cost = 1.5 - 2.0 для RAID, 1.1 - 1.3 для SSD. Вартість читання рандомних сторінки (за замовчуванням 4). Чим менше seek time дискової системи тим менше (але> 1.0) повинен бути цей параметр. Зайве велике значення параметра збільшує схильність PgSQL до вибору планів з скануванням всієї таблиці (PgSQL вважає, що дешевше послідовно читати всю таблицю, ніж рандомно індекс). І це погано.
• temp_buffers = 256Mb. Максимальна кількість сторінок для тимчасових таблиць. Тобто це верхній ліміт розміру тимчасових таблиць в кожній сесії.
• work_mem - Вважається так: ОЗУ / 32..64 - в нашому випадку виходить 1Gb. Ліміт пам'яті для обробки одного запиту. Ця пам'ять індивідуальна для кожної сесії. Теоретично, максимально потрібна пам'ять дорівнює max_connections * work_mem, на практиці такого не зустрічається так як більшість сесій майже завжди висить в очікуванні.
• bgwrite_delay - 20ms. Час сну між циклами записи на диск фонового процесу запису. Даний процес відповідальний за синхронізацію сторінок, розташованих в shared_buffers з диском. Занадто велике значення цього параметра призведе до зростання навантаження на checkpoint процес і процеси, які обслуговують сесії (backend). Мале значення призведе до повного завантаження одного з ядер.
• synchronous_commit - off. НЕБЕЗПЕЧНО! Вимкнення синхронізації з диском в момент коммітов. Створює ризик втрати останніх декількох транзакцій (протягом 0.5-1 секунди), але гарантує цілісність бази даних, в ланцюжку коммітов гарантовано відсутні пропуски. Але значно збільшує продуктивність.

Це далеко не все, що вдалося дізнатися з Інтернету і статей на https://its.1c.ru . АЛЕ! Навіть цих налаштувань вистачить, щоб мабуть прискорити роботу 1С: Підприємство на PostgreSQL.

У цьому конкретному випадку після переходу на PostgreSQL користувачі стали скаржитися, що 1С почала гальмувати ще сильніше, ніж у файловому варіанті. Але після цього тюнінгу база «полетіла». Тепер все насолоджуються швидкою роботою. Однак є і свої мінуси у вигляді блокувань. Зупинятися на це ми не плануємо, будемо копати далі і викладати корисні зміни конфігурації PostgreSQL сюди.

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

Бази даних 1С можна публікувати на веб-серверах !