Database не пригоден для использования 1с postgresql
Обновлено: 07.07.2024
Оптимизация производительности PostgreSQL для работы с 1С:Предприятие
PostgreSQL приобретает все большую популярность как СУБД для использования в связке с 1С:Предприятие. При этом одним из самых частых нареканий является низкая производительность этого решения. Во многом это связано с тем, что настройки PostgreSQL по умолчанию не являются оптимальными, а обеспечивают запуск и работу СУБД на минимальной конфигурации. Поэтому имеет смысл потратить некоторое количество времени на оптимизацию производительности сервера, тем более что это не очень сложно.
Существуют разные рекомендации по оптимизации PostgreSQL для совместной работы с 1С, мы будем опираться на официальные рекомендации, изложенные на ИТС, также можно использовать онлайн-калькулятор для быстрого расчета некоторых параметров. Если данные калькулятора и рекомендации 1С будут расходиться - то предпочтение будет отдано рекомендациям 1С.
Для тестирования мы использовали систему:
- CPU - Core i5-4670 - 3.4/3.8 ГГц
- RAM - 32 ГБ DDR3
- Системный диск - SSD WD Green 120 ГБ
- Диск для данных - 2 х SSD Samsung 860 EVO 250 ГБ - RAID1
- СУБД - PostgresPro 11.6
- Платформа - 8.3.16.1148
- ОС - Debian 10 x64
Прежде всего выполним тестирование с параметрами по умолчанию:
Полученный результат - 22,32 по Гилеву высоким не назовешь, для субъективного контроля мы использовали конфигурацию Розница 2.2 с базой реального торгового предприятия объемом в 8 ГБ, в целом работу можно было признать удовлетворительной, но местами наблюдалась некоторая "задумчивость", особенно при открытии динамических списков.
Перейдем к оптимизации. Все изменения следует вносить в файл postgesql.conf, который располагается в Linuх для сборки от 1С по пути /etc/postgres/1x/main, а для сборки от PostgresPro в /var/lib/pgpro/1c-1x/data. В Windows данный файл располагается в каталоге данных, по умолчанию это C:\Program Files\PostgreSQL 1C\1х\data. Все параметры указаны в порядке их следования в конфигурационном файла.
Одним из основных параметров, используемых при расчетах, является объем оперативной памяти. При этом следует использовать то значение, которое вы готовы выделить серверу СУБД, за вычетом ОЗУ используемой ОС и другими службами, скажем, сервером 1С. В нашем случае будет использоваться значение в 24 ГБ.
Затем рассчитаем значения отдельных параметров с помощью калькулятора, для чего укажем ОС и версию Postgres, тип накопителя, количество доступной памяти и количество ядер процессора. В поле DB Type указываем Data Warehouses, количество соединений можем проигнорировать, так как вычисляемый результат будет значительно расходиться с рекомендациями 1С.
Теперь можно приступать к редактированию файла конфигурации. Многие значения в нем закомментированы и содержат значения по умолчанию, при изменении таких параметров данные строки следует раскомментировать.
Максимальное число соединений, 1С рекомендует указанные выше значения, мы установили 1000.
Объем памяти для совместного кеша страниц, разделяется между всеми процессами Postgres, рекомендуемое значение - четверть доступного объема памяти, в нашем случае 6 ГБ.
Верхний лимит для временных таблиц в каждой сессии, рекомендуется фиксированное значение.
Указывает объем памяти, который может быть использован для запроса прежде, чем будут задействованы временные файлы на диске. Применяется для каждого соединения и каждой операции, поэтому итоговый объем используемой памяти может существенно превосходить указанное значение. Это один из тех параметров, вычисляемое значение которого калькулятором существенно отличается от рекомендаций 1С. Для объема памяти в 24 ГБ рекомендуемыми значениями будут 375 - 750 МБ, мы выбрали 512 МБ.
Объем памяти для обслуживающих задач (автовакуум, реиндексация и т.д.), указываем рекомендованный калькулятором объем, в нашем случае 2 ГБ.
Максимальное количество открытых файлов на один процесс, в сборке от PostgresPro для Linux это значение по умолчанию.
Параметры процесса фоновой записи, который отвечает за синхронизацию страниц в shared_buffers с диском.
Допустимое число одновременных операций ввода/вывода. Для жестких дисков указывается по количеству шпинделей, для массивов RAID5/6 следует исключить диски четности. Для SATA SSD это значение рекомендуется указывать равным 200, а для быстрых NVMe дисков его можно увеличить до 500-1000. При этом следует понимать, что высокие значения в сочетании с медленными дисками сделают обратный эффект, поэтому подходите к этой настройке грамотно.
Важно! Параметр effective_io_concurrency настраивается только в среде Linux, в Windows системах его значение должно быть равно нулю.
Настройки фоновых рабочих процессов, выбираются исходя из количества процессорных ядер, берем значения из калькулятора. Выше указаны настройки для четырехъядерного СРU.
Заставляет сервер добиваться физической записи изменений на диск. Выключение данной опции хотя и позволяет повысить производительность, но значительно увеличивает риск неисправимой порчи данных при внезапном выключении питания.
Альтернатива отключению fsync, позволяет серверу не ждать сохранения данных на диске, прежде чем сообщить клиенту об успешном завершении операции. Позволяет достаточно безопасно повысить производительность работы. В случае внезапного выключения питания могут быть потеряны несколько последних транзакций, но сама база останется в рабочем состоянии, также, как и при штатной отмене потерянных транзакций.
Задает размер буферов журнала предзаписи (WAL, он же журнал транзакций), если оставить эту настройку без изменений, то сервер будет автоматически устанавливать это значение в 1/32 от shared_buffers, но не менее 64 КБ и не более размера одного сегмента WAL в 16 МБ.
Указывает задержку в мс перед записью транзакций на диск при числе открытых транзакций, указанных во второй опции. Имеет смысл при количестве транзакций более 1000 в секунду, на меньших значениях эффекта не имеет.
Минимальный и максимальный размер файлов журнала предзаписи. Указываем значения из калькулятора, в нашем случае это 4 ГБ и 16 ГБ.
Скорость записи изменений на диск, рассчитывается как время между точками сохранения транзакций (чекпойнты) умноженное на данный показатель, позволяет растянуть процесс записи по времени и тем самым снизить одномоментную нагрузку на диски. В нашем случае использовано рекомендованное калькулятором максимальное значение 0,9.
Стоимость последовательного чтения с диска, является относительным числом, вокруг которого определяются все остальные переменные стоимости, данное значение является значением по умолчанию.
Стоимость случайного чтения с диска, чем ниже это число, тем более вероятно использование сканирования по индексу, нежели полное считывание таблицы, однако не следует указывать слишком низких, не соответствующих реальной производительности дисковой подсистемы, значений, иначе вы можете получить обратный эффект, когда производительность упрется в медленный случайный доступ.
Так как это относительные значения, но не имеет смысла устанавливать random_page_cost ниже seq_page_cost, однако при применении производительных SSD имеет смысл понизить стоимость обоих значений, чтобы повысить приоритет дисковых операций по отношению к процессорным.
Для производительных SSD можно использовать значения:
Но еще раз напомним, данные значения не являются панацеей и должны устанавливаться осмысленно, с реальным пониманием производительности дисковой подсистемы сервера, бездумное копирование настроек способно привести к обратному эффекту.
Определяет эффективный размер кеша, который может использоваться при одном запросе. Этот параметр не влияет на размер выделяемой памяти, не резервирует ее, а служит для ориентировочной оценки доступного размера кеша планировщиком запросов. Чем он выше, тем большая вероятность использования сканирования по индексу, а не последовательного сканирования. При расчете следует использовать выделенный серверу объем RAM, а не полный объем ОЗУ. В нашем случае это 18 ГБ.
Включение автовакуума, это очень важный для производительности базы параметр. Не отключайте его!
Количество рабочих процессов автовакуума, рассчитывается по числу процессорных ядер, не менее 4, в нашем случае 4.
Время сна процессов автовакуума, большое значение будет приводить к неэффективно работе, слишком малое только повысит нагрузку без видимого эффекта.
Отключает политику защиты на уровне строк, данная опция не используется платформой и ее отключение дает некоторое повышение производительности.
Максимальное количество блокировок в одной транзакции, рекомендация от 1С.
Данные опции специфичны для 1С и регулируют использование символа \ для экранирования.
Сохраним файл конфигурации и перезапустим PostgreSQL, в Linux это можно выполнить командами:
В Windows штатными средствами операционной системы, либо скриптами из поставки сборки PostgreSQL:
После чего снова выполним тестирование производительности, на этот раз мы получили следующий результат:
Как видим, достаточно несложные действия по оптимизации добавили серверу около 30% производительности, субъективные ощущения от работы с конфигурацией Розница также повысились, исчезло ощущение "задумчивости", повысилась отзывчивость системы.
Указанные выше настройки и параметры являются базовым набором для оптимизации PostgreSQL при совместной работе с 1С:Предприятие и доступны даже начинающим администраторам. Для выполнения этих действий не требуется глубокого понимания работы СУБД, достаточно просто правильно рассчитать ряд значений. Данные рекомендации основаны на официальных и рекомендуются в качестве базовой настройки сервера СУБД сразу после инсталляции.
Алгоритм резервного копирования баз 1С: 8 средствами PostgreSQL.
(1) lustin,Зачем так сложно ?
cmd - файл в задания под какой нибуть локальной админской записью.
Текстовые файлы, созданные pg_dump предназначаются для последующего чтения программой psql. Общий вид команды для восстановления дампа:
psql имя_БД < файл_дампа
где файл_дампа — это файл, содержащий вывод команды pg_dump. База данных, заданная параметром имя_БД не будет создана данной командой , так что вы должны создать её сами из базы template0 перед запуском psql (например, с помощью команды createdb -T template0 имя_БД)
Ещё следует уточнить что кодировка дампа должна совпадать с кодировкой сервера БД.PostgreSQL не восстанавливает текущую базу из дампа.
Поэтому, я восстанавливаю базу так:
dropdb имя_базы
createdb имя_базы
psql имя_базы < файл_дампа
Мой скрипт восстановления для Linux (работает под пользователем postgres):
if [ -z "$1" ] ; then
echo "Скрипт восстановления базы 1С. Параметры: 1 имя директории бэкапа, 2 имя базы 1С" 1>&2
exit
fi
dropdb $base_name
createdb $base_name
gunzip -c $archive_name | psql $base_name
dropdb -U postgres [имя базы]
createdb -U postgres [имя базы]
pg_restore -U postgres -d [имя базы] [имя файла] Для разграничения архивов по дням: namebase_backup_%date:
Если у пользователя установлен пароль: SET PGPASSWORD=123
"C:\Program Files\PostgreSQL\9.4.2-1.1C\bin\pg_dump.exe" --host localhost --port 5432 --username "postgres" --role "postgres" --no-password --format custom --blobs --section pre-data --section data --section post-data --encoding UTF8 --verbose --file "D:\1cBackupNew\ut11_backup_%date:
(7) Можно ли этим способом делать бэкап базы не выгоняя пользователей из базы? pg_dump — это программа для создания резервных копий базы данных Postgres Pro. Она создаёт целостные копии, даже если база параллельно используется. Программа pg_dump не препятствует доступу других пользователей к базе данных (ни для чтения, ни для записи).Нет, нельзя. Одна операция в 1с меняет данные во многих sql таблицах. Бэкап базы существеннен по времени и у вас нет гарантии, что данные за это время не изменятся. Вы сделаете несколько бэкапов и они будут рабочие, но однажды попадете на восстановление данных. (14) Не вводите людей в заблуждение.
Не только можно, но и в большинстве случаев это единственный вариант. Например если база весит пару терабайт, работает 24/7/365 и каждый час простоя стоит N килобаксов.
А по поводу длительности операции - там снэпшот создается, так что итоговый бэкап получается вполне себе консистентным.
Не знаю как насчет терабайт, а вот с базой 300Гб (select pg_database_size('base');), которая используется 24/7/365, я сначала был такого же мнения как и вы. Бэкап делался минут 40, в течении которых пользователи плевались и матерились, т.к. предприятие тормозило еще как. Так вот в один прекрасный день, когда неудачно прошло обновление конфигурации и база отказалась запускаться, пришлось воспользоваться самым свежим бэкапом, сделанным таким путем, и каково же было мое недоумение, когда он загрузился без проблем, но при открытии в 1с счет фактур предприятие вылетало. Вы можете возразить, что мол кеши надо было чистить, но все это конечно было сделано. Сейчас система переделана. Два сервера: один мастер, другой слейв. Когда нужно сделать бэкап, слейв теряет соединение с мастером, к нему подключается сервер 1с предприятия и средствами 1с делают бэкап. После этого слейв подключается к мастеру и синхронизируется.
Снепшот может и создается (хотя не уверен, а проверять ваши слова лень), но это снепшот sql базы. А вот 1с в этот момент может что-то активно писать и поменять данные в 1 таблице sql, и тут произойдет снепшот sql, а еще в 10 таблицах не успеет поменять, хотя должна, чтобы поддерживать свою логику. Вы же знаете, что одно добавление в регистр записи, может запускать множество других регистраций и каждая из них будет запускаться как одна транзакция в sql. Поэтому данные в базе у вас обязательно испортятся. Возможно база у вас и загрузится и даже работать будет, но данные будут неполными и это аукнется позже. (16), А есть уверенность, что в момент потери связи между серверами 1С были записаны все необходимые движения? Вы считаете что все движения, связанные с проведением документа в 1С происходят в одной 1С транзакции? А есть уверенность, что в момент потери связи между серверами 1С были записаны все необходимые движения?
Я говорил про сервера postgresql, а не 1с. Уверенности конечно нет, но т.к. бэкап делается средствами 1с, то 1с при обнаружении испорченных данных в документе его просто не выгрузит в бэкап. В результате структура базы будет цела, правда за минусом документа.
Ага, не понял вас сразу. То есть фактически плюсом этого решения является то, что боевая база не тормозит в момент бэкапа? Но вот в плане надёжности такого решения я испытываю сильные сомнения. В момент обрыва связи между серверами postgre вероятность потерять данные не меньше чем при снепшоте. То что потом бэкап делается средствами 1С не панацея. Сталкивался я со случаями, когда бэкап из dt не разворачивался из-за сбойных данных внутри.
Добрый день,
Выполнял выше указанные скрипты. Дамп отрабатывает без ошибок, но при попытки сделать восстановление в пустую созданную БД отрабатывает не корректно с ошибками, база не запускается. Так же создаю резервные копии как писали в коментах.
Но есть один вопрос. Иногда требуется срочно восстановить какую нибудь копию базы за определенный день. с командной строки я ее восстанавливаю в новую базу созданную посредством psql, но в 1ске то она не появиться надо вручную ее создать или с помощью 1с или через консоль администрирования 1с. А как через командную строку создать базу в 1с?
Хотелось бы рассказать про еще один "чудесный" способ передачи файла с дампом базы от облачного хостера 1С сервера. Возможно это сможет кому-то съэкономить часов 5 драгоценного времени, особенно для таких как я, которые за 15 лет работы с 1С - за ненадобностью postgre в глаза не видели, да и с линуксообразными тоже не особо.
Типовые ошибки установки сервера 1С:Предприятие и PostgreSQL на платформе Linux.
Связка сервера 1С:Предприятие и PostgreSQL вторая по популярности среди установок 1С и самое используемое решение на платформе Linux. В отличии внедрений на базе Windows и MSSQL, где трудно сделать так, чтобы не заработало, внедрения на базе Linux таят множество подводных камней для неопытного администратора. Часто бывает так, что вроде бы все сделано правильно, но ошибка следует за ошибкой. Сегодня мы рассмотрим самые типовые из них.
Общая информация
Перед тем, как начинать искать ошибки установки и, вообще, приступать к внедрению серверной версии 1С:Предприятия было бы неплохо освежить представление как это работает:
В небольших внедрениях сервер 1С и сервер СУБД обычно совмещают на одном физическом сервере, что немного сужает круг возможных ошибок. В нашем случае будет рассматриваться ситуация, когда сервера разнесены по разным машинам. В нашей тестовой лаборатории мы развернули следующую схему:
Сервер баз данных не обнаружен
ВАЖНО: пользователь "postgres" не прошёл проверку подлинности (Ident)
Данная ошибка возникает при разнесении серверов по разным ПК из-за неправильно настроеной проверки подлинности в локальной сети. Для устранения откройте /var/lib/pgsql/data/pg_hba.conf, найдите строку:
и приведите ее к виду:
где 192.168.31.0/24 - диапазон вашей локальной сети. Если такой строки нет, ее следует создать в секции IPv4 local connections.
Сервер баз данных не обнаружен
could not translate host name "NAME" to address: Temporary failure in name resolution
А теперь вспоминаем, о чем было сказано несколько раньше. Клиентом сервера СУБД является сервер 1С, но никак не клиентский ПК, следовательно запись нужно добавлять на сервере 1С:Предприятие в файл /etc/hosts на платформе Linux или в C:\Windows\System32\drivers\etc\hosts на платформе Windows.
Аналогичная ошибка будет возникать, если вы забыли добавить запись типа A для сервера СУБД на локальном DNS-сервере.
Ошибка при выполнении операции с информационной базой
server_addr=NAME descr=11001(0x00002AF9): Этот хост неизвестен.
где указываете адрес и имя вашего сервера 1С:Предприятия. В случае использования локального DNS следует добавить A-запись для сервера 1С.
Ошибка СУБД: DATABASE не пригоден для использования
Если вы имеете достаточный опыт администрирования Linux систем, то можете попробовать доустановить необходимые библиотеки и заново инициализировать кластер СУБД. В противном случае PostgreSQL лучше переустановить, не забыв удалить содержимое папки /var/lib/pgsql.
Также данная ошибка может возникать при использовании сборок 9.1.x и 9.2.x Postgre@Etersoft, подробности смотрите ниже.
Ошибка СУБД:
ERROR: could not load library "/usr/lib/x86_64-linux-gnu/postgresql/fasttrun.so"
Ошибка СУБД
ERROR: type "mvarchar" does not exist at character 31
или через средство запуска 1С.
Сервер баз данных не обнаружен
ВАЖНО: пользователь "postgres" не прошёл проверку подлинности (по паролю)
Сервер баз данных не обнаружен
FATAL: database "NAME" does not exist
Ошибка формата потока. Восстановление базы при использовании СУБД PostgreSQL
Столь же скупа и информация для технической поддержки:
Обычно это вызывает у пользователей и неподготовленных администраторов тихую панику, особенно если под рукой нет актуальной резервной копии. А судорожные попытки восстановления базы, обычно без понимания смысла выполняемых действий приводят как правило к ее полному разрушению.
К возникновению данной ошибки приводит повреждение основной конфигурации информационной базы. Реже - кеша конфигурации информационной базы, в последнем случае устранить ошибку можно путем очистки кеша, для этого можете воспользоваться нашей утилитой 1:Tools (кто хочет поддержать нас - может скачать ее по ссылке с Инфостарта)
В остальных случаях придется заниматься восстановлением непосредственно базы. В этом месте мы сразу внесем ясность и разделим сущности: информационная база 1С - это хранилище данных на уровне логики 1С:Предприятия которое описывается конфигурацией информационной базы. Т.е. именно здесь содержатся документы, справочники, регистры и т.д. и т.п., а повреждение конфигурации информационной базы делает невозможной работу с ними на этом уровне абстракции. База данных СУБД - это набор таблиц в которых хранятся как данные, так и конфигурация информационной базы 1С.
Повреждение основной конфигурации информационной базы происходит именно на уровне логики 1С:Предприятия, база данных СУБД остается работоспособной и не содержит ошибок с точки зрения СУБД. Если это не так, то мы будем иметь дело с повреждением самой базы данных СУБД, а это уже совсем иная ситуация.
В зависимости от того, какая именно часть конфигурации ИБ оказалась повреждена база может не загружаться в обычном режиме, но загружаться в Конфигуратор, либо вообще не загружаться никак. Если доступен режим конфигуратора, то можно попробовать снять базу с поддержки и загрузить в нее исправную конфигурацию из файла, в некоторых случаях это приведет к успеху, в других может потребоваться сначала выявить и удалить сбойный элемент метаданных.
Все это достаточно сложно и не всегда приносит требуемый результат, поэтому проще и надежнее заменить конфигурацию информационной базы на заведомо исправную используя инструменты СУБД, в нашем случае PostgreSQL. В зависимости от используемой ОС (Windows или Linux) некоторые аспекты работы с PostgreSQL могут отличаться и это будет оговорено отдельно, в остальных случаях указанные команды применяются вне зависимости от платформы.
Перед тем как начинать работу с PostgreSQL в Linuх последовательно повысим свои права для суперпользователя и затем войдем в систему от имени пользователя postgres:
Если утилита sudo не установлена (такой вариант может быть в Debian), то:
В первом случае вам потребуется ввести пароль от текущей учетной записи, во втором - от учетной записи суперпользователя (root).
Затем обязательно сделаем копию информационной базы средствами СУБД. Получить список баз данных в кластере СУБД можно командой:
В Windows вам потребуется ввести пароль пользователя postgres.
Выяснив имя необходимой базы данных выгрузим ее дамп командой:
Где basename - имя нужной базы данных. Обратите внимание, что в Windows мы можем явно задать путь выгрузки дампа, а в Linux выгружаем его в домашнюю директорию пользователя postgres, т.е. /var/lib/postgresql.
Для дальнейших действий нам потребуется развернуть на этом же сервере СУБД еще одну базу с точно такой же конфигурацией информационной базы, это может быть как старый бекап поврежденной базы, так и другая база такой же конфигурации, чистая установка или демо база. Главное, чтобы конфигурация новой базы с точностью до релиза совпадала с конфигурацией поврежденной.
После чего откроем интерактивный терминал PostgreSQL в котором будем производить все последующие действия:
В этом случае выполните:
Теперь подключимся к исправной базе:
где newbasename - имя исправной базы данных. При этом в строке приглашения появится имя подключенной базы.
Из нее мы выгрузим таблицу config в которой находится основная конфигурация информационной базы.
Обратите внимание, при указании пути для операционной системы Windows вы также должны использовать прямой, а не обратный слеш. Также служба СУБД должна иметь права на запись в целевую аудиторию, проще всего это сделать выдав полные разрешения для пользователя Все.
Переподключимся к поврежденной базе:
На всякий случай, также сохраним содержимое таблицы config:
После чего очистим сбойную таблицу:
И загрузим в нее данные из исправной информационной базы:
Для выхода из терминала PostgreSQL введите:
Если все сделано правильно, то поврежденная конфигурация информационной базы будет заменена на исправную и ее работоспособность будет восстановлена.
В некоторых случаях оказывается повреждена не основная конфигурация информационной базы, а конфигурация, открытая на редактирование в Конфигураторе. Внешне это проявляется как невозможность загрузить информационную базу в этом режиме. Для исправления этой ошибки достаточно очистить таблицу configsave:
Как видим, устранение ошибки формата потока средствами СУБД PostgreSQL достаточно несложно, однако требует некоторых навыков работы с данной СУБД. Но если вы будете внимательно и вдумчиво следовать нашей инструкции, то проблем у вас возникнуть не должно.
Читайте также: