gifts2017

Опыт обслуживания базы 1С в PostgreSQL.

Опубликовал Александр Григорьев (sashacd) в раздел Администрирование - Системное

...Время шло. Размер системного каталога PostgreSQL с базой 1C достиг размера 35Gb. Размер dt-файла выгрузки базы 1С стал где-то около 1.2Gb, а развернутая база на его основе 16Gb. И как-то пришло время придумать что-то еще для обеспечения производительной работы пользователей в 1С...

Знакомство с СУБД PostgreSQL было определено выходом версии платформы «1С:Предприятие 8.1», в которой была реализована поддержка СУБД PostgreSQL. Но все встречи с PostgreSQL проходили на резервном сервере (с ОС Linux), где методом тестового использования решался вопрос об использовании PostgreSQL в качестве СУБД для рабочей базы 1С. В это время на основном сервере (с ОС Linux) база 1С работала в файл-серверном режиме.

До поры до времени шел процесс перехода со старой системы на 1С. Ну это понятно — нормативно справочная информация была перенесена заранее, а в это время переносились текущие остатки, ну и так далее. Количество пользователей (менее 10) и размер файла базы 1С (менее 3Gb) позволяли работать в файл-серверном режиме.

Шло время. Пользователи по мере внедрения переводились из старой системы в 1С. Количество пользователей росло. Размер файла базы данных тоже увеличивался в размере.

Настало время подключать к базе 1С удаленных пользователей в терминальном режиме (FreeNX). Количество лицензий опять пришлось увеличить. Хорошо, что получилось поменять один ключ на ключ с большим количеством пользовательских лицензий и количество компьютеров для менеджера лицензий не увеличилось.

И тут произошло самое скучное — размер базы данных 1С в PostgreSQL вырос до неприличных размеров.

Все вместе - количество одновременно работающих в 1С пользователей более 10 и размер файла базы данных 1С более 4Gb, стало очень негативно сказываться на производительности работы пользователей в 1С.

Настало время серьезного знакомства с возможностью размещения базы 1С в СУБД PostgreSQL. Пользуясь знакомством с СУБД PostgreSQL, переезд на SQL-версию размещения данных 1С прошел быстро и без жертв (сервер с ОС Linux).

Время шло. Размер системного каталога PostgreSQL с базой 1C достиг размера 35Gb. Размер dt-файла выгрузки базы 1С стал где-то около 1.2Gb, а развернутая база на его основе 16Gb. И как-то пришло время придумать что-то еще для обеспечения производительной работы пользователей в 1С. Пользуясь документацией PostgreSQL, которая идет в комплекте с СУБД, оформилось две команды по обслуживанию базы «baza1c_81» в PostgreSQL. Эти команды выполняют сбор мусора, выполнение сбора статистики о базе данных для работы планировщика запросов, переиндексацию :

VACUUM FULL VERBOSE ANALYZE;

REINDEX DATABASE baza1c_81 FORCE;

(Хотя с FULL в первой команде лучше для себя определиться еще раз самостоятельно, http://wiki.PostgreSQL.org/wiki/VACUUM_FULL и в документации PostgreSQL см. VACUUM).

Далее дело техники. Определили время запуска. В воскресенье с 17-00 до понедельника 6-00 в базе никого не бывает. В cron отключаем ночное архивирование базы в это время (а архивировать лучше как средствами 1С, так и pgdump). Помним о том, что в файле cron'а должна быть последняя пустая строка. Если файл cron'а редактировали во внешнем редакторе, тогда делаем crontab -e и в нем - :w, :q.

Первым шагом в cron добавляем строку создание архива :

0 17 * * 0 /var/lib/pgsql/backups/pgdump.sh, где 0-мин, 17-час, *-день, *-месяц, 0-(день недели воскресенье);

Вторым шагом добавляем в cron строку выполнения первой команды :

0 18 * * 0 /var/lib/pgsql/backups/vacuum.sh, учтем 30 минут на работу pgdump.sh посозданию архива;

 

Команда vacuum.sh по факту работает от 6 до 8 часов.

Третьим шагом добавляем в cron строку выполнения второй команды :

30 3 * * 1 /var/lib/pgsql/backups/reindex.sh, учтем время на работу vacuum.sh;

 

 

Команда reindex.sh выполняется не более 1 часа.

И в каждый понедельник база готова к эффективной работе.

А время идет. Подумываем об использовании SSD дисков для размещения WAL. И знакомство с вариантом работы в 64-bit системе состоялось.

 

PS Если начинаете править postgresql.conf, тогда после изменений убедитесь в успешном старте PostgreSQL c новым postgresql.conf. А также необходимо убедиться в успешном создании архивной копии, лучше всего восстановив базу на резервном сервере из архивной копии.

PS Расчет себестоимости.... иногда этот расчет начинает очень сильно задумываться о чем-то своем. Так вот, в этом случае можно попробовать отключить в конфигурационном файле PostgreSQL autovacuum, выполнить стоп-старт "Менеджер лицензий-Сервер предприятия-PostgreSQL". После расчета себестоимости в конфигурационном файле вернуть все назад, стоп-старт. Оценить время расчета и сделать вывод о необходимости  повтора  этих действий.

Скорее всего уже не PS, а далее. Больная тема — остановка менеджера лицензий. И точнее всего эта остановочка прикладывается в пятницу, вечером. Это когда подходит время в цехе запустить 1С и добавить в систему отчет производства за смену, или на складе готовой продукции идет отгрузка во вторую смену. В другие дни решить эту проблему помогает удаленный доступ, но в пятницу....

По странному стечению обстоятельств, именно вечером в пятницу, меньше всего желающих поплавать в бассейне. И не воспользоваться этим нельзя, что мы и делаем. Но вот с удаленным доступом из бассейна пока дела обстоят плохо. Наверно надо менять его. Бассейн. Но это наверно в следующем сезоне.А пока для спокойного выполнения пятничных планов делаем маленькое дополнение в cron, а именнодобавляем следующую строку :############
# Restore hasplm#
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /var/lib/pgsql/backups/hasp.restore
В hasp.restore запишем :#!/bin/sh
FLAG=$(ps -A | grep hasplm | wc -l)
CUR_DATE=20$(date +%y).$(date +%m).$(date +%d)-$(date +%H)$(date +%M)$(date +%S):
if [ $FLAG -eq 2 ]
then
    echo "$CUR_DATE hasplm running" >> /var/log/hasp.restore.log     
else
    #echo "false"
    hasplm &
    echo "$CUR_DATE RESTORE hasplm" >> /var/log/hasp.restore.log    
fi
И после выполнения crontab -e (читай про него выше), с необходимым интервалом будет происходить проверка работы менеджера лицензий и запуск его в случае необходимости.Еще добавим в каталоге logrotate.d в файле syslog два файла для logrotate(автоматическая архивация log-файлов, см).../var/mail/root /var/log/hasp.restore.log ...А потом в свободное время смотрим tcpdump(или еще как то), вычисляем с какого адреса забивают наш менеджер лицензий. А там тоже может стоять менеджер лицензий, и даже совсем не 1С. Если находим такой адрес, добавляем правило в iptables не оставляя ему шансов присылать нам эти приветы.

Несколько замечаний про 2011 год.

Поставили диски
SSD для WAL и Log PostgreSQL. Intel X25 - 2 шт. А вот что это дало, сказать сложно, прошлые замеры были при одной базе, а сейчас в PostgreSQL их уже несколько. Да и база подросла. Вот отключить бы SSD и посмотреть, но на рабочем сервере это не получится.

Проблема : После обновления УПП с 1.2.х на 1.3.х, не работает создание резервной копии средствами СУБД PostgreSQL, а именно работа pg_dump завершаеся с ошибкой - «pg_dump: Команда была: COPY public.config (filename, creation, modified, attributes, datasize, binarydata) TO stdout;».
Решение этой проблемы приведено в статье http://infostart.ru/public/18771/.
Для выполнения запросов иcпользуем PgAdminIII
1) "SELECT FROM Config WHERE DataSize > 125829120” - увидеть, что такая запись есть;
2) "DELETE FROM Config WHERE DataSize > 125829120” ;

Но при следующем обновлении конфигурации возможно будут проблемы, которые можно решить прочитав http://infostart.ru/public/68793/.

Проблема : При формировании некоторых отчетов 1С вылетает с сообщением о выполняемых недопустимых действиях. Решаем эту проблему обновлением видеодрайвера, или в его свойствах отключаем аппаратное ускорение.

Проблема : Как только из 60 остается свободными 1-3 лицензии, тогда 1С у пользователя начинает сильно тормозить в своей работе. Решения пока не нашли.

 

 

Скачать файлы

Наименование Файл Версия Размер
vacuum.sh и reindex.sh 178
.7z 0,74Kb
04.02.12
178
.7z 0,74Kb Скачать

См. также

PowerTools от 1 000
Подписаться Добавить вознаграждение

Комментарии

1. Дмитрий Шерстобитов (DitriX) 09.08.10 05:05
тоже встал вопрос о том на чем ставить 1с, постгри на линуксе или мускул на Р2...
Не сравнивали ли Вы случайно вот таких 2 варианта, а то интересно, где же шустрее и проще...
2. Марат (MaratL) 09.08.10 08:24
2DitriX 1C на мускуле не живёт.
Или я не так понял?
3. Александр Григорьев (sashacd) 09.08.10 09:08
(1) Производительность одной и той же базы(текущей) в PostgreSQL и MS SQL к сожалению не сравнивали. Второго аналогичного по ТТХ сервера нет, на рабочем ставить MS SQL не судьба. А на обычном компе не интересно. Все сравнения были в начале, и в общем то на маленьких по объему базах.
4. Vladimir B (Vladimir7799) 09.08.10 09:32
Год назад делал сравнение производительности , пробывал sql 2000, 2005 and postgres под windows. Под виндой 1. место - 2000, второе 2005, третье postgres. При условии установки по умолчанию, без тонкой настройки. После настройки postgres повышает производительность, но проигрывает мелкософтовским продуктам. Под linux с минимальной насторойкой postgres показывает производительность почти как 2000 под виндой. Сейчас у меня 2 сервака крутятся под linux - надежно и без гемора. При активном использовании базы претензий к работе вообще нет. Серваки перегружаются где то раз в пол года, по причине что в конторе просто выключают электроэнергию для профработ на выходные. По поводу статьи - вакуум можно делать и почаще :D Можно использовать pgAdmin.
5. Vladimir B (Vladimir7799) 09.08.10 09:35
Да забыл .. тест производил под windows server 2003 r2, Linux openSuse 11.1 . железо использовалось для тестов одно и тоже, на чистую операционку.
6. fastwriter (fastwriter) 09.08.10 09:56
Очень нужная статья - по работе 1ц с Linux и Postgree материалов пока недостаточно.
7. Александр Григорьев (sashacd) 09.08.10 13:32
(4) Чаще vacuum не делаем(там есть FULL) - и надеемся на autovacuum
8. Vladimir B (Vladimir7799) 09.08.10 14:02
Зря надеетесь на autovacuum. хотя full достаточно раз в одну- две недели делать, зависит от нагружености базы. Кстати какой из linux -ов используете?
9. Александр Григорьев (sashacd) 09.08.10 16:16
(8) На рабочем сервере сейчас стоит MOPS 32bit, ядро пересобрали(памяти много, поэтому добавляли PAE). Для различных эксперементов успешно устанавливалось еще на SLES 64bit, Slackware.
10. Денис Яковлев (iceflash) 11.08.10 15:34
опыт хороший, но я бы хотел узнать как у вас так быстро выросла БД, или если это не БД, а всего лишь каталог Data где лежит "много" всего. Сам использую Postgres и доволен, сама бд очень нарвиться, не только в качестве субд для 1С (1с, кстати очень извратились из-за лени видимо, со своим патчем по поводу блокировок, чем самым, производительность данной субд значительно падает и при хорошей производительности будет равна ms sql)
интересен так же конфиг, разделы автовакуума, анализа, и распределения памяти. На моеми проекте работает 28-30 пользователей, база 11 Гб.
Опять же бесит еще одна ошибка 1С (ух, как же я люблю их называть 1ц) это проблемы со штатным бэкапом когда конфигурация стоит на поддержке.
11. Александр Григорьев (sashacd) 11.08.10 18:13
(10) Путь базы - 01.01.2008 старт в файл сервере - 01.08.2008 старт в PostgreSQL - август 2010 работаем дальше в PostgreSQL. Предприятие у нас производственное - много документов отчет производства за смену(наработка и выпуск).
Одновременно работает в базе наверно пользователей 35(плюс минус), вообще ключей 50 и все были заняты.
Конфиг, разделы автовакуума, анализа, и распределения памяти, а также все эксперементы это тема отдельной статьи....
Штатный бекап делается ночью в wine(dt). Еще pgdump запускается ночью и в обед.
12. Денис Яковлев (iceflash) 11.08.10 18:30
Просто меня на данный момент интересуют пара вопросов, по тюнингу постгрес в этих направлениях потому и было бы очень интересно сравнить/посмотреть. А зачем делает еще выгрузку информационной базы штатными средствами 1С? (были случаи когда из бэкапа постгреса не смогли восстановить?)
13. Александр Григорьев (sashacd) 11.08.10 19:02
(12) Зачем штатными? - это когда с утра хотят пользователи поэксперементировать со вчерашними данными - и побыстрее хотят. Или дома посмотреть базу.(Если не корректные параметры postgresql.conf, то не сделает архив, логи конечно будут, но шанс пролететь есть)

А postgresql.conf можем и обменяться + sysctl + config ядра

14. Денис Яковлев (iceflash) 11.08.10 19:08
Ага, надо будет обменяться=) Кстати пару раз возникала проблема с присвоением нового номера для документа, штатными средствами, не встречались с таким, было именно несколько раз за пол год. т.е. при вызове метода установки нового номера возвращается значение существующего уже документа (это как то связанно с обработкой самой БД) но данная проблема, как пришла так и ушла без изменения кода=)
15. Александр Григорьев (sashacd) 11.08.10 19:14
(14) Нет, такого не было. Вот только на последнем сервере предприятия установили только 4 рабочих процесса, на предыдущем релизе делали 6. Но с 6 стало как то тормозить.
16. Денис Яковлев (iceflash) 11.08.10 19:18
у нас на том объекте 2 процесса на сервере 1ц. А баз 3 :
2 типовых бух-ии (6-10 пользователей в каждо)
1 разработка отдельная (28-30 пользователей)
17. Александр Григорьев (sashacd) 11.08.10 19:22
да кстати тоже не стали мудрить - все на один сервак взвели - pgsql и сервер предприятия, freenx и базы в файл-серверном исполнении. Получилось как раз до кризиса сервак купили - пока тянет. А кстати у вас в postgresql несколько баз 1с?
18. Денис Яковлев (iceflash) 11.08.10 19:33
там сейчас такая структура один сервак(8Гб процессор мощный не помню какой точно, но общая загрузка 10-13% рэйд массив 5) на нем 1ц сервер, и постгрес для конфы разработанной на 11 Гб (28-30 пользователей)
Другой комп, просто средний с сата дисками на нем постгрес для 2-х баз бухгалтерии и еще там 2 зупа файловых, работает там в этих базах не много народу, до 10 пользователей.
Но в 1-ой базе крутится служебный пользователь которы, из бух-ии тянет данные по 60,62 счету, и все документы для акта сверки (Счет, Реализация, Поступление услуг, банковские выписки)
19. Брест Беларусь (zhleonid8) 29.09.11 13:36
проверено, терминал ставь , рейд массив,
20. Иван Шевченко (imshev) 18.10.11 14:05
а в чем причина таково нереального размера вы не разбирались?
21. пцкпц цкуцкпцу (йцукенн) 20.12.11 10:43
Под Win 2008R2, медленно работал 1с в связке с PostgresqL.
Перенесли Postgresql на cервер Linux, поставили автовакуум, последний релиз сервера 1с и сборки Postgresql для 1с. В настоящий момент быстродействие увеличилось примерно в полтора раза. Тестировали на проведении документов за весь период ведения учета.
22. пцкпц цкуцкпцу (йцукенн) 20.12.11 10:46
Посмотрите логи БД, почистите их по необходимости.
23. Александр Григорьев (sashacd) 25.12.11 19:19
Проблема : После обновления УПП с 1.2.х на 1.3.х, не работает создание резервной копии средствами СУБД PostgreSQL, а именно работа pg_dump завершаеся с ошибкой - «pg_dump: Команда была: COPY public.config (filename, creation, modified, attributes, datasize, binarydata) TO stdout;».


Решение этой проблемы приведено в статье http://infostart.ru/public/18771/

Для выполнения запросов иcпользуем PgAdminIII
1) “SELECT FROM Config WHERE DataSize > 125829120” - увидеть, что такая запись есть;
2) “DELETE FROM Config WHERE DataSize > 125829120” ;
24. Михаил Госьков (ГМВ) 04.02.12 20:07
"Проблема : Как только из 60 остается свободными 1-3 лицензии, тогда 1С у пользователя начинает сильно тормозить в своей работе. Решения пока не нашли."
По моим наблюдениям, проблема существует и при большем количестве свободных лицензий, если поиск ключей происходит в режиме BROADCAST = Enable.
25. Дмитрий Ли (Shaka13) 16.10.14 03:03
У меня на останавливается и не перезапускается демон pgsql кто-нибудь сталкивался с таким?
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа