Ошибка захвата таблиц 1SJOURN ..... :0( #30972

Есть ИТРП 2001, НТ4ТСЕ, Citrix. Сервак 2х733, RAID-0, Сетка 100 Mb.При работе более 7 человек постоянно вылетает, ошибка захвата таблиц 1SJOURN.Что это файл журналов ясно. Сетка работает нормально , недавно проверялясь.Что еще может быть или как побороть энтот глюк?

Есть такое. А какое ПО сервера?

НТ4ТСЕ меняй на W2Server

Угу, причем с использованием Active Directory

Версия операционки не причем, однозначно...

Система достигла предела и пользователи стали мешать друг другу создавать новые документы. Если уменьшение продолжительности транзакций не поможет то все.

На проведение документа сейчас уходит порядка 8-10 сек, хотя недавно было ~25-40 сек, это я именю ввиду что они проводяться в основном задним числом.По статистике в день набивается около 240 документов.

Узкое место, и какой выход?

Да, Олег, я тоже так считаю - прав, так что придется вылизывать модули документов ...

2Там ужо вылезано, что можно было.Дало скорость проведения 2-4 раза но проблемы не сняло. :0(

увеличить период опроса изменений БД и время ожидания захвата таблиц в меню Сервис - Параметры на каждой машине

Технически возможно прикрутить систему хранения пустых документов. В регламентное время запускается процедура которая плодит пустые документы в прошлом периоде и записывает их. А при создании документа он реально выбирается из уже записанных. В этом случае (_)1SJOURN не будет блокироваться. Будет блокироваться (_)1SSYSTEM при проведении на та.

Из-за того, что операционка не спешила освобождать файловые хендлы (та же самая ошибка, возможно другая таблица), пришлось сменить ее на другую. Дело было в сырой версии samba под linux--

Ну если ты в сети уверен на 100% - тогда не знаю ... SP на сервере какой ? ежели 6, то можно попробывать откатиться на 5, но imho это уже шаманство, хотя иногда и помагает ...

2SP 5.На счет секти на 100%, я конечно не уверен ,но на 90 % - уверенЗагруженность сети 5-10 %.Битые пакеты есть, но их мало 30-50 на 1000000 нормальных

W2Server + SQL2k

2 а релиз ты какой рекомендуешь?2 Время ожидания повысь однозначно . и эта ... винты нужны быстрые, если процессоров хватает.

2Время ожидания стоит уже 120 сек.Это не выход из положения. Можно конечно поставить и 600. Не будет появляться это окно и все, а доки проводиться сколько будут.Нажал и пошел курить. Зачем нужен тогда терминальный режим, мощные сервера и т.д.

Может быть поможет SQL (если база DBF)... Какие винты крутятся???

Винтов 2 (Quantum 18 Gb) на RAID0. Винты не тормозят(судя по анализу)А на счет SQL, я не уверен ,что он поможет в данном случае. Тем более что скорей всего конфа сразу не будет устойчиво работать после перехода.И на сколько я знаю проведение доков в SQL немного дольше, чем в ДБФ, а база у меня пока еще не очень большая (~300Mb).

2 Винты судя по всему ИДЕ-шные... SQL тебе поможет - это точно, вот конфа стабильно сразу работать будет вряд ли. Про проведение не беспокойся - не настолько долго... Либо тормоза на дисковых операциях, либо возможно у тебя битые индексы, а может просто очень большой 1СЖурнал... В любом случае проверь индексацию...

Думаю, что проблема не с винтами. У меня IBM SCSI, но имею то же самое. :о(

2Винты SCSI.Файл журнала 3.6 Мб, его индекс 4.2Мб

to : согласен - этот параметр влияет только на задержку перед выводом subj'ового сообщения ... а вот другой - "Период опроса изменений БД" (или как там его, сейчас не помню точно) - у тебя какое значение стоит (у меня 30с) ...

2 У меня тоже 30 сек.

2: Для файловой 1С это предел :-( Ставь сиквел и переписывай модули проведения на T-SQL. Если больше 10 операторов, то время проведения не должно превышать 2-3 секунд

Я сам не против SQL, но это черевато покупкой сервера, а руководству надо доходчиво ДОКАЗАТЬ, что это действительно надо и без этого не обойтись.У меня сомнения на счет того, скорей всего 100 Мб сетки между SQL и TSE серверами будет маловато

То Никакого предела нет...Аналогичная (почти) система, камни только 866 да РАИД-511 пользователей в сети под терминалом - никаких ошибок захвата. Исчезли после перехода с 1хП2-450...

2: Значит конфа по-проще или документов меньше. 240 в день это уже прилично...

2: Одним сиквелом здесь не обойтись: нужно будет модули переписывать.

To Вот Базопузомером посчитал...В среднем за день 245.4 документов, 2859 усл. строк.Что и подтверждает, что проблемы, скорее всего, в конфе, а не в операционке / софте / железе.