Связка PostreSQL 8.3.3 + 1C 8.1.12

Залил тестовую базу, запустил 4 сессии с имитацией интенсивной работы в базе (перепроводка документов с интевалом 1сек в каждой сессии)

Производительность просто потрясающая !!!

НО! Проработала эта красота не долго уже почти через 8 часов сервер уходит в длительную задумчивость на элементарные действия типа просморта журнала или простенького запроса.

Вываливает сообщение:

Ошибка СУБД:
ERROR:Out of shared memory
HINT: You might need to increase max_locks_per_trasaction

Помогите разобратся!

Вот он - блеск и нищета опенсорса...

настройки постгреса меняли в соответствии с рекомендациями 1С?

Дык он тебе и написал че делать то...
Буквально дословно: Вам возможно прийдется увеличить max_locks_per_trasaction

максимальную блокировку на транзакцию?

так же, выполнялись ли регламентные операции с БД посредством постгреса?

За основу были взяты настройки рекомендованные 1С(max_locks_per_trasaction
увеличен) + в них был включен автовакум, увеличено shared_bufer и другие
парметры учитывающие большой объем ОЗУ сервера. Этот глюк проявляется на обеих
настройках.

(5) Тех обслуживание выполнялось Полный вакуум+реиндексация толку 0
Объем записей в базе оставался неизменным как было 200 докум так и осталось они лишь перепроводились. x_log за время  вырос эксперимента на 300 Мб не думаю что это критическая цифра слышал про базы на постгрии в десятки гиг

(7) если не секрет на какую ось ставил постгри?

какой-то зверский режим - перепроведение ч/з каждую секунду. 8ч поработал - нормально. рабочий день. перегрузил и следующий день опять работаем нормально.

(7) W2K3

(9) Перезагружать сам сервер не пробывал он рабочий думаю безтолку ибо перзапуск служб сервера 1С и постгри эффекта не дает

(9) Режим может и зверский он разумеется не соотносится с реальным положением дел я таким образом хотел понять выдержит ли сервер не будет ли утечек памяти и пр. Короче ставил эксперимент с целью убедится в надежности выбора. Не думал что потолок будет достигнут на столько быстро. Теперь вот задумываюсь об альтернативах...

(6) например здесь http://kb.1c.ru/articleView.jsp?id=23 и здесь http://users.v8.1c.ru/Info/Platform/8_1_12_98/postgres833.htm
никаких рекомендаций по поводу max_locks_per_trasaction я не вижу.

а конфиг, выставленный по рекомендациям отсюда http://wiki.etersoft.ru/PostgreSQL/Optimum#h250-32
выдавал ошибку в точности как у вас. после смены конфига на дефолтный с параметром effective_cache_size = RAM/2 ошибка ушла.

(13)
Книге Е.М.Болдина

Цитата:
"патч postgresql-1c-8.1.5 несет в себе изменения в исходном файле настроек.
Перчислем их:
.....
.....
максимальное среденее число блокировок увеличино более чем в два раза:
-#max_lock_per_transactio=64
+#max_lock_per_transactio=150
..."

(14) у вас самосборный постгре с патчами под винду? или готовый инсталл под 1С? если 2-е, то типовой конфиг от 1с-ки меняли?

готовый инсталл от 1С да менял разделы перечисленные выше по всем здравым рекомендациям, могу выслать свой конфиг.

чему равно значение параметра shared buffers?

Ужасы нашего городка (с)

shared_buffers = 128MB

попробуйте 32MB

база зашевелилась по советам Estersoft
при установки параметра max_locks_per_transaction=250
shared_buffers=64
отчеты/журналы заработали как и прежде однако
периодический уход в ступор при проведении имеет место быть и видимо это непобедимо :(

У меня есть подозрение что это происходит изза автовакума тормоза возникают как
раз с периодичностью в 5 минут

в логах вижу

2008-09-18 15:10:25 MSD NOTICE:  there is no transaction in progress
2008-09-18 15:10:30 MSD ERROR:  deadlock detected
2008-09-18 15:10:30 MSD DETAIL:  Process 5960 waits for ApplicationExclusiveLock on relation 27485 of database 23530; blocked by process 2356.
   Process 2356 waits for ApplicationShareLock on relation 27345 of database 23530; blocked by process 5960.
2008-09-18 15:10:30 MSD STATEMENT:  LOCK _AccumReg689 IN APPLICATION EXCLUSIVE MODE;
    SET STATEMENT_TIMEOUT TO DEFAULT;
   
2008-09-18 15:10:30 MSD NOTICE:  there is no transaction in progress
2008-09-18 15:10:39 MSD NOTICE:  CREATE TABLE will create implicit sequence "tt74_f_1_seq" for serial column "tt74.f_1"
2008-09-18 15:10:47 MSD LOG:  loaded library "$libdir/plugins/plugin_debugger.dll"
2008-09-18 15:11:09 MSD ERROR:  canceling statement due to statement timeout
2008-09-18 15:11:09 MSD STATEMENT:  LOCK _AccumReg2328 IN APPLICATION EXCLUSIVE MODE;
    SET STATEMENT_TIMEOUT TO DEFAULT;