Знакомство с СУБД 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.ru/tips/info/2417.shtml
> учтем время на работу xxx.shА если не сумеете? Нужна только одна запись в cron, то есть пусть /var/lib/pgsql/backups/pgdump.sh в конце скрипта запускает /var/lib/pgsql/backups/vacuum.sh, а тот в конце - /var/lib/pgsql/backups/reindex.sh. И простоя не будет, и если вдруг какой-то скрипт будет выполняться дольше чем планировалось, ничего не обвалится.
А зачем так много файлов?
Я использую такое:
#!/bin/shDATE=`/bin/date --date '-1 day' +%Y%m%d`
BACKUPDIR=/backup
PGUSER=postgres/usr/bin/vacuumdb --all --analyze --full --quiet --username $PGUSER
for i in trade zup montage; do
/usr/bin/find $BACKUPDIR/$i -type f -ctime +45 -delete
/usr/bin/pg_dump --insert --blobs --format=custom \
--username=$PGUSER --file=$BACKUPDIR/$i/$DATE.tgz $i
doneПравда сервер 1С находится на другой машине, скрипт запускаю в 5 утра, у нас в это время не работают.
А зачем "учитываем время работы скрпита" нельзя ли составить однострочник с последовательным выполнением всем команд с помощью &&?
лучше время работы скрипта не учитывать наугад, а сделать проверку на работу предыдущего перед запуском следующего, создавая первичным скриптом lock файл и удаляя его потом
Correct: OS GNU/Linux
А что autovacuum не помогает? :(
И прям таки reindex делать нада???
и ещё меня убивает что все кругом делают VACUUM FULL. Вы доки читали??????????
НЕ РЕКОМЕНДУЕТСЯ ЕГО ДЕЛАТЬ! СМОТРИТЕ http://wiki.postgresql.org/wiki/VACUUM_FULL#When_.28not.29_t...
можно пояснить сакральный смысл REINDEX?
чем не угодил автовакум?> Подумываем об использовании SSD-дисков для размещения WAL
это поможет, да.
Всё это хорошо, но без управляемых блокировок PostgreSQL использовать невозможно, если есть постоянный ввод документов и пользователей больше пяти.
В 1с можно вручную прописать уровни блокировок и тогда постгресина становится вполне себе хорошей заменой MS SQL для 1с.
что это такое. поясните, любопытно. я знаю про транзакции, а упровляемая блокировка это что?
>что это такое. поясните, любопытно. я знаю про транзакции, а упровляемая блокировка
>это что?забанили в гугле?
http://v8.1c.ru/overview/datalockcontrol.htmЗЫ: объясните, мил человек, как можно умудриться сделать ошибку в слове "упрАвляемая"?
> ЗЫ: объясните, мил человек, как можно умудриться сделать ошибку в слове "упрАвляемая"?Помимо ошибок бывают ещё опечатки, это когда человек хотел написать правильную букву но ошибся и нажал не ту клавишу на клавиатуре. Так-то!
>> ЗЫ: объясните, мил человек, как можно умудриться сделать ошибку в слове "упрАвляемая"?
>
>Помимо ошибок бывают ещё опечатки, это когда человек хотел написать правильную букву
>но ошибся и нажал не ту клавишу на клавиатуре. Так-то!человек осьминог? буковки о и а - как то не очень рядышком на клавиатуре. так-то.
>http://v8.1c.ru/overview/datalockcontrol.htmПурга какая то .... У нас одному ERP'у вместо старого оракля подсунули постргресса ... молотит только пыль летит. А великие и ужасные 1C - не ослилили ...
великие и ужасные 1с берут на работу с такой ЗП, что идут туда либо люди одной с директором 1С национальности, либо студенты. И в итоге код выходит курам на смех. То, что они еще живы - это лишь подтверждение тому, что качество софта мало влияет на успешность продукта.
аська, виндовс, 1с, оракл - все одного поля ягоды. И стыдно и завидно. Видать, стабильность разработки больше выгодна программерам, чем конечным пользователям. Которые голосуют кошельком :-)
s/стабильность разработки/качество кода/
Это нельзя ни подтвердить ни опровергнуть.
Однако 1С-прогеры на испытательном сроке получают больше, чем начальник с 3-х летним опытом в Parallels.
>Это нельзя ни подтвердить ни опровергнуть.
>Однако 1С-прогеры на испытательном сроке получают больше, чем начальник с 3-х летним
>опытом в Parallels."За что купил, за то и продаю", и не в курсе, что платит параллелс.
Можете сами это узнать, если интересно.У приятеля сын C-прогером устроился в одну контору после института - 40 т.р.
Гуру у них получает 60 т.р.Обычный 1С-ник с не очень большим опытом в паршивой фирме 80 т.р.
Вы, вероятно, путаете понятия.
1С-ник, пишущий прикладные конфигурации в 1С-платформе для фирм-клиентов - это следующее звено в пищевой цепочке, жирное по деньгам, массовое и с низким порогом входа.Я же говорю о людях, пишущих саму 1С-платформу, гнездящихся в офисе самой фирмы 1С.
>>великие и ужасные 1с берут на работу с такой ЗП, что идут туда либо люди одной с директором 1С национальности, либо студенты.При чем тут национальность?
>>аська, виндовс, 1с, оракл - все одного поля ягоды. И стыдно и завидно.
У Вас есть примеры программ с безупречным кодом и работой?
>При чем тут национальность?имеется в виду закамуфлированный "гастарбайтер"
>У Вас есть примеры программ с безупречным кодом и работой?В мире все относительно, не стоит применять атрибутику идеального мира. И, следуя этой же относительности, перечисленные софты явно не в топе общепризнанного качества.
> У нас одному ERP'у вместо старого оракля подсунули постргресса ... молотит только пыль летит. А великие и ужасные 1C - не ослилили ...Оракл и постгрес версионники, а 1С разрабатывалась под блокировочник, отсюда и проблемы.
Два варианта, которые собственно и озвучены: либо переисать конфигурации на другой тип блокировок, либо сделать из версионника блокировочник и получить деградацию скорости.
Постгрес - версионник.
М$скул - блокировочник.
В МС блокировки построчные.
Реализация 1С на постгресе использует блокировки таблиц, но можно их сделать (в терминах 1С) управляемыми, сиречь - тоже построчными.
Правда, простое переключение блокировок в конфигурации 1С из "автоматических" в "управляемые" ожидаемого результата не даст: требуется ещё и вмешательство в код, что автоматом исключает апдейт до свежих версий платформы.
Поправьте меня, если я неправильно ошибаюсь.
В чем сакральный смысл reindex после vacuum full?
А в чем сакральный смысл не делать reindex после vacuum full? Только опыт использования в каждом случае может ответить на этот вопрос.
>В чем сакральный смысл reindex после vacuum full?
>А в чем сакральный смысл не делать reindex после vacuum full? Только
>опыт использования в каждом случае может ответить на этот вопрос.ответ на этот вопрос может дать вдумчивое чтение документации. дураки учатся на "собственном опыте", читай - ошибках. умные люди - учатся на ошибках чужих.
"REINDEX DATABASE baza1c_81 FORCE;
VACUUM FULL VERBOSE ANALYZE;(Хотя с FULL в первой команде лучше для себя определиться еще раз)"
Автор как истинный программист считает с 0 ? :)
поправился -
"VACUUM FULL VERBOSE ANALYZE;
REINDEX DATABASE baza1c_81 FORCE;"
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /var/lib/pgsql/backups/hasp.restoreменяем на
*/5 * * * * /var/lib/pgsql/backups/hasp.restore
==============
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
hasplm &
echo "$CUR_DATE RESTORE hasplm" >> /var/log/hasp.restore.log
fiменяем на
[ $FLAG -eq 2 ] && echo "$(date +%Y.%m.%d-%H:%M:%S) hasplm running" >> /var/log/hasp.restore.log || {
hasplm &
echo "$(date +%Y.%m.%d-%H:%M:%S) RESTORE hasplm" >> /var/log/hasp.restore.log
}