v7: Проблема с 1с 7.7.+ w2k3 terminal #693621

Доброго времени всем и с наступающим/наступившим Новым годом. Прошу помощи. 1с 7.70.0.27-сетевая работает в конфигурации РарусАльфа 3.09 Автозапчасти+автошины ( размер базы порядка 2.3 гига.)на Windows Server 2003sp2 64 bit терминале (работают от 6-14 пользователей). Проблема вот в чем. Около 3-х недель назад началось падение 1с при подготовке отчетов. Падение наблюдается при любых периодах и любых отчетах. Выглядит так: на клиенте: или белый экран или просто зависание на енной строке подготовки или вывода данных. в это время на сервере (если белый экран) память которую занимал процесс падает от десятков Мб до порядка 1 мб и полная загрузка ядра процессора; если зависание при выборе или выводе данных то полная загрузка ядра при этом видно что процесс перестал использовать память но объем под процессом остается тот же. До этого в течении нескольких лет проблем небыло. что сделано мной: Проверено сервер на наличие заразы. Проверено Рейд на наличие ошибок диска. Отключен-удален антивирус. а также установлена внешняя компонента TerminalSleep. собственно теряюсь в догадках Прошу помощи. Заранее спасибо.

Доброго времени всем и с наступающим/наступившим Новым годом. Прошу помощи. 1с 7.70.0.27-сетевая работает в конфигурации РарусАльфа 3.09 Автозапчасти+автошины ( размер базы порядка 2.3 гига.)на Windows Server 2003sp2 64 bit терминале (работают от 6-14 пользователей). Проблема вот в чем. Около 3-х недель назад началось падение 1с при подготовке отчетов. Падение наблюдается при любых периодах и любых отчетах. Выглядит так: на клиенте: или белый экран или просто зависание на енной строке подготовки или вывода данных. в это время на сервере (если белый экран) память которую занимал процесс падает от десятков Мб до порядка 1 мб и полная загрузка ядра процессора; если зависание при выборе или выводе данных то полная загрузка ядра при этом видно что процесс перестал использовать память но объем под процессом остается тот же. До этого в течении нескольких лет проблем небыло. что сделано мной: Проверено сервер на наличие заразы. Проверено Рейд на наличие ошибок диска. Отключен-удален антивирус. а также установлена внешняя компонента TerminalSleep. собственно теряюсь в догадках Прошу помощи. Заранее спасибо.

Что-то поломалось наверно...

Например файлик вылез за допустимый размер...

не совсем понял начет файла...можно подробние

размер самого большого файла в базе озвуч

Просматриваешь размеры файлов БД. Если видищь файл больше 1Gb, начинаешь думать...

а понятно...самый большой порядка 540 мб

этот вариант проверял...но был исключен

всякие переиндексации делал?

стандартную и удалял cdx файлы...проблему не решило

с бубном танцани: выгрузи-загрузи данные. Но сперва бэкап.

да интересный момент...1с может свормировать 2-3 раза отчет на 4 вылететь...а может с первого

и у усеров каталоги почистить не помешает

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

а не память ли какой отчет откусывает, посмотри что в процессах висит

Каталоги пользователей чистились...принтера работают через ScrewDrivers проблем небыло...хотя попробую вечером отключить их...нет в памяти 1с как процес максимум 60-80 мб

Тестирование и исправление запущу на копии вечером когда все отключатся

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

По моим наблюдениям 1с падает при работе пользователей...собствено подозревал проблему с блокировкой таблиц....

*.mlg файл какого размера?

mlg порядка 240 мб

Я бы обрезал на всякий. Но мне кажется проблема в таблица физически или логически повреждены.

я бы согласился...но повторюсь...делает отчет за один и тот же период 2-3 раза все ок...на 4 может вылететь...а может и с первого...если бы таблица была повреждена ...то б не одного небыло

в печатаемых таблицах - нет расшифровок с большими данными?

Да нет ...там все расшифровки в основном на документ или на номенклатуру. Конфигурация работает уже более 5 лет раньше проблем не было

откатись на месяц назад в бэкап системы

Чистить TEMP ещё никто не предлагал ? Или вообще, запускать 1С с ключом /t указывая альтернативную TEMP-директорию.

откат системы как крайний вариант... темпы все перечищены были в самом начале...профили прользователей скинуты на дефалтные...

попробую с альтернативным темпом

Отключение TerminalSleep никак не влияет на зависания? Если что посмотрите похожую dll, я выкладывал ту версию, которая стоит на нашем сервере несколько лет.

to romix...я подключал TerminalSleep поскольку думал что проблема в блокировке таблиц...но как показал день работы не помогло...брал как раз с указаного сайта..

А если переустановить 1С? И поставить в разворот через 64-битный инсталлятор

А на копии в монопольном режиме не пробовали?

ТИИ нормально проходит?

1) Посмотрите журналы системы. 2) Прогоните "стресс" тест железа. Подозрение на железо...

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

В журнале системы (Windows) имеет смысл посмотреть, что было ДО "зависаний" проблемных сессий. Тестировать (нагружать), думаю, надо прежде всего CPU+RAM.

на даный момент ситуация такая...1с не зависла при ТиИ ...а задумалась...есть проблема в регистры но корень ее тянется в 2005 год ... и проходит она по архивам с 2009 года...те что у меня есть доступны...по этому пока ищу еще возможные причины... Журнал чист...кроме отключения клиентов по впн инородных событий нет....

еще раз просмотрел таблицу на которую ругается ТиИ как вот с этим база могла работать и индексироваться...никак в голову не влазит

Индексироваться - легко. А работать не всегда - как попадет (потребуется алгоритму) условие поиска по индексу.

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

а чем может быть дело , 1с 7.7 DBF грузится база по 2-3 минуты, жутко тормозит, но в терминале все летает. Тестирую скорость загрузки файлов на сервер -> 30мБит загрузка сети , показывает  по диспетчеру задач. Сеть 100мБитная. Кидал сетевой провод прямо с компа на сервак - тоже самое, тормоз. W2008R2 и компы с W7 XP , разные. Все так же тормозят.

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

Касательно вот этой ситуации...скажите свое мнение...может ли она влиять на работу...после ТиИ эта жуть остается в базе...в свое время я такое встречал в фоксовых dbf..появлялось как правило в конце таблици..обычно после того когда пропадал свет а в этот момент велась запись на диск...но  там индексация не проходила ...а сам фокс орал что повреждена таблица...лечил c помощью cdbf...собственно вопрос в чем...с тем что база 1с проходит индексацию и вот эта жуть остается в базе...возможен вариант что система берет этот код при выборке...и на нем умирает???

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

"возможен вариант что система берет этот код при выборке...и на нем умирает???"(с) Да. Но, возможно, ОНА его не может даже "взять", т.к. этот мусор и в индексах. Сделайте реиндексацию этой таблицы, и посмотрите её средствами просмотра DBF-ов с использованием индексов. Или дайте посмотреть другим людям. ;-)

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

Да. Т.к., например, порядок поступления записей при "движении" по этому индексу не соответствует операторам сравнения полей таблицы в оперативной памяти. Аналогичная проблема возникает при использовании DBF-ной базы под управлением Win7 когда в полях таблицы находятся "запредельные" символы.

а почему не соответсвует..? что-то я не втыкаю..

В индексах информации лежит в кодах "преобразованных" по специальной таблице, которая не полностью соответствует системной кодировке. Т.е. некие символы в индексах дают сравнение на больше/меньше отличное от сравнения операторами 1С-а. Ну, и совсем "весело", когда в поле таблицы влетает 0х00.

Индексы бывают разные - всё зависит от типа индекса и от преобразования значения, выполняемого перед индексированием. Для строк, 1С выполняет UpperCase(LeftChar(Value,128)), то есть в случае каши с большой вероятностью получится пустая строка, которая прекрасно индексируется, но будет нарушена уникальность (которая, насколько я помню, на низком уровне не отслеживается). В итоге, индексация прекрасно пройдёт, только вот результат поиска по идентификатору будет местами достаточно странный. Смертельно то, что "кривые" значения идентификатора будут преобразовываться в число функцией, которая не сильно проверяет их правильность - то есть из каши будут получаться числа, которые обратно в кашу не преобразуются. Но, ТИИ каши должно проходить с ошибками, так как там проверяется и логическая целостность и допустимые символы в строках (например, символ с кодом 1 в строке не разрешён).

Всё верно. Но, маленькое дополнение. 1) ТиИ не выявит для строковых полей символы типа 0x01. 2) Пустая строка в индексе не появится, даже если в поле БД будет символ 0х00. Т.к. при использовании полей в индексном выражении используется длина поля, а не завершающий байт нулевого значения. Например, значение поля "1234"+0х00+"6789" так и будет выглядеть в индексе с нулем между 4 и 6. Но, при взятии значения поля из самого DBF-а будет значение "1234". Т.е. полная "каша" и "странности" гарантированы... :-(

от ты побач Мыкола що навыдумляли о цы кляты москали...

Символ 0x01 в некоторых строках ТИИ на этапе логической целостности видит (но в ID - точно нет). Дальше, если строка в индекс идёт без преобразований, то символ с кодом 0x00 в середине никак не повлияет на результат индекса - просто он не будет работать в 1С (где строка заканчивается нулём). Если же строка подвергается преобразованию какой-то функцией (например UpperCase), то всё зависит от реализации самой функции. И, самое печальное, что функции сравнения и поиска работают по-разному в 1С, в движке dbf-драйвера и на низком уровне внутри драйвера.

В общем так: 1С.Предприятие 7.7 (версия 7.70.027) Новая база, справочник: Обработка для записи кодов: Выполняем ТИИ: Файл SC12.dbf. Запись 2. Поле DESCR. Неверное содержимое текстового поля - "ВасяПупкин              " Файл SC12.dbf. Запись 2. Поле SP14. Неверное содержимое текстового поля - "Строка   " Как бы система говорит, что ей не понравились символы 0x01 и 0x05 в наименовании и обычной строке (не входящей даже в индекс).

Да. Согласен. Моя оплошность. Делал ТиИ в своей "примочке" в режиме эмуляции "родных" DBF. А в ней отключена "Проверка физической целостности". Уже забыл про это... :-(

Просто, есть подозрение, что в тоже какие-то примочки стояли. P.S. у меня в первой моей программе, где числа хранились в упакованном виде (0x01-0x7E) первое ТИИ выдало просто дофига сообщений, после чего я понял, что 1С это не VbScript и быстро и хорошо не получается.

я смотрю на дбф примерно так как описано здесь: возможно в 1с оно чуток подругому...но основной принцип...думаю сохраняется...так вот...в моем понимании это выглядит так... есть заголовок который опысывает таблицу...  и если в каком то поле находися не тот тип даных...то система как бы не должна это индексировать их...в лучьшем случае ...орать что мол нарушена структура...судя повсему она эти записи пропускает при индексации... каши удалось избавится после перепаковки таблиц в ТиИ. Рузультатом стало что в отчет не попадает часть даных....скорее всего ТиИ зацепило еще какие то даные... нужно пробовать перепровидение... что волнует ...как это все отразится на регистре склада...

Что значит примочок...если они там есть то от раруса...в остальном чистый код ...немного изменены формы ...документов ...но с этим все работало чудесно...

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

Рарус никаких примочек для работы с dbf не использует - есть часть закрытого кода для поддержания системы защиты и сокрытия каких-то алгоритмов, но она уже намного выше системы хранения данных. Но, некоторые конфы раруса используют сторонние файлы для взаимоблокировок, что может сказаться на правильности функционирования системы.

не ссы! 1. на оригинальной базе сними кртичные остатки по складу. 2. поправь базу, перепроведи нафиг все в нормальных условиях. сделай все регламенты какие надо. 3. посмотри остатки по складу по сравнгению с п.1 - ничего разъехатьяс не должно. Если разъехалось - невязку откинь в виртуальный карман до разборок.

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

кто хочет посмотреть вот ссылка

смотреть в районе 35200 записи

Если смотреть эту таблицу с использованием любых индексов (кроме "служебного" IDELETED), то "мусор" располагается в начале и конце таблицы. Т.е. такое расположение "битой" информации может влиять негативно на отчеты и обновление БД в любых интервалах. А не только при обращении к информации за 2005 год, где наблюдается собственно порча DBF файла. Вопрос, как это всё успешно работало с 2005 года... Возможно есть еще другие "битые" таблицы. Или наблюдаемая "битость" изменилась в худшую сторону уже в настоящее время. Думаю, полезно будет глянуть на этот DBF из старой копии. Как вы говорите - "проходит она по архивам с 2009 года"(с). Их и надо посмотреть. Прикрепляйте ссылку в тему. Бум смотреть... :-)

Кстати. ;-) 1) Эти записи не исчезают при реиндексации. 2) В результате упаковки удаляется всего две записи, т.к. "битость" попала у них на признак (пометку) удаленности. А общее количество "битых" записей пара десятков. Это то, что видно глазами.

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

по совету сделал выгрузку и загрузку даных...каша исчезла...проверяю остатки по отчетам...посмотрим как будет работать...ТиИ не проводил

Сделал бы сразу это - не было бы 60 постов мозгового штурма в новогодние ночи ))))

В обоих файлах "битость" одинакова. Т.е., если это и есть ПРЯМАЯ причина "зависания" сессий с отчетами, то это должно было произойти в 2005 году. :-) P.S. Рекомендую посмотреть размер этой таблицы и количество записей после выгрузки/загрузки. И сравнить с исходной. Возможно, что выгрузка произошла только до "битости". Т.к. во время выгрузки тип полей и их содержание проверяется на соответствие. И, возможно, "битость" не пропускается, а алгоритм выгрузки молча ;-) завершается. Это как я ЭТО понимаю. Могу и ошибаться...

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

отчеты с рабочей и загруженой базы по остаткам плюс отчет по оборотам за последний год сошлись

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

Дык. ;-) Зависание можно моделировать в однопользовательской среде? Тогда высылайте мне базу с подробным описание задачи-зависания. У меня есть возможность включить трассировку всех обращений к БД. Думаю, проблему можно будет локализовать...

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

делай как ходжик в описал - получишь гарантированный ответ.

какое на формирование "табличной части" - формирование самой таблицы отчета? - если виснет на этом - ну или алгоритм кривой либо проблемы вне 1С...

база на eurotron-овском ключе...втыкнут в лпт порт...дампа ключа нет...если отключив компоненту защиты еще можно запустить саму 1с то все функции становятся не робочими...

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

Если " Около 3-х недель назад началось падение 1с", возьми архив месячной давности и посмотри в копии. А лучше локально. Во всяком случае можешь исключить либо 1С, либо работу терминала.

собственно этим сейчас и занимаюсь

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

ждем вестей

TEMP-директории пользователей чистили ? И куда указывает переменная TEMP в сеансе пользователя ? Ну и диски неплохо бы посмотреть на ошибки, а то была у меня "хорошая" машина, которая почему-то тормозила - потом пришла идея - SMART-диагностику сделать - было много ошибок поиска сектора (причём именно поиска, а чтение и запись почему-то шли на ура).

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

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

Вот тут (сообщения 95, 166) есть смешной тест. Если Вы его запустите для 5-10 сессий, то это сильно нагрузит железо "особенностями" 1С. Пропустите его на реальном сервере. Естественно, без пунктов 8, 9, 10. Т.е. проверяем только  исправность/надежность железа.

попробую ближе к 20:00 по киеву

Смарт ключа работает криво - как только обращение в ту область данных, неважно, нужна или нет - получаешь косяк. Я такое ловил даже с рабочим ключом. Ну а папуковские поделки вообще притча..

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

походу вылезла закономерность...выгледит так: например делаю отчет по продажам за произвольный период... выборка делается мгновенно ...табличная часть формируется мгновенно...отчет выводится нормально повторяю этот же отчет ...выборка делается медленее ...и вывод самой табличной части медлено...но отчет открывает... третий раз...еще медленее...но открывает как правило на 4 раз ...зависает странно...может у кого есть варианты

Есть варианты. ;-) Перегрев CPU. :-( Вы стресс тест то сделайте...

если межуд 3-им и четвертым быстро перезапустить 1сину - что будет..?

работает...еще два три отчета можно сделать

перечитал материал по ссылке ...сейчас нет возможности запустить ваш тест в полном объеме...перед созданием темы...запускал стрес тест системы средствами евереста (проц, память, жесткий диск) тестировался  4 часа...темп процесора не поднялась выше 45градусов

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

по 1 вопросу: ну как при перезапуске...сначала все ок... а на 3-4 отчете зависает. выглядит так...полностью загруженое ядро...память или остается занятой или освобождается....обращение к диску прекращается