Оновлення платформи 1с на postgresql. встановлюємо PostgreSQL

Як тільки розмір файлової бази даних 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 вузлами розподіленої БД в тлі.

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

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

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

Ініціалізіруем кластер бази даних (галочка). А ось тут задаємо параметри облікового запису для 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 \u003d 24Gb. Але особисто я залишаю цей параметр ще нижче, десь 20Gb - все-таки ОЗУ потрібна не тільки для PostgreSQL.
random_page_cost \u003d 1.5 - 2.0 для RAID, 1.1 - 1.3 для SSD. Вартість читання рандомних сторінки (за замовчуванням 4). Чим менше seek time дискової системи тим менше (але\u003e 1.0) повинен бути цей параметр. Зайве велике значення параметра збільшує схильність PgSQL до вибору планів з скануванням всієї таблиці (PgSQL вважає, що дешевше послідовно читати всю таблицю, ніж рандомно індекс). І це погано.
temp_buffers \u003d 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 Лис 2012 Переваги використання вільно поширюваного програмного забезпечення очевидні. На жаль, є й недоліки - немає офіційної підтримки, Часто документація суперечлива, неповна і розкидана по різних джерелах. Ця стаття допоможе розібратися з процесом установки PosgreSQL для "1С: Підприємство 8", уникнувши підводні камені, які не описані в офіційній документації.

Необхідні компоненти для установки

СУБД PostgreSQL поширюється безкоштовно і входить в комплект поставки сервера додатків "1С". Сервер додатків "1С: Підприємство 8" поставляється в двох варіантах: 32-розрядний і 64-розрядний. Postgre може працювати з обома.

Отже, маємо на руках дистрибутиви:

Postgre: postgresql-9_1_2-1_1Cx64.zip, люб'язно наданий фірмою "1С".
Дистрибутив сервера додатків "1С: Підприємство" для Windows x64, версії 8.2.16.368.

Здавалося б, чого простіше - запусти і встановиться. Легко! Але установка в стандартному режимі дасть одне невелике обмеження: кластер у нас будуть лежати в папці "Program Files". Не всім це сподобається. Розглянемо два варіанти установки, простий і розширений.

Стаття розбита на 5 розділів:

1) Установка сервера 1C.

2) Установка PostgreSQL в стандартному вигляді, достатньому для запуску 1С без додаткових налаштувань.

3) Установка PostgreSQL з вибором папки зберігання кластера.

4) Створення нової інформаційної бази 1С.

5) Вказівка \u200b\u200bпапки зберігання файлів бази даних на сервері СУБД.

Перед установкою обов'язково прочитайте всю статтю цілком!

Установка сервера додатків 1С

Запускаємо setup.exe з папки з дистрибутивом сервера 1С.

У тому випадку, якщо ви встановите сервер додатків не як сервіс, потрібно буде вручну його запускати кожен раз. Потрібно такий варіант рідко. Встановлюємо як службу (сервіс), і вирішуємо, під яким користувачем він буде запускатися. З міркувань безпеки краще створити окремого користувача USR1CV82, а не дозволяти сервісу працювати під повними правами.

Після установки сервера додатків система запропонує встановити драйвер ключа захисту HASP. погоджуємося:

Чекаємо повідомлення:

Якщо повідомлення буде іншим, в системі, швидше за все, залишилися "хвости" від попередніх установок драйверів HASP. Видаляйте їх все, і пробуйте заново.

Готово, сервер додатків "1С: Підприємство 8" ми встановили успішно.

Установка PostgreSQL в стандартному вигляді, достатньому для запуску 1С без додаткових налаштувань

Запускаємо "postgresql-9.1.2-1.1C (x64) .msi"

Параметри встановлення можна не міняти, 1С працювати буде. Далі.

Postgre, як і сервер 1С, може сам створити користувача, під яким будете запускатися служба. Звертаю вашу увагу на те, що якщо вказати обліковий запис з правами адміністратора, то служба коректно працювати не буде. Завжди створюйте нового користувача.

Наступне вікно установки.

Ініціалізіруем кластер. Якщо у нас сервер баз даних і сервер додатків 1С знаходяться на різних комп'ютерах, Тоді встановлюємо галочку «Підтримую під'єднання з будь-яких IP», інакше не чіпаємо. Обов'язково вказуємо кодування UTF8. Створюємо суперкористувача СУБД. Далі ...

Для початкової роботи нам нічого додаткового не потрібно, знімаємо галочку, завершуємо установку.

Результат наших зусиль - готовий до роботи PostgreSQL. Якщо нас влаштовує, що бази будуть лежати в Program Files \\ PostgreSQL \\ 9.1.2-1.1C \\ data - закінчуємо на цьому, розкриваємо бази і насолоджуємося процесом. Однак, частіше все-таки бази даних "лежать" на спеціально призначених для цього дискових масивах, а не на системному диску. Для того, щоб налаштувати розташування даних, перед установкою прочитайте наступний розділ.

Установка Postgre з вибором місця зберігання кластера

Приступаємо до установки Postgre і виконуємо всі кроки до тих пір, поки нам не запропонують ініціювати кластер:

Знімаємо галочку "Ініціалізувати кластер бази даних" і натискаємо "Далі".

Так, впевнені.

Знімаємо галочку "По виходу запустити Stack Builder" і завершуємо установку.

1. Необхідно видати повні права на папку в яку ми встановили PostgreSQL, зазвичай це C: \\ Program Files \\ PostgreSQL

2. З під адмінських прав запускаємо cmd. Якщо це робите в win7, то запускаємо від Адміністратора.

3. Створюємо папку де буде зберігатися кластер. Наприклад d: \\ postgredata.

md d: \\ postgredata

4. Проводимо ініціалізацію кластера вручну із зазначенням шляху де він буде знаходитися.

"C: \\ Program Files \\ PostgreSQL \\ 9.1.2-1.1C \\ bin \\ initdb.exe" -D d: \\ postgredata --locale \u003d Russian_Russia --encoding \u003d UTF8 -U postgres

5. Видаляємо службу PostgreSQL, яка була встановлена \u200b\u200bв ході установки.

sc delete pgsql-9.1.2-1.1C-x64

Де pgsql-9.1.2-1.1C-x64 - Ця назва служби. Якщо не знаєте назву точно, можна подивитися властивості служби "PostgreSQL Database Server ..." (Пуск - Панель управління - Адміністрування - Служби)

6. Створюємо новий сервіс із зазначенням нашого кластера

"C: \\ Program Files \\ PostgreSQL \\ 9.1.2-1.1C \\ bin \\ pg_ctl" register -N pgsql -U postgresql -P пароль -D d: / postgredata

7. Тепер заходимо в служби. Пуск - Панель управління - Адміністрування - Служби і стартуємо нашу службу.

Створення нової бази даних 1С на сервері з PostgreSQL

Є кілька варіантів створення бази даних. Можна спробувати створювати базу через pgAdmin3, консоль адміністрування серверів 1С. Але тут ви зіткнетеся з масою незрозумілих питань і купою помилок, відповіді на які будете довго шукати. Залиште це для фахівців. Наше завдання отримати працездатну базу з мінімальними зусиллями. Наведемо найпростіший шлях домогтися цього.

Запускаємо клієнт 1С.

Натискаємо "Додати ...".

Придумуємо назву бази, вказуємо "На сервері 1С: Підприємства", далі.

Кластер серверів 1С: Підприємства - localhost, якщо ми створюємо базу на тому ж комп'ютері, де встановлено сервер 1С, або ім'я сервера додатків 1С, якщо на іншому.

Ім'я інформаційної бази в кластері - в подальшому це назва буде вказуватися при підключенні з інших комп'ютерів.

Тип СУБД - Вибираємо PostgreSQL.

Сервер баз даних - вказуємо назву сервера PostgreSQL. Якщо створюємо базу на сервері, так само вказуємо localhost.

Ім'я бази даних - з такою назвою буде створена база в PostgreSQL.

Користувач, пароль - ім'я користувача, якого ми вказували як суперкористувача при установці PostgreSQL. Обов'язково піднімаємо галочку "Створити базу даних в разі її відсутності".

Виникає питання - а де база буде зберігатися фізично? В папці Base зазначеного кластера. А якщо ми не хочемо, щоб вона лежала там, де лежать усі бази? Тут поки нічого вдіяти не можна, просто створюємо базу і рухаємося далі. Далі ...

Вказівка \u200b\u200bпапки зберігання бази даних

Отже, ми створили базу. У більшості випадків на цьому установка закінчується. Однак, якщо баз багато, і є кілька дискових масивів для різних груп баз, потрібно вказати, де фізично повинні розташовуватися бази. Щоб зробити це, запускаємо pgAdmin3 з Пуск - Програми - PostgreSQL. Підключаємося до нашого сервера.

При першому підключенні Postgre попросить пароль для користувача postgres (якого ми створювали при установці).

Створюємо новий TableSpace, це буде та папка, в якій будуть зберігатися наші бази.

Вказали місце зберігання файлів бази. Ок.

Тепер відкриваємо властивості вже створеної раніше бази даних, розміщення якої ми хочемо змінити.

Міняємо властивість Tablespace. Після натискання "ОК" файли бази даних будуть автоматично переміщені. Готово! Сподіваємося, що стаття була вам корисна. Якщо це так - залишайте коментарі, діліться посиланнями на цю сторінку. Дякую!

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

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

Початкові дані:

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

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

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

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

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

2. Тюнінг PostgreSQL 9.4.2.

pg_hba.conf
postgresql.conf
pgpass.conf

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

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

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

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

shared_buffers - Кількість пам'яті, виділеної PgSQL для спільного кеша сторінок. Ця пам'ять поділяється між усіма процесами PgSQL. Ділимо доступну ОЗУ на 4. В нашому випадку це 8Gb.
effective_cache_size - Оцінка розміру кешу файлової системи. Вважається так: ОЗУ - shared_buffers. У нашому випадку це 32Gb - 8Gb \u003d 24Gb. Але особисто я залишаю цей параметр ще нижче, десь 20Gb - все-таки ОЗУ потрібна не тільки для PostgreSQL.
random_page_cost \u003d 1.5 - 2.0 для RAID, 1.1 - 1.3 для SSD.Вартість читання рандомних сторінки (за замовчуванням 4). Чим менше seek time дискової системи тим менше (але\u003e 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 секунди), але гарантує цілісність бази даних, в ланцюжку коммітов гарантовано відсутні пропуски. Але значно збільшує продуктивність.

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

Залишилися питання?

Щось пішло не так? Фахівці нашої компанії допоможуть Вам розібратися з проблемами, що виникли! Звертайтеся! →

Інструкція по установці PostgreSQL 9.0.3-3.1C на Windows Server 2008 x64

Для установки використовуємо пакет - PostgreSQL 9.0.3-1C (x 86 або x 64).

Запускаємо msi-пакет:

Відзначаємо галочкою, якщо не зазначено «Директорія з даними», «psql» і «pgAdmin III». Далі.

Встановлюємо "як сервіс". Для роботи цього сервісу буде потрібно спеціальний користувач. Вказуємо обліковий запис, домен (якщо є) і пароль. Далі.

Якщо такого користувача в системі немає, тоді майстер сам запропонує створити нового. Відповідаємо "так" - користувач створюється. Далі.

Тепер инициализируем БД. Вказуємо порт 5432. Перевіряємо, що кодування UTF 8. Задаємо логін і пароль користувача PostgreSQL (система попереджає, що пароль користувача системи і пароль користувача PostgreSQL НЕ ПОВИННІ збігатися - враховуємо це). Якщо кластер серверів 1С та PostgreSQL на різних машинах, то ставимо галочку «Підтримувати під'єднання з будь-яких IP, а не тільки з localhost». Далі.

Може виникнути помилка « Secondary Logon ». Тоді йдемо в «Адміністрування» - «Служби». Стартуємо службу «Вторинний вхід в систему» \u200b\u200bабо «Secondary Logon»:

Програма встановлюється.

Через меню "Пуск" - "Усі програми" запускаємо утиліту адміністрування «pgAdmin III».

Підключаємося до сервера. Там вводимо пароль для користувача «postgres». Якщо підключитися вдалося, спробуємо створити нову базу засобами самої 1С.

Запускаємо клієнтську частину 1С. Тиснемо кнопку "Додати", ставимо галочку "Сервер підприємства 1С". Далі заповнюємо наступне: сервер бази даних (IP або DNS ім'я того сервера, куди ставили PostgreSQL) - якщо той же, що і кластер 1С, то вказуємо 127.0.0.1. Ім'я бази даних: [любое_імя]. Користувач: "postgres" Пароль: [ваш_пароль_postgres]. Далі.

Перевіряємо, що база 1С створюється успішно.

Нижче зазначені параметри не панацея, їх треба коригувати з урахуванням реальних доступних потужностей. Реальної кількості користувачів і інтенсивності (записується) введення інформації.При налаштуваннях системи також важливо наскільки професійний той, хто налаштовує її.

Яку ОС встановити:

процесор

autovacuum_max_workers \u003d NCores / 4..2 але не менше 4

Кількість процесів автовакуума. Загальне правило - чим більше write-запитів, тим більше процесів. На read-only базі даних досить одного процесу.

Ssl \u003d off

Вимкнення шифрування. Для захищених ЦОД'ов шифрування безглуздо, але призводить до збільшення завантаження CPU

пам'ять

shared_buffers \u003d RAM / 4

Кількість пам'яті, виділеної PgSQL для спільного кеша сторінок. Ця пам'ять поділяється між усіма процесами PgSQL. Операційна система сама кешує дані, тому немає необхідності відводити під кеш всю готівкову оперативну пам'ять.

Temp_buffers \u003d 256MB

Максимальна кількість сторінок для тимчасових таблиць. Тобто це верхній ліміт розміру тимчасових таблиць в кожній сесії.

Work_mem \u003d RAM / 32..64 або 32MB..128MB

Ліміт пам'яті для обробки одного запиту. Ця пам'ять індивідуальна для кожної сесії. Теоретично, максимально потрібна пам'ять дорівнює max_connections * work_mem, на практиці такого не зустрічається так як більшість сесій майже завжди висить в очікуванні. Це рекомендаційне значення використовується оптімайзер: він намагається передбачити розмір необхідної пам'яті для запиту, і, якщо це значення більше work_mem, то вказує екзекьютору відразу створити тимчасову таблицю. work_mem не є в повному розумінні лімітом: оптімайзер може і промахнутися, і запит займе більше пам'яті, можливо в рази. Це значення дає змогу зменшити, стежачи за кількістю створюваних тимчасових файлів:

Maintenance_work_mem \u003d RAM / 16..32 або work_mem * 4 або 256MB..4GB

Ліміт пам'яті для обслуговуючих завдань, наприклад зі збору статистики (ANALYZE), збірці сміття (VACUUM), створення індексів (CREATE INDEX) і додавання зовнішніх ключів. Розмір виділеної під ці операції пам'яті повинен бути порівняний з фізичним розміром найбільшого індексу на диску.

Effective_cache_size \u003d RAM - shared_buffers

Оцінка розміру кеша файлової системи. Збільшення параметра збільшує схильність системи вибирати IndexScan плани. І це добре.

диски

effective_io_concurrency \u003d 2 (тільки для Linux систем, не застосовувати для Windows)

Оцінне значення одночасних запитів до дискової системі, які вона може обслужити одноразово. Для одиночного диска \u003d 1, для RAID - 2 або більше.

Random_page_cost \u003d 1.5-2.0 для RAID, 1.1-1.3 для SSD, 0.1 для NVMe

Вартість читання рандомних сторінки (за замовчуванням 4). Чим менше seek time дискової системи тим менше (але\u003e 1.0) повинен бути цей параметр. Зайве велике значення параметра збільшує схильність PgSQL до вибору планів з скануванням всієї таблиці (PgSQL вважає, що дешевше послідовно читати всю таблицю, ніж рандомно індекс). І це погано.

Seq_page_cost \u003d 0.1 для NVMe дисків autovacuum \u003d on

Включення автовакуума.

Autovacuum_naptime \u003d 20s

Час сну процесу автовакуума. Занадто велика величина буде приводити до того, що таблиці не встигатимуть вакуум і, як наслідок, зросте bloat і розмір таблиць і індексів. Мала величина призведе до марної нагрівання.

Bgwriter_delay \u003d 20ms

Час сну між циклами записи на диск фонового процесу запису. Даний процес відповідальний за синхронізацію сторінок, розташованих в shared_buffers з диском. Занадто велике значення цього параметра призведе до зростання навантаження на checkpoint процес і процеси, які обслуговують сесії (backend). Мале значення призведе до повного завантаження одного з ядер.

Bgwriter_lru_multiplier \u003d 4.0 bgwriter_lru_maxpages \u003d 400

Параметри, що управляють інтенсивністю записи фонового процесу запису. За один цикл bgwriter записує максимум, ніж було записано в минулий цикл, помножене на bgwriter_lru_multiplier, але не більше чемbgwriter_lru_maxpages.

Synchronous_commit \u003d off

Вимкнення синхронізації з диском в момент коммітов. Створює ризик втрати останніх декількох транзакцій (протягом 0.5-1 секунди), але гарантує цілісність бази даних, в ланцюжку коммітов гарантовано відсутні пропуски. Але значно збільшує продуктивність.

Checkpoint_segments \u003d 32..256< 9.5

Максимальна кількість сегментів WAL між checkpoint. Занадто часті checkpoint призводять до значного навантаження на дискову підсистему по запису. Кожен сегмент має розмір 16MB

Checkpoint_completion_target \u003d 0.5..0.9

Ступінь «розмазування» checkpoint'a. Швидкість запису під час checkpoint'а регулюється так, що б час checkpoint'а дорівнювало часу, що пройшов з минулого, помноженому на checkpoint_completion_ target.

Min_wal_size \u003d 512MB .. 4G\u003e \u003d 9.5 max_wal_size \u003d 2 * min_wal_size\u003e \u003d 9.5

Мінімальна і максимальна обсяг WAL файлів. аналогічно checkpoint_segments

Fsync \u003d on

Вимкнення параметра призводить до зростання продуктивності, але з'являється значний ризик втрати всіх даних при раптовому виключенні живлення. Увага: якщо RAID має кеш і перебувати в режимі write-back, перевірте наявність і функціональність батарейки кеша RAID контролера! Інакше дані записані в кеш RAID можуть бути втрачені при виключенні живлення, і, як наслідок, PgSQL не гарантує цілісність даних.

Commit_delay \u003d 1000

паузу (в мікросекундах) перед власне виконанням збереження WAL

Commit_siblings \u003d 5

Мінімальна кількість одночасно відкритих транзакцій, при якому буде додаватися затримка commit_delay

Груповий Комміт декількох транзакцій. Має сенс включати, якщо темп транзакцій перевищує 1000 TPS. Інакше ефекту не має.

Temp_tablespaces \u003d "NAME_OF_TABLESPACE"

Дисковий простір для тимчасових таблиць / індексів. Приміщення тимчасових таблиць / індексів на окремі диски може збільшити продуктивність. Попередньо треба створити tablespace командою CREATE TABLESPACE. Якщо характеристики дисків відрізняються від основних дисків, то слід в команді вказати відповідний random_page_ cost. Див..

row_security \u003d off\u003e \u003d 9.5

Відключення контролю дозволу рівня запису

Max_files_per_process \u003d 1000 (default)

Максимальна кількість відкритих файлів на один процес PostreSQL. Один файл це як мінімум або індекс або таблиця, але таблиця / може складатися з декількох файлів. Якщо PostgreSQL впирається в цей ліміт, він починає відкривати / закривати файли, що може позначатися на продуктивності. Діагностувати проблему під Linux можна за допомогою команди lsof.

Мережа

max_connections \u003d 500..1000

Кількість одночасних коннектов / сесій
Якщо у Вас більше 100 користувачів, то краще вказати вручну значення для цього параметра за кількістю користувачів

Типова проблема в Windows

Помилка СУБД: could not send data to server: No buffer space available (0x00002747 / 10055)

При використанні операційної системи Windows, Максимальне стандартне число тимчасових TCP-портів одно 5000. При спробі встановити TCP-з'єднання через порти, номери яких перевищують 5000, видається повідомлення про помилку. Іншими словами, треба збільшити кількість доступних портів в реєстрі, де виберіть Parameters (HKEY_LOCAL_MACHINE \\ SYSTEM \\ CurrentControlSet \\ Services \\ Tcpip \\ Parameters) і додайте наступного параметр реєстру MaxUserPortз типом: DWORDі значенням: 65534 (Можна вибрати зі значень 5000-65534)

блокування

max_locks_per_transaction \u003d 256

Максимальне число блокувань індексів / таблиць в одній транзакції

Налаштування під платформу 1С

standard_conforming_strings \u003d off

Дозволити використовувати символ \\ для екранування

Escape_string_warning \u003d off

Чи не видавати попередження про використання символу \\ для екранування

Shared_preload_libraries \u003d "online_analyze, plantuner"

кілька поділюваних бібліотек, які будуть завантажуватися при запуску сервера
якщо зазначена в ньому бібліотека не буде знайдена, сервер не запуститься
настройка параметра має більше значення для linux, хоча і windows її робити теж варто

Модуль online_analyze надає набір функцій, які негайно оновлюють статистику після операцій INSERT, UPDATE, DELETE або SELECT INTO в цільових таблицях.
Модуль plantuner додає підтримку вказівок для планувальника, що дозволяють відключати або підключати певні індекси при виконанні запиту.

Online_analyze.enable \u003d on

Включає аналіз статистики тимчасових таблиць, часто використовуваних в 1С

оптимізатор

default_statistics_target \u003d 1000 -10000

(Поліпшення статистики оптимізатора)

Enable_nestloop \u003d off, enable_mergejoin \u003d off

(Зміна параметрів оптимізатора)
● Включає або відключає використання планувальником планів з'єднання з вкладеними циклами
● Включає або відключає використання планів з'єднання злиттям.
Наприклад помилки типу out of memory

Join_collapse_limit \u003d 1

(Відключення при розумінні порядку з'єднань таблиць!)
● При значенні, рівному 1, пропозиції JOIN переставлятися не будуть, так що явно заданий в запиті порядок
з'єднань визначить фактичний порядок, в якому будуть з'єднуватися відносини.
Інші настройки впливають на оптимізатор

From_collapse_limit \u003d 20

● Задає максимальну кількість елементів у списку FROM, до досягнення якого надасть права зносити в нього явні конструкції JOIN (за винятком FULL JOIN). При менших значеннях скорочується час планування, але план запиту може стати менш ефективним.
● seq_page_cost \u003d 0.1 random_page_cost \u003d 0.4 cpu_operator_cost \u003d 0.00025

Online_analyze.table_type \u003d "all"

(Більше навантаження)
Типи таблиць, для яких виконується негайний аналіз: all (всі), persistent (постійні), temporary (тимчасові), none (ніякі).

Online_analyze.threshold \u003d 50

● Мінімальна кількість змін рядків, після якого може початися негайний аналіз (цей параметр подібний до autovacuum_analyze_threshold).

Online_analyze.scale_factor \u003d 0.1

Відсоток від розміру таблиці, при якому починається негайний аналіз (цей параметр подібний до autovacuum_analyze_scale_factor).

Online_analyze.min_interval \u003d 10000

● Мінімальний інтервал часу між викликами ANALYZE для окремої таблиці (в мілісекундах).

Online_analyze.local_tracking \u003d off

● Включає в online_analyze відстеження тимчасових таблиць в рамках обслуговуючого процесу. Коли ця змінна відключена (off), online_analyze використовує для тимчасових таблиць системну статистику за замовчуванням.

Online_analyze.verbose \u003d "off"

● Вимкнення докладні повідомлення розширення online_analyze

Plantuner.fix_empty_table \u003d "on"

● plantuner буде обнуляти число сторінок / кортежів в таблиці, яка не містить ніяких блоків у файлі