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

   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 добавляем строку для создания архива:
Запускаем 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.  Также необходимо убедиться
в успешном создании архивной копии, лучше всего восстановив базу на резервном
сервере из архивной копии.

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

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

Для спокойного выполнения пятничных планов делаем маленькое дополнение в cron,
а именно добавляем следующую строку :

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