v7: Блокировка журнала регистраций #562677

Доброго всем дня! 1С 7.7 Торговля (далеко не типовая), SQL,УРБД.  Интересная проблема нарисовалась у нас. База иногда повисает. Грешим на то, что блокируется журнал регистрации, т.к. в момент затупа не появляется ни одной записи в нем и при просмотре его в мониторе жуткие тормоза. Причем и сам сервер начинает нагружаться с чего-то. При выкидовании какого-нибудь пользователя (каждый раз разного) все начинает работать. Вычислить условия, при которых это возникает, не получается, воспроизвести тоже. Может кто-нибудь сталкивался?

размер шурнала?

72 метра

в целом не тормозит, а только в некоторые (непонятные) моменты времени

С чего вы взяли что проблема с журналом. 72 метра это ниочем.

документы не открываются даже на просмотр, просто повисает, и не добавляется запись в журнал

если есть варианты кроме журнала регистраций, то изложите

Сжать журнал? В режиме монитора меню Монитор - Архивирование журнала.

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

хотя это имхо от сервера зависит, это по сути текстовый файл, на слабом сервере и на 70мгб может заткнуться.

Однажды в журнал попала (внезапно!) какая-то строчка неправильная и при просмотре старого периода требовала пароль. Вычислил тупым подбором, с какой даты глючит, открыл в блокноте и убил ту строчку. Всё заработало. Причину пока не знаю.

, а че это за единица такая "мгб"? Интуитивно я догадываюсь, но хотелось бы уточнить (С) КВН

+11 В Убунте. например, пишут МиБ. Мега и Байт, наверное...

Межгалактический Глобальный Баунти

наверное попробуем вариант с удалением журнала регистраций

больше мылсей нет

Предположу, что у вас где нибудь в обработке ожидания висит процедура чтения этого журнала на предмет чего либо. При попытке открыть файло - вылет.

Пробуйте удалить, пробуйте и сжать.

"и при просмотре его в мониторе жуткие тормоза" - это как раз нормально, это ж, благодаря разрабам, тупо обычный текстовый файл. но вряд ли он причина торомозов что происходит во время т.н. "зависаний"? хоть кто-то из юзеров работать может? или у всех одновременно белый экран? скуль какой? может, в это время тупо автообмен с РБД происходит?

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

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

скуль 2000-ный. Происходит в этот момент все что и в другие моменты, т.е. ничего уникального

Антивирусник есть?

нет

может дефрагментировать его?

дефрагментировали не так давно

свободное место на диске с этим файлом есть?

места много

"Документы открываются проводятся, но очень долго. Только это не фиксируется в журнале" - ты уверен насчёт второго предложения?

в момент затупа нет

т.е. ДА, уверен

это весьма странно. прибей журнал полностью (сохранив копию), посмотри, что это даст. ещё не мешало бы проверить на регламентные процедуры/роботы (запуск из шедулера с обработкой ПриНачалеРаботыСистемы, или запуск из самой 1сины ч/з ОбработкаОжидания глобального или какого-нибудь локального контекста)

не в тему, но вдруг: а файлы 1Cv7.CFG у пользователей большие? Больше 500кБ?

Тупо удалите и не парьтесь. Можно архивную копию сделать на всякий случай если нужна история изменений.

и после затупа этих записей нет, просто записи в этот период отсутствуют

а ты на зверей систему проверял?

да не похоже, лишних процессов нет

это не показатель

врядли это вирус, при выкидывании пользователя, каждый раз разного, все становится нормально

тогда смотри в сторону ОбработкаОжидания

ладно, будем завтра пробовать удалять файл

напишу что получится

вот чё я тебе скажу - mlg одинэсиной не лочится напостоянку. т.е. сторонняя прога, либо код из самой 1Сины, могут в него писать как в обычный текстарь. естественно, в это время сама 1сина в него записать не может. это объясняет всё, и тормоза, и отсутствие части логов, а учитывая "выкидывая юзера - становится всё нормально", то остаётся только код из самой 1сины.

+ если найдёшь такой код - оторви руки тому писателю

+ возможно, в него и ничего не пишется в это время, может, он не совсем удачно открывается так на чтение

вот, может пригодиться:

сегодня снесли mlg, пока ничего не было, но затупы и не каждый день были... поглядим, чего дальше будет

Доброго всем дня. Все повторилось, но обнаружилась интересная вещь. За минуту до того, как встал журнал регистраций, два пользователя создали ПКО с интервалом в 5 секунд, НО номера одинаковые. Один из пользователей новый документ записал. Пытался ли второй пользователь записывать неясно.

Не тупило несоколько дней после того как удалили mlg

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

спасибо гляну

>ты уверен насчёт второго предложения? программные действия в клюшках не регистрируются

PAGEIOLATCH_SH 70%. Оказывается мы тут уже это смотрели

PAGEIOLATCH_SH - Имеет место, когда задача ожидает кратковременной блокировки буфера, находящегося в состоянии запроса ввода-вывода. Запрос на кратковременную блокировку производится в режиме общего доступа. Длительное время ожидания может указывать на проблемы с дисковой подсистемой. ------------------------------------- думаю понятно куда копать :)

+ короче у Вас что-то диски тормозит, например такое бывает если сервер "виртуальный"

54 он развернут с бэкапа виртуального

но дисковая подсистема хорошая

какой размер файла 1cv7evt.txt?

48 байт

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