Настройка PostgreSQL для работы в связке с 1С 8.х на платформе Windows Server 2012, объём БД более 200 Гб
Настройка бесплатной СУБД PostgreSQL для работы в связке с 1С 8.х на платформе Windows Server 2012 х64. Объём БД более 380 Гб для мощного сервака. Конфигурация КА 1.1.108.2, 50 пользователей. Более 1 млн. проводок при закрытии месяца. Время закрытия месяца сравнимо с MSSQL и составляет в среднем 2 часа. Время отмены закрытия месяца - всего 10 минут! Ликвидированы зависания PostgreSQL. Всё за счет настроек файла postgesql.conf.
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
>> текущий объем 215 ГБ
Степень bloat проверяли? Используется ли антиблотер, например pgcompacttable? Каков размер после пересчета итогов и последующего vacuum full?
>> work_mem = 2024MB
Совсем озверели.
>> checkpoint_completion_target = 0.9
Очередь и IOPS покажите.
Не увидел режима коммита и wal_level.
В общем, система работает, потому что объем оперативки превышает текущие потребности.
Ну и выбор платформы Windows сомнителен.
Степень bloat проверяли? Используется ли антиблотер, например pgcompacttable? Каков размер после пересчета итогов и последующего vacuum full?
>> work_mem = 2024MB
Совсем озверели.
>> checkpoint_completion_target = 0.9
Очередь и IOPS покажите.
Не увидел режима коммита и wal_level.
В общем, система работает, потому что объем оперативки превышает текущие потребности.
Ну и выбор платформы Windows сомнителен.
>>Сервер 1С 8.3 х64 запущен на этой же машине.
У нас когда база подходила к 300гб, начались тормоза и зависания, процессора (Intel ® Xeon ® E5650 2.4 GHz ) не хватало (в пики постоянная загрузка 98-100%, при 200 активных соединений ), что бы одновременно обрабатывать запросы сервера и 1с и СУБД.
Пришлось основной кластер 1с (всего 3 сервера 1с) и субд, разделить на 2 машины, сейчас БД ~ 600gb полет нормальный в пики видим загрузку процессора субд и 1с только на 50-60%
У нас когда база подходила к 300гб, начались тормоза и зависания, процессора (Intel ® Xeon ® E5650 2.4 GHz ) не хватало (в пики постоянная загрузка 98-100%, при 200 активных соединений ), что бы одновременно обрабатывать запросы сервера и 1с и СУБД.
Пришлось основной кластер 1с (всего 3 сервера 1с) и субд, разделить на 2 машины, сейчас БД ~ 600gb полет нормальный в пики видим загрузку процессора субд и 1с только на 50-60%
(6) dour-dead, В дальнейшем, вероятно, так и сделаем, разнесем PostgreSQL и 1C 8.3 сервер по разным серверам, но пока нагрузка в среднем 10% на процы, пики редкие до 90%. Настроил сервер 1С 8.3 на не более 20 соединений на рабочий процесс и отдельные процессы для каждой БД. В итоге крутится в среднем 3 рабочих процесса, сервер 1С не зависает целиком, если какой-то пользователь вдруг запустил "невозможный" отчет миллионов на 100 проводок по 20 счету. Спасибо за совет.
И ещё. Может быть оправданным вынесение WAL и tmp_tablespace на отдельные диски. На тех серверах на 2xE5*** которые я видел даже на 1U было место и порты где можно было бы разместить пару 2.5" дисков. Мы ставили два SSD в зеркало и размещали там WAL, temp_tablespace + дисковый кэш (на Linux и FreeBSD).
Что(14) vj_still, Что-то мне подсказывает что тест Гилава покажет еще ниже при таких настройках. Во всяком случае после этих рекомендаций у меня с 20 упало до 4. Хотя тест Гилева не панацея, он однопоточный и не всегда показывает актуальные данные. А вот реальная база стала работать быстрее. Во всяком случае проведение и удаление объектов
(14) vj_still, Тест Гилева 9,62, однако реальная база работает быстрее. Ещё бы как-то заставить оптимизатор запросов Postgree выбирать правильные планы запроса без включения/отключения параметра
#enable_nestloop = off, цены бы не было такой настройке
устанавливал
default_statistics_target = 5000, Запускал ANALIZE, как советуют в документации - не помогает,
для некоторых запросов всё равно строится неоптимальный план (к примеру, при заполнении документа Инвентаризация ОС с большим числом позиций помогало только временное отключение плана со вложенными запросами enable_nestloop = off)
отключенный же enable_nestloop = off отрицательно влияет на время расшифровки обороток по 20,23 счетам)
#enable_nestloop = off, цены бы не было такой настройке
устанавливал
default_statistics_target = 5000, Запускал ANALIZE, как советуют в документации - не помогает,
для некоторых запросов всё равно строится неоптимальный план (к примеру, при заполнении документа Инвентаризация ОС с большим числом позиций помогало только временное отключение плана со вложенными запросами enable_nestloop = off)
отключенный же enable_nestloop = off отрицательно влияет на время расшифровки обороток по 20,23 счетам)
Кстати статья с ИТС про enable_nestloop кому интересно:
Решение проблемы с зависанием PostgreSQL
При выполнения некоторых регламентных операций (Закрытие месяца, Расчет себестоимости и т.п), где используются сложные запросы с большим количеством соединений больших таблиц, возможно существенное увеличение времени выполнения операции. В основном, эти проблемы связаны с работой оптимизатора PostgreSQL и отсутствием актуальной статистики по таблицам, учавствующим в запросе.
Варианты решения проблемы:
Увеличить количество записей, просматриваемых при сборе статистики по таблицам. Большие значения могут повысить время выполения команды ANALYZE, но улучшат построение плана запроса:
Файл postgresql.conf - default_statistics_target = 1000 -10000.
Отключение оптимизатору возможности использования NESTED LOOP при выборе плана выполнения запроса в конфигурации PostgreSQL:
Файл postgresql.conf - enable_nestloop=off.
Отрицательным эффектом этого способа является возможное замедление некоторых запросов, поскольку при их выполении будут использоваться другие, более затратные, методы соединения (HASH JOIN).
Отключение оптимизатору возможности изменения порядка соединений таблиц в запросе:
Файл postgresql.conf - join_collapse_limit=1.
Следует использовать этот метод, если вы уверены в правильности порядка соединений таблиц в проблемном запросе.
Изменение параметров настройки оптимизатора:
Файл postgresql.conf:
seq_page_cost = 0.1
random_page_cost = 0.4
cpu_operator_cost = 0.00025
Использование версии PostgreSQL 9.1.2-1.1.C, в которой реализован независимый от AUTOVACUUM сбор статистики, на основе информации об изменении данных в таблице. По умолчанию включен сбор статистики только для временных таблиц и во многих ситуациях этого достаточно. При возникновении проблем с производительностью выполнения регламентных операций можно включить сбор статистики для всех или отдельных проблемных таблиц изменив значение параметра конфигурации PostgreSQL( файл postgresql.conf) online_analyze.table_type = "temporary" на online_analyze.table_type = "all".
После изменнеия этих параметров, следует оценить возможное влияние этих изменений на работу системы и выбрать наиболее приемлимый выриант для ваших задач.
Решение проблемы с зависанием PostgreSQL
При выполнения некоторых регламентных операций (Закрытие месяца, Расчет себестоимости и т.п), где используются сложные запросы с большим количеством соединений больших таблиц, возможно существенное увеличение времени выполнения операции. В основном, эти проблемы связаны с работой оптимизатора PostgreSQL и отсутствием актуальной статистики по таблицам, учавствующим в запросе.
Варианты решения проблемы:
Увеличить количество записей, просматриваемых при сборе статистики по таблицам. Большие значения могут повысить время выполения команды ANALYZE, но улучшат построение плана запроса:
Файл postgresql.conf - default_statistics_target = 1000 -10000.
Отключение оптимизатору возможности использования NESTED LOOP при выборе плана выполнения запроса в конфигурации PostgreSQL:
Файл postgresql.conf - enable_nestloop=off.
Отрицательным эффектом этого способа является возможное замедление некоторых запросов, поскольку при их выполении будут использоваться другие, более затратные, методы соединения (HASH JOIN).
Отключение оптимизатору возможности изменения порядка соединений таблиц в запросе:
Файл postgresql.conf - join_collapse_limit=1.
Следует использовать этот метод, если вы уверены в правильности порядка соединений таблиц в проблемном запросе.
Изменение параметров настройки оптимизатора:
Файл postgresql.conf:
seq_page_cost = 0.1
random_page_cost = 0.4
cpu_operator_cost = 0.00025
Использование версии PostgreSQL 9.1.2-1.1.C, в которой реализован независимый от AUTOVACUUM сбор статистики, на основе информации об изменении данных в таблице. По умолчанию включен сбор статистики только для временных таблиц и во многих ситуациях этого достаточно. При возникновении проблем с производительностью выполнения регламентных операций можно включить сбор статистики для всех или отдельных проблемных таблиц изменив значение параметра конфигурации PostgreSQL( файл postgresql.conf) online_analyze.table_type = "temporary" на online_analyze.table_type = "all".
После изменнеия этих параметров, следует оценить возможное влияние этих изменений на работу системы и выбрать наиболее приемлимый выриант для ваших задач.
У автора предложения при использовании сборки (версии) PostgreSQL-9.4.2-1.1С, а решение проблемы с зависанием PostgreSQL, от Андрея Лукина, приводится с использованием версии PostgreSQL 9.1.2-1.1.C - при выполнении некоторых регламентных операций (Закрытие месяца, Расчет себестоимости и т.п), где используются сложные запросы с большим количеством соединений больших таблиц, возможно существенное увеличение времени выполнения операции. Насколько эти версии отличаются друг от друга? И подойдут предложения для 9.1.2-1.1С к 9.4.2-1.1С.
(28) bulas,
seq_page_cost = 0.1
random_page_cost = 0.4
cpu_operator_cost = 0.00025
установка этих параметров сильно уменьшает время выполнения длительных запросов и для версии 9.4.2-1.1С
enable_nestloop = off - используется в исключительных случаях в запросах по регистрам, связанным с Основными средствами, отключение этого параметра в КА 1.1 замедляет формирование расшифровок обороток по 20-м счетам и поэтому не рекомендуется
seq_page_cost = 0.1
random_page_cost = 0.4
cpu_operator_cost = 0.00025
установка этих параметров сильно уменьшает время выполнения длительных запросов и для версии 9.4.2-1.1С
enable_nestloop = off - используется в исключительных случаях в запросах по регистрам, связанным с Основными средствами, отключение этого параметра в КА 1.1 замедляет формирование расшифровок обороток по 20-м счетам и поэтому не рекомендуется
К автору публикации: можете полный конфиг выложить?
Так как у Вас настроен PG, так настраивать нельзя. Особенно seq_page_cost = 0.1 и enable_nestloop=off.
P.S. Тест Гилёва на клиент-серверных базах не показатель впринципе, бороться там за попугаев не имеет никакого смысла. Есть стандартный нагрузочный тест от Фирмы 1С - это гораздо более приближенно к реальной нагрузке.
Так как у Вас настроен PG, так настраивать нельзя. Особенно seq_page_cost = 0.1 и enable_nestloop=off.
P.S. Тест Гилёва на клиент-серверных базах не показатель впринципе, бороться там за попугаев не имеет никакого смысла. Есть стандартный нагрузочный тест от Фирмы 1С - это гораздо более приближенно к реальной нагрузке.
Всем доброго времени суток!
Если я правильно понял, вышеперечисленные настройки применимы к одной базе, а как быть если их 24?, 2 основные размером 27Гб и 8Гб, а остальные от 1Гб до 11Гб. и крутится все это не на Windows Server а на CentOs 7?.
Подскажите пожалуйста, как мне оптимизировать быстродействие PostgreSQL?.
Если я правильно понял, вышеперечисленные настройки применимы к одной базе, а как быть если их 24?, 2 основные размером 27Гб и 8Гб, а остальные от 1Гб до 11Гб. и крутится все это не на Windows Server а на CentOs 7?.
Подскажите пожалуйста, как мне оптимизировать быстродействие PostgreSQL?.
(36) Я не Линуксоид, но думаю, что PostgreSQL неплохо справляется с обработкой множества баз в одном кластере в любой ОС, тем более на LINUX. На Windows Server у меня сейчас 40 !!! баз крутится в одном кластере, и все немаленького размера. Так что все описанное здесь справедливо для множества баз.
Здравствуйте, Коллеги! Подскажите пожалуйста куда копать в устранении проблемы? У нас периодически падает база postgressql. Мониторинг перед падением показывает перегруз оперативной памяти. В нормальном состоянии база сервера postgresql потребляет 4-6 ГБ оперативной памяти, при падении базы потребление оперативки подскакивает до максимума в 24 ГБ.
Параметры сервера:
Windows server 2016, 8 CPU, 24ГБ RAM.
PostgreSQL Database Server 10.3-2.1C(x64)
Платформа стоит на другой машине.
Конфигурация Документооборот 8 КОРП, редакция 2.1 (2.1.12.2)
Параметры сервера:
Windows server 2016, 8 CPU, 24ГБ RAM.
PostgreSQL Database Server 10.3-2.1C(x64)
Платформа стоит на другой машине.
Конфигурация Документооборот 8 КОРП, редакция 2.1 (2.1.12.2)
(42) effective_cache_size сколько? Потребление памяти в кластере 1с замеряли? Там тоже потребление скачет или только слоник жрет память? Что в логаг PG? Настройки логирования длительных запросов делали? У меня такое было, только проц уходил в потолок. Нашли запрос на стороне 1с зацикленный в расчетах.
Как предположение можно посмотреть maintenance_work_mem и autovacuum_max_workers. Если удаляется много данных и запускается много процессов очистки и подсчета статистики, то выделяется память maintenance_work_mem * autovacuum_max_workers. Но я не знаю, ограничивается ли это выделение параметром effective_cache_size. Это предположение, мало информации. Ни размера базы, ни количества пользователей, ни среднего количества операций в ед времени, ни проводимые обслуживания в тех окно.
Как предположение можно посмотреть maintenance_work_mem и autovacuum_max_workers. Если удаляется много данных и запускается много процессов очистки и подсчета статистики, то выделяется память maintenance_work_mem * autovacuum_max_workers. Но я не знаю, ограничивается ли это выделение параметром effective_cache_size. Это предположение, мало информации. Ни размера базы, ни количества пользователей, ни среднего количества операций в ед времени, ни проводимые обслуживания в тех окно.
(43)
effective_cache_size = 16500MB
maintenance_work_mem = 1GB
autovacuum_max_workers = 4
В кластере память в норме...
Логи к сожалению отключены, пока не разобрался как их настроить. При включении отнимают много системных ресурсов.
Причину нашёл, но как её побороть на стороне постгресса пока не знаю.
Причина оказалось в том, что у некоторых пользователей для поиска добавлены столбцы доп реквизитов внутренних документов 1С ДО.
При динамическом поиске при вводе символов типа "До" постгресс создаёт один процесс который занимает около 800мб памяти и 15% процессора
При вводе символов типа "Договор №365 от" система создаёт 5 процессов postgresql и каждый из них занимает 1.4ГБ памяти и 15% процессора.
В итоге потребление взлетает до 100% и максимально возможной памяти, что в последствии вешает сервер базы данных.
Пока убрал у пользователей функцию динамического поиска.
Может быть кто то подскажет, как это можно побороть на стороне базы данных?
effective_cache_size сколько?
effective_cache_size = 16500MB
maintenance_work_mem = 1GB
autovacuum_max_workers = 4
Потребление памяти в кластере 1с замеряли?
В кластере память в норме...
Что в логаг PG?
Логи к сожалению отключены, пока не разобрался как их настроить. При включении отнимают много системных ресурсов.
Причину нашёл, но как её побороть на стороне постгресса пока не знаю.
Причина оказалось в том, что у некоторых пользователей для поиска добавлены столбцы доп реквизитов внутренних документов 1С ДО.
При динамическом поиске при вводе символов типа "До" постгресс создаёт один процесс который занимает около 800мб памяти и 15% процессора
При вводе символов типа "Договор №365 от" система создаёт 5 процессов postgresql и каждый из них занимает 1.4ГБ памяти и 15% процессора.
В итоге потребление взлетает до 100% и максимально возможной памяти, что в последствии вешает сервер базы данных.
Пока убрал у пользователей функцию динамического поиска.
Может быть кто то подскажет, как это можно побороть на стороне базы данных?
(42)
Попробуйте 11.5-19.1C или тестовую 11.7-5.1C(на днях выложили).
Желательно учесть, при этом, что для 11-й редакции PostgreSQL
Что с более ранними версиями работать совсем не будет, нигде не утверждается, но и обратного тоже.
Впрочем, и 10.12-3.1C тоже есть тестовая, можно и ее попробовать, но для нее тоже
10.3-2.1C уже очень старая.
Попробуйте 11.5-19.1C или тестовую 11.7-5.1C(на днях выложили).
Желательно учесть, при этом, что для 11-й редакции PostgreSQL
Текущая версия PostgreSQL предназначена для использования с версией технологической платформы 1С:Предприятие 8 не ниже 8.3.14.1565
Что с более ранними версиями работать совсем не будет, нигде не утверждается, но и обратного тоже.
Впрочем, и 10.12-3.1C тоже есть тестовая, можно и ее попробовать, но для нее тоже
не ниже 8.3.14.1565
10.3-2.1C уже очень старая.
Добрый день возникла проблема с ошибкой 53100 при этом места на диски с BD есть. Ошибка вываливается при обновление и удаление.
База весит 29 Gb диск 278Gb свободна 249Gb Reid 1 диски sas. Куда копать не пойму. Можете подсказать в чем проблема postgresql прикрепил.
Параметры сервера:
Windows server 2012 R2, 20 CPU, 64 ГБ RAM
PostgreSQL Database Server 10.5-24.1C(x64)
Платформа стоит на другой машине.
При выполнение процесса нагрузки на сервер почти нет.
postgresql вроде выполнен также ток с учетом ттх сервера.
База весит 29 Gb диск 278Gb свободна 249Gb Reid 1 диски sas. Куда копать не пойму. Можете подсказать в чем проблема postgresql прикрепил.
Параметры сервера:
Windows server 2012 R2, 20 CPU, 64 ГБ RAM
PostgreSQL Database Server 10.5-24.1C(x64)
Платформа стоит на другой машине.
При выполнение процесса нагрузки на сервер почти нет.
postgresql вроде выполнен также ток с учетом ттх сервера.
Прикрепленные файлы:
postgresql.conf