Знакомство с СУБД PostgreSQL было определено выходом версии платформы "1С:Предприятие 8.1", в которой была реализована поддержка СУБД PostgreSQL. Но все встречи с PostgreSQL проходили на резервном сервере (с ОС Linux), где методом тестового использования решался вопрос об использовании PostgreSQL в качестве СУБД для рабочей базы 1С. В это время на основном сервере (с ОС Linux) база 1С работала в файл-серверном режиме.До поры до времени шел процесс перехода со старой системы на 1С - нормативно справочная информация была перенесена заранее, а в это время переносились текущие остатки. Количество пользователей (менее 10) и размер файла базы 1С (менее 3Gb) позволяли работать в файл-серверном режиме.
Шло время. Пользователи по мере внедрения переводились из старой системы в 1С. Количество пользователей росло. Размер файла базы данных тоже увеличивался в размере. Настало время подключать к базе 1С удаленных пользователей в терминальном режиме (FreeNX). Количество лицензий опять пришлось увеличить. Хорошо, что получилось поменять один ключ на ключ с большим количеством пользовательских лицензий и количество компьютеров для менеджера лицензий не увеличилось.
И тут произошло самое скучное - размер базы данных 1С вырос до неприличных размеров. Все вместе, количество одновременно работающих в 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 добавляем строку для создания архива:
Запускаем crontab -e:
0 17 * * 0 /var/lib/pgsql/backups/pgdump.sh
:wq
, где 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.
PS. Если начинаете править postgresql.conf, тогда после изменений убедитесь в успешном старте PostgreSQL c новым postgresql.conf. Также необходимо убедиться в успешном создании архивной копии, лучше всего восстановив базу на резервном сервере из архивной копии.
URL:
Обсуждается: http://www.opennet.dev/tips/info/2417.shtml
Вариант для распечатки
on 12-Авг-10, 23:55 
