Платформа 8.3.8.2054
Конфигурация Розница 2.2.2.20 файловая
Настроен РИБ по магазину
Дело в том что на днях похоронил базу распределенного узла из-за вируса-шифровальщика и решил восстановить начальным образом из центральной.
Образ сделать получилось (объектов оказалось больше 1 млн, базе 2 года), но когда из нового образа (1Cv8.1CD) запускаю режим предприятия - висит при запуске минут 20, не меньше, запускается и работает с тормозами что хоть вешайся. В конфигуратор заходит. Выгрузку-загрузку конфигурации (*.dt) делал. Новую (*.cf) из этой тормознутой создавал - чистая отлично работает, загружаю конфу (*.dt) и тормоза прилетели. Кеш не чистил, но менял расположение/имя. Запускал с отключенными фоновыми заданиями (/AllowExecuteScheduledJobs -Off ), регламентные все отлючены, полнотекстовый поиск отключен. Проводил тестирование и обычное и chdbfl.exe и переферии и центральной (а потом создавал образ) - ошибки были, но результат те же тормоза. Менял версию платформы.
В общем обычные средства все (или почти все) испробованы - результат 0.
Есть подозрения что какая-то из процедур при запуске зацикливается, но где? Вроде можно проверить замером производительности, но я не совсем понял как им пользоваться. На обычных обработках получалось, а с конфигурацией не пойму как он работает. Если кто знает подскажите!
Заметил что в режиме конфигуратора любой журнал, справочник, документ, регистр и т.п. открывается гораздо дольше обычного, НО! когда один раз откроешь документ-повторное его открытие быстро!и любой другой подобный уже нормально открывается. Еще при запуске в режиме предприятия неохотно используется оперативка (при запуске обычно съедает около 150-200 мб почти сразу, а тут по 0,5 мб за 5 секунд набирает) зато процессор загружает на 25% +- 2-3% стабильно пока не запустится.
Подозреваю что проблема с каким-то хранилищем, но куда копать понять пока не могу...
Сделал только что замер производительности на примере журнала Реализации товаров и услуг - все процедуры в сумме дали примерно 18-19 секунд, что в принципе близко к правде, а это значит, что все (или большинство) процедуры выполняются дольше обычного.
(8) leks88,
да.
Без опыта 1СD-Tools не запустишь, а без неё индексы не зарубить и не заставить саму 1С их восстановить.
Только выгрузкой- загрузкой в/из *.dt.
(10) leks88, попробуй пропустить через отладку, пару точек остановки на модуль перед началом работы. Нужны любый ответы. И затем в систему за списком ошибок.
Не забудь что желательно загрузить в новый каталог, 1С любит стартовать по ранее созданным временным файлам. Главное проверь настройки засыпания и спящего режима в конфе.
Сбоя не было, оригинала базы просто не существует. Эта база-это начальный образ узла РИБ и она запущена на другом компьютере, не там где был вирус.
А на какой процедуре лучше всего остановку сделать?
Сбоя не было, оригинала базы просто не существует. Эта база-это начальный образ узла РИБ и она запущена на другом компьютере, не там где был вирус.
А на какой процедуре лучше всего остановку сделать?
Хоть один работающий архив базы есть с центрального узла?
обычное или уф
(22) leks88, архив это когда на cd, на флешке.
тогда так, а на сколько у тебя эти базы на корневом и периферии различаются?
Если их можно использовать на периферии, нужно из архивной центрального сделать обычную, без настроек РИБ.
тут готовая обработка Поднять на другом компе и заново настроить риб.
(22) leks88, есть на диске systemvolumeinformation (был по крайней мере раньше). У админа прав на него нет - замени владельца контейнера на своего админа, получишь туда доступ (win 7). Я один раз после шифровальщика пытался найти хоть что-нить (бекап, копию) - нашел случайно там dt последней рабочей базы (туда у шифровальщика нет прав)... Попробуй - вдруг тебе тоже повезет
Ну, отличаются. В переферии были документы только определенного магазина/склада и информативные остатки остальных складов. Корректно сделать переферию из той центральной не получится, а если и получится то это опять же это займет время... хотя заморочиться можно. НО, все таки интересно что же такого могло произойти в переферии что она теперь так тормозит!? На будущее хотелось бы разобраться все таки
(25) leks88, удалить лишние доки, справочники не проблема, заново вбивать дольше.
Тормозит - долго ищет сама себя. Нужно сбросить настройки плана обмена и заново их прописать.
Проще найти готовую обработку если не можешь написать, там кода всего то.
Напряги гугл, есть в сети готовые обработки, аналогичные платной с инфострата..
Просто не всё ты описал, я вначале подумал это сбой из-за вируса.
Удачи.
А эту обработку не предлагать? Для больших файловых баз, где тормозит создание Распр узла - по моему самое оно.
1) В центральной создали новый План обмена
2) Новый узел обмена
3) Скопировали базу
4) Поменяли узлы
5) Вот готовая РИБ
затраченного времени минут 15 от силы (с копированием базы)
Решение найдено!
В свое время была внедрена обработка в конфигурацию, которая запускалась вместе с базой, она проходилась по дополнительным реквизитам справочника номенклатуры/регистру остатков и т.п. Именно эта обработка вешала всю базу. Внедрялась она отдельно в центральную и переферию. Причина зависаний не выяснена, буду разбираться еще отдельно.
Всем спасибо за советы!