Знакомство с СУБД 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).

Первым шагом в 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;

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

Скорее всего уже не 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 не оставляя ему шансов присылать нам эти приветы.

Проблема : После обновления УПП с 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С у пользователя начинает сильно тормозить в своей работе. Решения пока не нашли.

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

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

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