Форма входа

Логин:
Пароль:

Поиск

Наши координаты

Телефон:
+7 (913) 229 5479
Адрес:
г. Барнаул
пр. Строителей, 16, оф. 613
Почтовый адрес:
656067, Алтайский край, г.Барнаул, 67 отделение связи,
а/я 4180
E-mail:
support@oit-company.ru

Наши партнёры





Суббота, 25.11.2017, 14:03
Приветствуем Вас Гость
Регистрация | Вход | RSS

ОТДЕЛ
ИНФОРМАЦИОННЫХ
ТЕХНОЛОГИЙ
 
Каталог статей


Главная » Статьи » Мои статьи

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

Знакомство с СУБД 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. Эти команды выполняют сбор мусора, выполнение сбора статистики о базе данных для работы планировщика запросов, переиндексацию :

REINDEX DATABASE baza1c_81 FORCE;

VACUUM FULL VERBOSE ANALYZE;

(Хотя с 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 делаем стоп-старт сервера предприятия 1C, PostgreSQL, менеджера лицензий и VACUUM :

#!/bin/sh

# reindex BD

PIDEL=`pidof Xvfb`

if [ ! "$PIDEL" = "" ]; then

##иногда выгрузка из 1С в WINE зависает

kill -9 $PIDEL

fi

################

# stop 1c-server

/bin/sh /etc/rc.d/rc.1c stop

############################

#kill all running session nx

/bin/sh /etc/NX/bin/nxserver --cleanup

sleep 150

########################

###перешли на stop start

/bin/sh /etc/NX/bin/nxserver --stop

/bin/sh /etc/rc.d/rc.sshd stop

rm /tmp/.nX*

rm /tmp/.X*

rm /tmp/.X11-unix/X29 ## следы от запуска Xvfb

######################################

/bin/killall nxserver

/bin/killall nxnode

/bin/killall nxagent

#

sleep 150

/bin/sh /etc/rc.d/rc.sshd start

/bin/sh /etc/NX/bin/nxserver --start

#################

# start 1c-server

sleep 150

/bin/sh /etc/rc.d/rc.1c start

sleep 150

################################

su postgres -c /var/lib/pgsql/backups/vacuumdb.sh


В vacuumdb.sh :

#!/bin/sh

psql -a -f /var/lib/pgsql/backups/vacuum.sql


В vacuum.sql :

VACUUM FULL VERBOSE ANALYZE;

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


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

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


В reindex.sh все тоже, что и в vacuum.sh, за исключением одной строчки. Вместо su postgres -c /var/lib/pgsql/backups/vacuumdb.sh напишем su postgres -c /var/lib/pgsql/backups/reindexdb.sh.


В reindexdb.sh :

#!/bin/sh

psql -a -f /var/lib/pgsql/backups/reindex.sql


В reindex.sql :

REINDEX DATABASE baza1c_81 FORCE;


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


А время идет. Подумываем об использовании 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

Автор sashacd support@oit-company.ru

При перепечатке указание ссылки на www.oit-company.ru обязательно.

Дополнительный материал - книга "Работа с Postgresql: настройка, масштабирование. Дополненное издание". Страничка книги — http://postgresql.leopard.in.ua. Автор Васильев Алексей.

Категория: Мои статьи | Добавил: sashacd (31.07.2010)
Просмотров: 22683 | Комментарии: 3 | Теги: большая база 1С и PostgreSQL | Рейтинг: 0.0/0 |
Всего комментариев: 2
2  
>> Проблема : Как только из 60 остается свободными 1-3 лицензии, тогда 1С у пользователя начинает сильно тормозить в своей работе. Решения пока не нашли.
Так до сих пор и не нашли решения?

1  
Все же решили поделиться опытом smile

Имя *:
Email *:
Код *:

Copyright ООО "Отдел Информационных Технологий" © 2017