Знакомство с СУБД 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;».
Решение этой проблемы приведено в статье //infostart.ru/public/18771/.
Для выполнения запросов иcпользуем PgAdminIII
1) "SELECT FROM Config WHERE DataSize > 125829120” - увидеть, что такая запись есть;
2) "DELETE FROM Config WHERE DataSize > 125829120” ;
Но при следующем обновлении конфигурации возможно будут проблемы, которые можно решить прочитав //infostart.ru/public/68793/.
Проблема : При формировании некоторых отчетов 1С вылетает с сообщением о выполняемых недопустимых действиях. Решаем эту проблему обновлением видеодрайвера, или в его свойствах отключаем аппаратное ускорение.
Проблема : Как только из 60 остается свободными 1-3 лицензии, тогда 1С у пользователя начинает сильно тормозить в своей работе. Решения пока не нашли.
