1С 8.1.12.98

Любые запросы в отчетах накладывают эксклюзивную блокировку на всю таблицу регистра. Это я определил, выполняя в момент формирования отчета в консоле управлением сервера запрос select * from pg_locks;
пока отчет выполняется там тысячи(!) записей о эксклюзивных блокировках поэтому делаю вывод что вся таблица стоит.
Из-за чего имею постоянный вылет:

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

Вставки управляемых блокировок перед выполнением запроса ситуацию не меняют хотя в модулях проведения управляемые блокировки отрабатывают корректно. Почему так?

Да увеличение приведенных в ошибке параметров проблемму не решают, оно вроде и помогает времеменно но
при добавлении в базу очередной порции информации всё повторяется вновь.

Кто-нить сталкивался?

Странно, у меня УТ на постгресе крутится, 30 юзеров, отчеты и проведение доков постоянно делается, в среднем по 10 deadlock в день.

Случаем режим разделения итогов регистров не включен?

(2) да включен для регистра бухгалтерии, но отчет не по нему, а по регистру накопления!

Дык этим то и отличается PostGre от MS SQL.... Что он блин блокировку на всю таблицу накладывает....

а конфигурация типовая?

(4) включен режим управляемых блокировок он как раз под постгрии делался
(5) нет не типовая

(6) Понятно. У меня типовые нормально работают с PostgreSQL без вышеуказанных проблем. А вам, скорее всего, необходимо оптимизировать код в соответсвии с рекомендациями из базы знаний http://kb.1c.ru

(6) режим включен, а модули дописаны?

(8)разумеется дописаны я же это писал выше, более того к докам вопросов нет блокировки работают корретно что было подтверждено испытаниями. Единсственная проблема возникала с регистром бухгалтерии но там выкртились установкой разделения итогов опсле чего можно реально одновременно проводить документы с неконфликтными измерениями. Теперь грабли с отчетами валят он 1С изза блокировок хотя по логике запросы на чтения ну никак не должны накладывать эксклюзивные блокировки а они валятся в pg_locks пачками при этом в этот момент доки вообще не проводятся тобишь дело в отчете. Но он прост как пять пальцев запрос по таблице остатков и оборотов могу привести код если нужно. не знаю что там можно оптимизировать

(9) да ну, почему не должны? смотря как запрос написан

(6) (1) дайте конфиг к серверу может у меня руки кривые вроде все рекомендации по настройке выполнил. сервант не слабый W2K3

(10) запрос в отчете без признака "ДЛЯ ИЗМЕНЕНИЯ" почему он должен чтото блокировать эксклюзивно???

(12) все таки рекомендую ознакомится с базой знаний, например http://kb.1c.ru/articleView.jsp?id=44 либо книгу "Профессиональная разработка в системе 1С:Предприятие"

ну вот, например, кусочек статьи

Если в структуре базы данных отсутствует индекс, удовлетворяющий всем перечисленным условиям, то запрос может отрабатывать неоптимально. В результате этого может увеличиться время выполнения запроса и количество блокировок, которые он устанавливает на уровне СУБД.

(13) хе, я б с радостью, ток доступа нет

(13) да и в регистре накопления по которому делается запрос 5 измерений 4 из них с признаком индексирования этого мало? Или речь о доп.индексах PostgreSQL?

(11) отправил

Вот что в логах:

2008-09-25 10:27:04 MSD STATEMENT:  create temporary table tt4 (_Period timestamp,_Recorder_TYPE bytea,_Recorder_RTRef bytea,_Recorder_RRRef bytea,_Fld471RRef bytea,_Fld51RRef bytea,_Fld577RRef bytea,_Fld50RRef bytea,_Fld53Receipt numeric(21,3),_Fld53Expense numeric(21,3),_Fld53InitialBalance numeric(21,3),_Fld53FinalBalance numeric(21,3)) WITHOUT OIDS
2008-09-25 10:27:04 MSD NOTICE:  there is no transaction in progress
2008-09-25 10:28:16 MSD WARNING:  out of shared memory
2008-09-25 10:28:16 MSD ERROR:  out of shared memory
2008-09-25 10:28:16 MSD HINT:  You might need to increase max_locks_per_transaction.
2008-09-25 10:28:16 MSD STATEMENT:  create temporary table tt5 (_Period timestamp,_Recorder_TYPE bytea,_Recorder_RTRef bytea,_Recorder_RRRef bytea,_Fld50RRef bytea,_Fld577RRef bytea,_Fld51RRef bytea,_Fld471RRef bytea,_Fld53Receipt numeric(21,3),_Fld53Expense numeric(21,3),_Fld53InitialBalance numeric(21,3),_Fld53FinalBalance numeric(21,3)) WITHOUT OIDS
2008-09-25 10:28:16 MSD WARNING:  out of shared memory
2008-09-25 10:28:16 MSD ERROR:  out of shared memory
2008-09-25 10:28:16 MSD HINT:  You might need to increase max_locks_per_transaction.
2008-09-25 10:28:16 MSD STATEMENT:  select * from pg_locks;
2008-09-25 10:28:16 MSD NOTICE:  there is no transaction in progress
2008-09-25 10:31:50 MSD WARNING:  out of shared memory
2008-09-25 10:31:50 MSD ERROR:  out of shared memory
2008-09-25 10:31:50 MSD HINT:  You might need to increase max_locks_per_transaction.
2008-09-25 10:31:50 MSD STATEMENT:  create temporary table tt6 (_Period timestamp,_Recorder_TYPE bytea,_Recorder_RTRef bytea,_Recorder_RRRef bytea,_Fld471RRef bytea,_Fld51RRef bytea,_Fld577RRef bytea,_Fld50RRef bytea,_Fld53Receipt numeric(21,3),_Fld53Expense numeric(21,3),_Fld53InitialBalance numeric(21,3),_Fld53FinalBalance numeric(21,3)) WITHOUT OIDS
2008-09-25 10:31:50 MSD NOTICE:  there is no transaction in progress
2008-09-25 10:41:04 MSD WARNING:  out of shared memory
2008-09-25 10:41:04 MSD ERROR:  out of shared memory
2008-09-25 10:41:04 MSD HINT:  You might need to increase max_locks_per_transaction.
2008-09-25 10:41:04 MSD STATEMENT:  create temporary table tt7 (_Period timestamp,_RecordKind numeric(1,0),_Fld2329RRef bytea,_Fld2330RRef bytea,_Fld2331RRef bytea,_Fld2332_TYPE bytea,_Fld2332_RTRef bytea,_Fld2332_RRRef bytea,_Fld2333 boolean,_Fld2334 numeric(15,2),_Fld2335 numeric(15,2),_Fld2336RRef bytea,_Fld2337RRef bytea) WITHOUT OIDS
2008-09-25 10:41:04 MSD NOTICE:  there is no transaction in progress

и вот еще:

2008-09-25 11:53:46 MSD WARNING:  out of shared memory
2008-09-25 11:53:46 MSD ERROR:  out of shared memory
2008-09-25 11:53:46 MSD HINT:  You might need to increase max_locks_per_transaction.
2008-09-25 11:53:46 MSD STATEMENT:  SELECT
   _Document511._IDRRef AS f_20,
   _Document511._Version AS f_21,
   _Document511._Marked AS f_22,
   _Document511._Date_Time AS f_23,
   _Document511._NumberPrefix AS f_24,
   _Document511._Number AS f_25,
   _Document511._Posted AS f_26,
   _Document511._Fld658RRef AS f_27,
   _Document511._Fld709RRef AS f_28,
   _Document511._Fld2263 AS f_29,
   _Document511._Fld513RRef AS f_30,
   _Document511._Fld2129RRef AS f_31,
   _Document511._Fld1300 AS f_32,
   _Document511._Fld1301 AS f_33,
   _Document511._Fld516RRef AS f_34,
   _Document511._Fld2382RRef AS f_35,
   _Document511._Fld781_TYPE AS f_36,
   _Document511._Fld781_RTRef AS f_37,
   _Document511._Fld781_RRRef AS f_38,
   _Document511._Fld517 AS f_39,
   _Document511._Fld518RRef AS f_40,
   _Document511._Fld2381RRef AS f_41,
   _Document511._Fld519 AS f_42,
   _Document511._Fld520 AS f_43,
   _Document511._Fld655RRef AS f_44,
   _Document511._Fld2101 AS f_45,
   _Document511._Fld521RRef AS f_46,
   _Document511._Fld523RRef AS f_47,
   _Document511._Fld573RRef AS f_48,
   _Document511._Fld524RRef AS f_49,
   _Document511._Fld631 AS f_50,
   _Document511._Fld608RRef AS f_51,
   _Document511._Fld525RRef AS f_52,
   _Document511._Fld706 AS f_53,
   _Document511._Fld526 AS f_54,
   _Document511._Fld527 AS f_55,
   _Document511._Fld530RRef AS f_56,
   _Document511._Fld2262 AS f_57,
   _Document511._Fld531 AS f_58,
   _Document511._Fld1223RRef AS f_59,
   _Document511._Fld656RRef AS f_60,
   _Document511._Fld2426RRef AS f_61,
   0 AS f_1
   FROM
   _Document511
   WHERE
   _Document511._IDRRef = '\\210\\327\\000\\030\\347\\011$\\011\\021\\335\\211d\\337\\265\\220\\221'::bytea
2008-09-25 11:53:46 MSD NOTICE:  there is no transaction in progress
2008-09-25 11:53:46 MSD WARNING:  out of shared memory
2008-09-25 11:53:46 MSD ERROR:  out of shared memory
2008-09-25 11:53:46 MSD HINT:  You might need to increase max_locks_per_transaction.
2008-09-25 11:53:46 MSD STATEMENT:  create temporary table tt1 (_RecorderTRef bytea,_RecorderRRef bytea,_Period timestamp,_LineNo numeric(9,0),_AccountDtRRef bytea,_AccountCtRRef bytea,_Fld1366RRef bytea,_Fld1398DtRRef bytea,_Fld1398CtRRef bytea,_Fld1368 numeric(15,2),_Fld1369Dt numeric(15,2),_Fld1369Ct numeric(15,2),_Fld1370Dt numeric(15,3),_Fld1370Ct numeric(15,3),_Fld1371 mvarchar(50)) WITHOUT OIDS
2008-09-25 11:53:46 MSD NOTICE:  there is no transaction in progress

(16) не нашел ничего революционного в конфиге только

deadlock_timeout = 2147483
ну да у меня 2сек как рекомендуют на кажом столбе
и видимо поэтому и вываливает, а тут просто система будет уходить в глубокий даун. Шило на мыло ИМХО

(0) Покажи postgresql.conf
а так же ответь ты документ новый проводишь или старый правишь?

(21) лишь перепровожу. Но проблемма связана както косвенно с проведением. Ибо собственно сабж мучает в момент формирования отчета иногда в параль проведению иногда вообще без какой либо параллельной работы в базе

своконфиг

тьфу конфиг выслал (21)

(20) deadlock_timeout = 2147483 это в милисекундах, короче это те же 2 сек. Больше он не дает.

(212) Особено строки
"shared buffers"
"Max connections"
"effective_cache_size"

а так же инфа на яком и подчем крутится Postgres

(22) Если перепроводиш скажи такую вещь, у тебя в этих доках какой режим стоит в в разделе "Движения" - "Удаление движений"?

вот сейчас вообще загадочно выкинуло
смотрю select * from pg_locks там тишина

запускаю проводку дока с однойс строчкой
сразу рой блокировок в pg_locks
и вылет
перезпускаю 1с вхожу в отчет повторяется
тоже самое такое ощущение что он
повторяет гдето отложенные блокировки.

Блин пошло гадание на кофейной гуще

(27) везде автоматическое удаление

(26) не совсем понял. Полный конфиг выслал на почту
вот вдержка:
shared_buffers = 128MB
max_connections = 30
effective_cache_size = 1024MB

сервер W2K3 4ядра, 4Гб озу, SCSI

(29) Поставь max_connections = 100 не меньше
на счет авто удаление, если перепроводиш доку то при удалении он блокирует все таблицы где было движение, делай ручное удаление и пиши код в модуле для удаления

(31) не понял причем тут max_connections у меня юзверей до 20 и потолок 30 не вижу связи. На счет автоматического удаления тоже непонятно как тогда у меня получается доки параллельно проводить (по разным измерениям разумеется)? Ведь это рабоет и сейчас! Но обязательно поэкспериметнирую.

(32) На винде очень даже причем, у тя в логах "MSD WARNING:  out of shared memory" проскакивает
на счет движения если док новый только создан да он будет проводить параллельно но если ты пепепроводиш док то он сначала удаляет движения вот в этот момент и блокировка таблицы

(32) Добавь еще
"commit_delay = 100" - для отложеной записи транзакции 100 мс
"synchronous_commit = on"
"wal_sync_method = 'open_datasync'"
"full_page_writes = off"
"default_statistics_target = 100"
"constraint_exclusion = on"

(32) Да и ваще W2K3 нужно хоронить и ставить Linux + ИБП, тогда можно будет сделать fsync = off скорость в разы подымится, можеш на винде попробывать но оставлять не рекомендую глюкнит винда все слетит в базе

(33) поставил на одном доке "не удалять движения автоматически"
перепровожу старый - вылет
создаю новый - создался добавил одну строчку провожу - вылет

вернул всё в зад
перезапустил  постгрее захожу открываю любой док провожу всё в ажуре

запускаю в одном сеансе перепроведение с интервалом 2 сек
смотрю select * from pg_locks;
блокировки есть но количество в пределах разумного (50-250) в основном shared и rowExclusive
в другом сеансе запускаю отчет по регистру и понеслась сплошные ExclusiveLock (6000-8000) и вылеты во всех сессиях

up

Как не странно max_connections = 100 действительно дало изменение, а именно вместо ошибки 1с просто уходит в ступор при этом  select * from pg_locks; показывает уже дестяки тысяч эксклюзивных блокировок. Причем вырубание сеанса 1с не прекращает множение этих самых блокировок . Похоже косячит сервер 1С. После перезапуска сервера 1с и постгрии проблемма на время пропадает но вновь и вновь повторяется :(

конфу надо оптимизировать

(41) что именно? Хоть намекните в каую сторону смотреть, а так это всё общие слова ни о чем

(36) Поменять статус удаления не достаточно нужно в модуле проведения включить процедуру удаления в виде кода в твоем случае 1с пыталась тупо записать еще раз движения которые уже были записаны

(40) Попробуй задать больше ....
А ваще лучше скажи у тебя сервер приложений находится отдельно?
Используешь и поток процесса в сервере приложений?

(44) Последний вопрос читать так
Используешь и несколько потоко процесса в сервере приложений?

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

(44) Сейчас сервер приложения 1с находится на том же сервере где и postgreSQL там же терминал т.к. все в режиме тестирования

(45) не знаю как этим пользоваться предполагаю что один поток по умолчанию.

(46) Мдя.... рассадник получился
еще тогда вопрос ты смотрел загрузку компа в момент работы?
интересует уже доступность озу в этот пик, интенсивность обмена с диском и особено с его очередью, загрузка процессоров, так же понаблюдай за процесовм rphost прыгает ли потребление озу в верх и вниз периодически?

(47) весь объем озу задействованого всем этим рассадником не превышет 1Гиг при доступных 4х, общая загрузука сервера в пиках не превышает 30% при всевозможных тестах тоибшь мощности процов с запасом хватает. Очередь диска не знаю как посмотреть но думаю и там будет в пределах допустимого.

(42) на мыло отправил статейку

дело точно  не в железе,
думаю возможны варианты:

1)кривая конфа? Но управляемые блокировки работают. Подскажите что еще было не учтено. У кого реально работает на серьзных объемах и с большим количеством регистров учета в том числе и бухгалтерии (а с ним не все просто в плане блокировок - исп. разделение итогов)?
2)сервер 1с валит лишние эксклюзивные блокировки. Может в топку постгри и да здраствует MSSQL ? IBM DB2 похоже совсем экзотика.
3)Кривой конфиг для постгри? Настройки делал по Гилеву. Подскажите что не учтено?

(48) Надо не думать а смотреть, открывал "системный монитор" задавай счетчики и смотри показатели ...

(50) Я тебе не на железо пытаюсь указать а интенсивность обмена данными, если ты гриш что вначале все ок а уж потом идут тормоза значить кому то нехватает ресурсов..

p.s. У мя на посте крутятся 6 баз бухгалтерии размером от 500 до 3000 метров, 5 баз зарплаты от 300-1500 метров, база сертификатов около 1 гига и 2 торговли в районе 4 гиг все это висит на одном сервере где кроме постгре ниче нету, далее в 2 сервера под сервер приложений один слабенький он же центральный отвечает больше за обслуживание 1с на нем вертится 1 процес кластера сервера приложений с низкими стоимостью, второй мощный и еще в качетсве терминала работает на нем вертятся 4 процесса кластера сервера приложений с самыми высоким стоимостью на него большенство запросов идет все это крутится и вертится без тормозов

средняя очередь на запись 60-80 (только не понятно чего) бывают пики до 200-240

(53) Во во ! дисковая система узкое место, походу поток увеличивается даных и оно тормозит, какой максимальный и средний поток записи и чтения? да еще запусти что ли якой нить утилу которая тестирует скорость диска може кеш у тя на рейде не врубен на запись?

кэш рэйда включен 100%

(55) Давай так, правь конфу

Снизим нагрузку на диск
"random_page_cost = 4.0"

повысим нагрузку на процы
"cpu_tuple_cost = 0.001"
"cpu_index_tuple_cost = 0.0005"
"cpu_operator_cost = 0.00025"

и ты не рассказал как у тебя ведет себя rphost

объем потребляемого озу rphost в пределах 60-90Мб и явно зависит от нагруженности базы

сделал
выкинуло через 5 минут после начала эксперимента но не все сессии а одну чего небыло ранее

(57) Слабовато, тогда сделай так еще
Открой менеджер "Cерверы 1С Предприятия", зайди в раздел "Процессы" удали там процес, далее зайди в свойсва ветки 1541 и поставь там пташку "Много процессов" далее опять вернись в раздел "Процессы" и добавь шт 3-4 процесса это даст многопоточность и кэширование сервера приложений

нет всеравно через время всех повыкидывало

(58) Выкинуло? ошибка была какая нить? попробуй пост (59)

(59) галку поставил и удалил, а вот добавить не могу

(61) ошибка из сабжа

(62) Зади в раздел "Рабочие сервера" там есть что нить? если нет добавь

(64) Там же и процессы добавь

(62) а начел как

(63) А что имено за ошибка? скинь лог ошибки...

сама ошибка и примеры лога приведены выше в ветке

конфа большая? могу попробовать на своем сервере

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

Теперь выдало вот это:

Runtime Error!
Program: C:\Program files\1c81\bin\1cv8.exe
This application has requested the Runtime to terminate it in an unusuak way....

и похоже что это уже приговор :(

в других сессиях ошибка из сабжа всеравно проявляется

(70) Вау! походу или у вас железо глючит или ось глюкавит

(69) в наличии постгре 8.3 под линукс и вин 2003

(71) Если проявляется это ошибка это значить нехватет ресурсов ! тоесть в конфиге описано что можно юзать столько то а когда пост пытается задействовать это он не получает все это добро, я бы на твоем месте перенес базу постгрее отдельно работающую машину чтобы он мог спокойно там работать

(73) сейчас вышлю

(75) ээээ, стой! база большая?

(76)выслал 1cv8.dt около 6 метров

может (nolock) поставить?

(77)вернулось account is full (quota exceeded)

(77) Высылай и ме тоже и скажи че в ней запустить чтобы было как у тебя

(78) расшифруйте пожалуйсто

(78) Это ваще то из MSSQL а постгре версионик у него все это подругому работает и блокировки задает 1с

(79) попробуй asp6666<>yandex.ru

выслал

получил. пароли мог бы и снять :)

я выслал в дагонку пароль

под юзером зашел :)

легкий пароль :)

(86) Опиши что нужно сделать чтобы с сымитировать твою работу?

аfтар, ты где? аськи у меня нет, отмылил. Пока могу сказать, что база летает.

(90) Такой объем, че бы не летать то :)

(91) все документы провел за 6 минут :) все отчеты строятся без проблем пока

ну ладно, я пока отойду в гараж, мне еще мост передний собрать нужно. вернусь через 2 часа :)

перепроведение доков по циклу в  2-3 сессии с задержкой на 2-3сек+ еще одна
сессия для тырканья по базе и формирования отчетов. Из базы выкидывать начало
не сразу гдето через сутки после начала экспериментов до этого тоже всё
"летало" и радовало, а потом начались проблеммы с сабжем сейчас обычно в
течении 10-15 минут работы в указанном режиме

(94) Часов 6 уже перепроводятся доки в цикле постоянном ни одной ошибки досихпор небыло

Продолжаем разговор:
Удалил базу в постгрии, затем восстановил из архива
запустил аж 4 сессии перепроведения вылетов пока не наблюдаю уже целых полчаса!
Но в 5й сессии в которой я в ручную выборочно провожу доки и формирую отчет, вы будете смеятся, я опять получил новую ошибку:

Ошибка СУБД:
ERROR: value too long for type mvachar(100)

вот лог:

2008-09-26 09:44:25 MSD ERROR:  value too long for type mvarchar(100)
2008-09-26 09:44:25 MSD STATEMENT:  UPDATE _Reference8
   SET
   _Marked = FALSE,
   _IsMetadata = FALSE,
   _OwnerIDRRef = '\\210\\327\\000\\030\\347\\011$\\011\\021\\335\\210\\243\\207\\261\\376['::bytea,
   _Code = CAST('b0042602'::mvarchar AS MCHAR(8)),
   _Description = 'Капуста Р вЂ?елокочанная Р РѕСЃСЃРС'::mvarchar,
   _Fld413RRef = '\\210\\327\\000\\030\\347\\011$\\011\\021\\335\\211\\\\\\206\\374\\247\\347'::bytea,
   _Fld37RRef = '\\210\\327\\000\\030\\347\\011$\\011\\021\\335\\211\\\\\\206\\374\\247\\347'::bytea,
   _Fld289RRef = '\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000'::bytea,
   _Fld38 = CAST(1 AS NUMERIC(10,2)),
   _Fld89 = CAST(0 AS NUMERIC(10,2)),
   _Fld90 = CAST(0 AS NUMERIC(10,0)),
   _Fld34RRef = '\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000'::bytea,
   _Fld31RRef = '\\210\\327\\000\\030\\347\\011$\\011\\021\\335\\211A\\316\\314\\352\\012'::bytea,
   _Fld1458RRef = '\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000'::bytea,
   _Fld414RRef = '\\235\\002\\000\\340}\\302\\314\\015\\021\\335+\\263?px\\214'::bytea,
   _Fld2403RRef = '\\235\\002\\000\\340}\\302\\314\\015\\021\\335+\\263?px\\214'::bytea,
   _Fld288 = CAST(''::mvarchar AS MVARCHAR(20)),
   _Fld35RRef = '\\216\\347PPTP00\\021\\332\\236\\007\\241\\237\\3062'::bytea,
   _Fld2404 = '   '::mvarchar,
   _Version = _Version + 1
   WHERE
   _Reference8._IDRRef = '\\210\\327\\000\\030\\347\\011$\\011\\021\\335\\211\\\\\\206\\374\\247\\346'::bytea AND BINROWVER(_Reference8._Version) = '\\000\\000\\000\\000\\000\\000\\000\\010'::bytea
2008-09-26 09:44:25 MSD NOTICE:  there is no transaction in progress

Вот уже почти 12 часов висит 4 потока перепроведения, плюс периодически проверяю отчет ошибок нету, при этом еще на этом же сервере работают рабочие базы ....

+ еще одна сессия вылетела с такой же ошибкой
в базе полетела нумерация у некоторых документов
вот такие номера имеем:
bР Р”
bР Р”00010
bР Р”00011


ужос

может моя сборка postgreSQL 8.3.3-2.1С какая то неправильная? или сама платформа 1С 8.1.12.98 с ним некорретно работает?

(99) Уже есть платформа 8.1.12.101 только седня скачал вроде ошибка критичная с регистрами накопления

Для чистоты эксперимента сейчас поставлю всё на другой сервант

(101) Я тебе уже грил отдели котлеты от яиц тоесть пост отдельно сервер приложения отдельно

не у всех есть в наличие такое количество свободных мощных серверов

Поменяй платформу на тестовую 8.1.12.101, у меня база на MS SQL2000, после перехода на 98 платформу сервер 1С стал выбрасывать пользователей, писал проблемы с сетью. Заметили просто прикольную штуку, в базе вечером осталось 5 человек, а проц на скуле занят почти на 100%, при этом счетчик очереди страниц щелкает до 150 и выше, выгнали из базы всех пользователей, ан нифига, картинка на скуле такая же. Перегрузили сервер 1С, все прекратилось. Вчера перепрыгнули на 101 релиз, все прекратилось. Пользователи перестали вылетать... или скажем так вылетают предсказуемо и объяснимо...

(103) Тебе мощность щас не должна волновать, а больше стабильность работы базы

(101) поставил на отдельный серевер платформу 1С и сервер приложения, на исходном сервере все сессии 1С вырублены сервер приложения также в дауне, работает только постгри.

На отдельно сервере запустил тот же эксперимент через 30 минут вывалило:

Ошибка СУБД:
ERROR: value too long for type mvachar(100)

:(

(106) Перенеси постгре тоже

(104) она уже не тестовая - 101 релиз стала официальным.

Поставил на отдельный сервер постгри тудаже свежую платформу 101, все работает
стабильно в течении 4 часов, но один выкидыш всё таки был:

2008-09-26 16:14:04 MSD ERROR:  relation "tmpind1" already exists
2008-09-26 16:14:04 MSD STATEMENT:  CREATE INDEX TmpInd1 ON tt8 (
   _RecorderTRef,
   _RecorderRRef,
   _LineNo,
   _Correspond,
   _KindRRef)
2008-09-26 16:14:04 MSD NOTICE:  there is no transaction in progress
Продолжаю тестирвание

(109) Ну вот видишь все оказалось не так сложно, разбирайся со старым сервером и виндой ....

После 2х суток тестирования вывод: всеравно валится 1с да с другой ошибкой и регулярностью но ВСЕ сессии по очереди.

Вот лог:

2008-09-28 17:57:55 MSD ERROR:  cache lookup failed for relation 805065
2008-09-28 17:57:55 MSD STATEMENT:  SELECT 1::INT8 FROM PG_CLASS WHERE pg_catalog.pg_table_is_visible(OID) AND RELKIND='i' AND RELNAME='tmpind1' LIMIT 1
2008-09-28 17:57:55 MSD NOTICE:  there is no transaction in progress
2008-09-28 17:57:57 MSD ERROR:  relation "tmpind1" already exists
2008-09-28 17:57:57 MSD STATEMENT:  CREATE INDEX TmpInd1 ON tt8 (
   _RecorderTRef,
   _RecorderRRef,
   _LineNo,
   _Correspond,
   _KindRRef)

(111) Посмотри в логах 1с и в логах посгре что то типа "existing connection closed" надпись не дословно но ищи если ли обрывы связи между сервером поста и сервером 1с

(112) не нашел такого нигде в логах. Да и причем тут проблемма со связью если
всё крутится на одном сервере?

У меня ошибка пока не воспроизводится, однако вызывает настороженность факт записей в логах

2008-09-29 09:51:34 MSD NOTICE:  CREATE TABLE will create implicit sequence "tt440_f_1_seq" for serial column "tt440.f_1"
2008-09-29 09:51:37 MSD NOTICE:  CREATE TABLE will create implicit sequence "tt451_f_1_seq" for serial column "tt451.f_1"
2008-09-29 09:51:37 MSD NOTICE:  CREATE TABLE will create implicit sequence "tt466_f_1_seq" for serial column "tt466.f_1"
2008-09-29 09:51:42 MSD NOTICE:  CREATE TABLE will create implicit sequence "tt485_f_1_seq" for serial column "tt485.f_1"
2008-09-29 09:51:50 MSD NOTICE:  CREATE TABLE will create implicit sequence "tt504_f_1_seq" for serial column "tt504.f_1"

плюс, в БД дополнительно к схеме public появилась еще схема pg_temp в которой количество таблиц и последовательностей (sequence) непрерывно увеличивается.

На мой взгляд это может вызвать негативные последствия в дальнейшем, например, как в (17)

(114) это тоже имеет место быть непонятно только как с этим боротся

(115) временная схема создается только на время проведения, а эти записи появляются только на "косячных" документах, которые не проводятся. Вы там все перепроводите или только проведенные? а проведние на время останавливали, или двое суток без перерыва?

(116) только проведенные. Проведение останавливалось только на время вылетов как только замечал перезапускал сессии по новой. Вылеты повторяются вновь и вновь, да существенно реже  (гдето 2-3 раза в сутки) чем на предыдущем сервере но это крутится с дефолтными настройками от 1с но всеравно это неприемлемо

еще такое в логах вижу:

2008-09-29 09:10:50 MSD WARNING:  corrupted pgstat.stat file

(114) and (118) Везет вам на ошибках :)
Вы базы все тестируете на виде?
У мя на лине таких ошибок ваще нету

Для меня установка линукс сервера является просто невозможной. Если постгри не работает стабильно на винде значит в топку слонов. Хотя люди на SQL.RU пишут что смена оси роли не играет вот цитата:

"Судя по описанной ситуации когда не хватает памяти для блокировок и растет количество процессов это похоже на фирменную особенность 1С. Грубо говоря прога делает кучу запросов которые требуют AccessExclusiveLock ( т.е. "я один ларису ивановну хочу, остальные в очередь") естественно образуется очередь из запросов которая может расти если какой-либо из таких запросов требует значительного времени на исполнение.

Вам я думаю надо сначала четко понять что происходит с точки зрения базы, а потом подергать специалистов по 1С когда у вас на руках будет больше данных. Перевод базы на линукс,солярис,*бсд,етц тут я думаю поможет мало"

(119) на винде и на линуксе тоже

(120) Слон изначально на Linux и для Linux разрабатывался. Под винду существует только ПОРТ. А что такое ПОРТ, каждый серьезный разработчик знает. Выпечка порта зачастую не такой тщательный процесс, как вылизывание софта на родной среде.
.
Раз решил топку, так в топку, бери MS SQL, раз нет возможности поднять Linux-server.
Слон будет пахать на винде так-же как и 1С на Linux.

(119) как получить. Операции -> Проведение документов, там отмечаем док. Ввод остатков, период не ограничивать, делать по проведенным и непроведенным. В результате в логе (114)

(123) да, и схема очистилась только после выхода из 1С-предприятие, м.б. это тоже может сказаться

судя по всему автор, английский тебе учить надо срочно.

(125) если есть что сказать посуществу то милости просим, а если нет,
то не говорите мне что мне делать и я вам не скажу куда вам идти

(126) Ты бы меньше трендел, больше бы думал. Я сейчас как раз по твоему вопросу гуглю, так как слон меня очень интересует.

(120) Попробуй еще врубить логирования сервера 1с инструкция тут http://webfile.ru/2268254 может че нить отловиш

(123) Такая операция создает в логе только 1 строку
2008-09-29 19:59:48.109 VLAST,"postgres","post",3632,"192.168.6.17:26667",48e098f4.e30,2,"CREATE TABLE",2008-09-29 19:59:32 VLAST,4/19760,1191204,NOTICE,00000,"CREATE TABLE will create implicit sequence ""tt14_f_1_seq"" for serial column ""tt14.f_1""",,,,,,,,

И все ....

(129) да, все верно - только одну строку. Но в базе таких плохих документов не один, так что временная схема распухает прилично.

Да, базу смотрю через EMS SQL Manager for PostgreSQL, в онлайне мониторю и вижу что количество таблиц во временной схеме растет _очень_ быстро.

(128) Пробую, но тяжеловат это журнал, за полчаса 600 метров логов намотал

Ну вот, запустил проведение в типовой УПП, ситуация совершенно обратная - сообщениями из (114) не сыплет, всего три позиции за месяц проведения и временная схема не распухает - всего 64 таблицы за такой же период. В базе от (0) было уже несколько тысяч таблиц.

снес всё на старом сервере перставил postgre настрройки поумолчанию,обновил платформу на 101 теперь ситуация 1к1 как на втором сервере т.е. out of shared memomory ушло, но блин также вываливает как в (111). Тестирование длится сутки.

Вывод: Одназначно можно отсекти версию проблеммы с железом и/или проблемм с осью.

Склоняюсь к тому что проблемма с платформой и/или настройками постгри. Не исключаю что кривая конфа, но считаю какой бы кривой она небыла бы она не должна в теории вызывать ошибки СУБД.

(132)
pg_temp не смог смоделировать но аналигичные записи в логах у меня тоже прут. Доки я перепровожу своей обработкой перепроведения: сервис-адимнистративные-перепроведение (только проведенные)