1с начальное заполнение данных долго висит
В любой организации, временами случается проблема с «подвисанием» компьютерных программ. Пожалуй, самая неприятная ситуация, это когда зависает 1С Бухгалтерия. Программа теряет свое главное преимущество в глазах пользователей — «Быстродействие».
Так как, практически вся финансовая деятельность организаций завязывается на этом программном продукте, эффект от неприятного торможения обязательно скажется на всей инфраструктуре компании. Сделки не осуществляются, работа стоит, продажи падают, клиенты недовольны. Поэтому, устранение неприятности становится самой приоритетной задачей.
Чтобы разрешить проблему, в первую очередь, необходимо зафиксировать те участки программы, пользователей и виды операций, которые зависают. Нужно постараться составить наиболее точную картину ситуации: время происшествия, характер затруднения, разница в скорости выполнения требуемой операции. Все это поможет более точно описать возникшие проблемы, во время обращения к программистам за помощью.
В любой организации, временами случается проблема с «подвисанием» компьютерных программ. Пожалуй, самая неприятная ситуация, это когда из-за слабой работоспособности компьютера зависает 1С Бухгалтерия. Программа теряет свое главное преимущество в глазах пользователей — «Быстродействие».
Так как, практически вся финансовая деятельность организаций завязывается на этом программном продукте, эффект от неприятного торможения обязательно скажется на всей инфраструктуре компании. Сделки не осуществляются, работа стоит, продажи падают, клиенты недовольны. Поэтому, устранение неприятности становится самой приоритетной задачей.
Чтобы разрешить проблему, в первую очередь, необходимо зафиксировать те участки программы, пользователей и виды операций, которые зависают. Нужно постараться составить наиболее точную картину ситуации: время происшествия, характер затруднения, разница в скорости выполнения требуемой операции. Все это поможет более точно описать возникшие проблемы, во время обращения к программистам за помощью.
Общие причины зависаний 1C:
- Нехватка мощности рабочего компьютера;
- Слишком большой объем информации;
- Не целевое использование программного продукта;
- Излишек дополнительных, второстепенных функций;
- Ошибки в установленных настройках.
Наиболее распространенные виды проблем, возникающих при эксплуатации:
Очень долгий запуск системы
Причины замедления запуска 1С могут быть различны. Распространенные факторы, мешающие программе правильно запуститься:
При сложной конфигурации, первый запуск программы действительно может занять некоторое время. Замедление, является результатом обязательного стандартного кэширования. Этот процесс проводится один раз, при первом запуске и в дальнейшем старт будет проходить более оперативно.
Причиной медленного запуска 1С может быть массовое обращение к различным модулям, большое количество обработок.
- Скорость компиляции и исполнение второстепенных задач
В процессе отсылки к тексту какого-нибудь модуля может замедлиться компиляция. Значительное количество модулей вызывает заметное торможение.
На заметку! Эта проблема может быть разрешена проведением своевременной модификации—оптимизации. В итоге отключится исполнение многих второстепенных задач подключенных к старту системы, тем самым «облегчив» сам запуск.
- Разрешение на авто подключение к интернету, автообновление, автопоиск информации.
Возможно, программа при запуске автоматически обращается в интернет для считывания необходимой информации. Это тоже весомый повод для зависания.
Очень долгое открытие форм
Причиной очень долгого открывания форм может быть:
Большое количество элементов управления требует значительного времени на создание форм, и их взаимной увязки с компонентами. Для решения этой проблемы желательно упростить сами формы. Оставить только необходимые компоненты, а второстепенным элементам создать новую форму.
Количество алгоритмов при инициализации влияет на скорость автоматической проверки условий или считыванию необходимой информации из базы. Облегчить процесс можно оптимизировав создание и открытие формы. Отключить неактуальные алгоритмы и упростить инициализацию.
Очень долгая реакция на интерактивные действия пользователя
Если программа медленно реагирует на действия пользователя при попытке выбрать значение в элементе формы, то «виновников» возникновения проблемы необходимо искать:
Каждый раз при выполнении данного действия, алгоритмами производится проверка или просчитывание сведений, влияющих на режим выбора значения. Применив «Замер производительности» можно отыскать проблемные алгоритмы, изучить затруднения, созданные ими и оптимизировать процесс.
Формы выбора настроены на погрузку всего ассортимента элементов из базы. Устранить это недоразумение можно, тоже тщательным изучением реализации формы выбора. Проверить установленные свойства, настройки и отключить «тяжелые» алгоритмы.
Очень долгая реакция на обновления
Еще одна существенная проблема при использовании 1С Бухгалтерия — это зависание программы во время стандартного обновления. Как правило, сбои возникают во время запуска резервного копирования. В основном, такое случается в момент обновления программы через интернет. Поводом для возникновения внештатной ситуации бывает:
- Не соблюдение установленных сроков обновления.
Несвоевременные обновления, в результате чего релизы вынужденно устанавливаются друг на друга в хаотичном порядке, создадут в итоге ошибку. Для предупреждения таких обстоятельств, желательно вовремя проводить обновления или установить автоматическое обновление программы.
Кстати! Фоновое обновление программного обеспечения тоже может стать причиной для замедления некоторых процессов во время работы. Этот фактор нужно обязательно учитывать, при выяснении причин зависаний 1С.
Возможно, программе попросту не хватает оперативной памяти компьютера, и добавление объема может положительно отразиться в динамике работы.
Долгая запись объектов/проведение документов
Для выявления точной причины долгой записи или блокировки, желательно провести статистический анализ. Опция «Замер производительности» поможет проанализировать журнал регистрации, где зафиксированы и идентифицированы все транзакции. Итоги анализа могут указать на закономерные причины зависаний 1С:
Если по результатам анализа на зависание влияет не количество пользователей, а определенное время суток, вполне вероятно, что в момент произведения записи сервер в фоновом режиме проводит процедуры, установленные регламентом.
Причина монопольных блокировок интуитивно понятна — количество пользователей. Кто-то из сослуживцев занял что-то для проведения какой-то операции. Оставшимся специалистам остается только ждать, когда получится продолжить свой рабочий процесс. Причем блокировка будет длиться до конца транзакции. Например, чтобы не создавать подобных «пробок», лучше выбирать запрос — для чтения и объектную модель — при записи.
Одна из возможных причин может крыться в состоянии оборудования, которое имеет низкую пропускную способность.
Квалифицированное решение
Зависание 1С может возникнуть не только от вышеуказанных проблем. Чаще всего торможение может быть результатом неудачной установки самой платформы на компьютер. Как бы то ни было, разбираться в ситуации самостоятельно, без знания технических основ программы очень рискованно. Даже самый лучший бухгалтер с многолетним стажем и уверенный пользователь программы, не всегда сможет правильно оценить причины возникшей проблемы. Поэтому, лучше всего доверить разрешение конфликта с квалифицированным специалистам. Техническая услуга «Оптимизация производительности 1С» поможет разом решить все наболевшие проблемы.
Проведение оптимизации по повышению производительности включает в себя: поиск и устранение блокировок в коде, включение управляемых блокировок, настройку СУБД, подбор подходящего сервера и необходимых составляющих для 1С.
Мы имеем обширный опыт в оптимизации программы 1С, и оказываем комплексные услуги «скорой» технической помощи. Чтобы связаться с нами и узнать условия сотрудничества:
- Оставьте заявку на нашем сайте или позвоните нам по телефону;
- Менеджер уточнит причины обращения и зафиксирует проблему;
- Наши специалисты проведут технический аудит и экспертизу;
- Проведут полную оптимизацию 1С.
После проведения оптимизации производительности 1С, значительно повысится производительность программы. Улучшится работа систем, что в свою очередь, повысит эффективность работы всего персонала. Вы сможете, наконец, спокойно заниматься своим любимым и важным делом.
Хотите получать подобные статьи по четвергам?
Быть в курсе изменений в законодательстве?
Подпишитесь на рассылку
Хочу развернуть БСП (с основными подсистемами или полностью, все равно).
Делаю по инструкции с ИТС пункт 2.4. Быстрое начало разработки «с нуля»:
- Сравнение/объединение;
- Установить в свойствах конфигурации имя конфигурации, например, МояКонфигурация, номер версии разрабатываемой конфигурации, например 1.0.1.1.
- Скопировать общий модуль ОбновлениеИнформационнойБазыБСП и заменить в названии скопированного модуля на имя или сокращение имени конфигурации (например, ОбновлениеИнформационнойБазыМК).
- Заменить текст модуля на:
Процедура ПриДобавленииПодсистемы(Описание) Экспорт
Описание.Имя = "МояКонфигурация";
Описание.Версия = "1.0.1.1";
// Требуется библиотека стандартных подсистем.
Описание.ТребуемыеПодсистемы.Добавить("СтандартныеПодсистемы");
КонецПроцедуры
Процедура ПриДобавленииОбработчиковОбновления(Обработчики) Экспорт
КонецПроцедуры
Процедура ПередОбновлениемИнформационнойБазы() Экспорт
КонецПроцедуры
Процедура ПослеОбновленияИнформационнойБазы(Знач ПредыдущаяВерсия, Знач ТекущаяВерсия,
Знач ВыполненныеОбработчики, ВыводитьОписаниеОбновлений, МонопольныйРежим) Экспорт
КонецПроцедуры
Процедура ПриПодготовкеМакетаОписанияОбновлений(Знач Макет) Экспорт
КонецПроцедуры
Процедура ПриДобавленииОбработчиковПереходаСДругойПрограммы(Обработчики) Экспорт
КонецПроцедуры
Процедура ПриОпределенииРежимаОбновленияДанных(РежимОбновленияДанных, СтандартнаяОбработка) Экспорт
КонецПроцедуры
Процедура ПриЗавершенииПереходаСДругойПрограммы(Знач ПредыдущееИмяКонфигурации, Знач ПредыдущаяВерсияКонфигурации, Параметры) Экспорт
КонецПроцедуры
заменив в процедуре ПриДобавленииПодсистемы имя конфигурации и номер версии на установленные на шагах 1 и 2 соответственно.
- Включить возможность внесения изменений в модуль ПодсистемыКонфигурацииПереопределяемый и в процедуру ПриДобавленииПодсистем вставить строчку:
МодулиПодсистем.Добавить("ОбновлениеИнформационнойБазыМК");
указав имя модуля.
- Выполнить первый запуск. Убедиться в отсутствии ошибок при начальном заполнении.
Запуск выполняется, НО зависает на 5% Начальное заполнение данных и висит часами.
Последняя строка из журнала регистрации: Метаданные Регистр сведений. Параметры работы программы.
Пробовала добавлять общий макет (рекомендации тут же на форуме) ОписаниеИзмененийСистемы перетаскиванием из демо-версии БСП, не помогает.
Версии БСП что пробовала 3.0.2.269 или 3.0.2.264.
Платформа 1С:Предприятие 8.3 (8.3.13.1644).
Режим совместимости 8.3.12.
Методика расследования причин медленной работы операции на примере открытия управляемой формы
Для начала необходимо убедиться, что проблема стабильно воспроизводится (в одинаковых условиях) и что все пункты с описанием применения методики выполнены. Для этого можно сделать следующее:
Сбор и анализ стандартных данных
Разберем пример для операции открытия формы документа "Табель учёта рабочего времени".
Мы организовали тестовый стенд, на котором наша проблема воспроизводится под пользователем с полными правами. К этому стенду мы можем подключаться как напрямую с удаленной рабочей станции в режиме тонкого клиента, так и в режиме веб-клиента через публикацию на веб-сервере.
Настройка технологического журнала на клиенте может быть такой:
Фильтр по имени процесса для нашей задачи избыточен и нужен для того, чтобы в случае ошибочной настройки такого лога на сервере не получить сбор всех событий для серверных процессов, что может занять значительный объем. С другой стороны, при осознанном включении такой настройки на сервере (если клиентские приложения запускаются там же, где может быть развернут и сервер приложений 1С:Предприятие) мы в отдельном каталоге Client_Full увидим данные только клиентских приложений (хотя при этом подкаталоги других процессов тоже будут созданы, но они буду пустыми). Свойство Interface не собираем, так как оно дублируется более "человек читаемым" свойством IName (хотя даже последнее нам в данном примере не обязательно нужно).
После настройки технологических журналов и проверки корректности замера времени ОценкиПроизводительности БСП выполняем повторение операции с включенной отладкой.
Замеры времени средствами БСП будут выглядеть следующим образом:
Везде далее будем рассматривать верхний в этом списке замер от последнего повторения, его длительность 13,022 секунды.
Замер отладчиком конфигуратора изображен на следующем рисунке:
Как видно, сумма длительности всех строк, связанных с открытием формы составила всего 1,523 секунды.
'00010101' + ТекущаяУниверсальнаяДатаВМиллисекундах() / 1000
а для миллисекунд взять остаток от деления на 1000 (то есть просто последние три цифры, обратите внимание на "779" на следующей картинке).
Точное время начала замера (минут:секунд.миллисекунд): 25:10.779
Точное время окончания замера (минут:секунд.миллисекунд): 25:23.801
Найдем теперь записи технологического журнала, соответствующие данному замеру, они будут примерно следующими:
Здесь видно, что соответствующий нашему замеру серверный вызов SCALL завершился примерно за 10,1 секунды, это соответствует интервалу между запросом VRSREQUEST и ответом VRSRESPONSE.
Причем время начала замера почти совпадает с началом вызова, то есть событием VRSREQUEST, что собственно ожидаемо, так как замер БСП начинается на клиенте и должен быть непосредственно перед командой открытия формы. А вот окончание вызова сервера случилось раньше, чем окончание замера, что значит, что эта разница во времени пришлась на часть работы клиентского приложения.
Итак, промежуточный итог по длительностям замеров разными способами показывает соответствие нашей ситуации ограничениям и выполнение неравенства: 1,5 < 10,1 < 13.
Стандартными инструментами не удается увидеть причину проблем низкой производительности работы (открытия) управляемой формы, поэтому воспользуемся следующими помощниками:
- Отладчик операционной системы: Windows Performance Recorder для сбора метрик и Windows Performance Analyzer для их визуализации и анализа;
- Анализатор сетевых протоколов Wireshark или прокси-сервер Fiddler Web Debugger.
Установим и запустим Windows Performance Recorder ("C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\WPRUI.exe"), укажем настройки:
После того, как их подготовили, перейдем в тонкий клиент 1С, откроем форму списка документов и непосредственно перед воспроизведением проблемной операции запустим сбор данных WPR (кнопка Start).
После открытия формы в тонком клиенте запись можно остановить и открыть ее для анализа. В открывшемся окне найдем по PID 5508 (его можно определить в диспетчере задач ОС или по логам ТЖ) наш тонкий клиент 1С и должны получить примерно следующую картинку:
По данным Windows Performance Analyzer видим, что у нас нет серьезной нагрузки по дискам, а поток тонкого клиента потребляет 100% ЦП на протяжении длительного времени вплоть до завершения замера.
Запомним этот результат и проанализируем траффик.
Запустим Wireshark и повторим проблемную операцию в тонком клиенте 1С:Предприятие с прямым подключением к серверу приложений 1С.
При сборе данных с помощью Wireshark (и отбору по пакетам с сервером-источником равным серверу приложений 1С:Предприятие) запуск открытия формы документа будет выглядеть примерно так:
Здесь каждая такая строка – это пакет (или если точнее, то "кадр", frame), который в свою очередь является частью общего большого пакета поверх протокола TCP (PDU – Protocol Data Unit). Если их сложить, получим пакет около 70 Кб. Стоит обратить внимание, что это будет размер с учётом сжатия, а если без него – то должны получить что-то около 2500 – 3500 Кб данных.
Устанавливаем и запускаем Fiddler, на панели инструментов ищем "Browse", выбираем любимый браузер и запускаем в нем необходимое нам приложение (информационную базу 1С:Предприятие). После запуска переходим в форму списка документов (готовимся воспроизвести сценарий), возвращаемся в Fiddler и включаем сбор траффика (кнопка F12), переходим в браузер и открываем форму документа. После её открытия сбор траффика можно отключить и заняться его анализом. Мы должны получить примерно следующее:
В данном дампе достаточно быстро находится относительно большой пакет искомого размера, выбираем его в списке слева, а в правой части окна переключаемся на страницу Inspectors, выбираем там просмотр заголовков (Headers), и так как у нас пакет является сериализованным json (Content-Type: application/json), то попросим Fiddler десериализовать его для нас.
После этого в окне предпросмотра отобразится древовидная структура ответа (response), которая передается с сервера на клиент и содержит так много данных. Далее нам необходимо проанализировать её и найти наиболее проблемные места. Может помочь кнопка Expand All, которая развернёт все элементы дерева, но это может занять некоторое время. Чтобы его сократить, сначала поймем, что именно нужно искать.
Подведем промежуточный итог:
- Проблем с медленной работой прикладного кода 1С или запросов нет.
- Большая часть времени открытия формы состоит из сетевого взаимодействия.
- Размер пакета с формой подозрительно велик.
- После получения пакетов имеем высокую утилизацию ЦП тонким клиентом 1С (или веб-клиентом).
- Потерянное время находится где-то между окончанием/началом работы прикладного кода 1С и сетевой передачей.
Из всех этих пунктов для нас наиболее полезным и требующим дополнительного анализа является тезис "Размер пакета с формой подозрительно велик".
Какие могут быть причины для такой ситуации? В общем случае их несколько:
- Сама по себе большая и сложная форма с большим количеством экранных элементов и реквизитов. Наверное, редкий и точно не очень правильный случай, лучше такого избегать на этапе проектирования систем.
- Простая форма, но много данных в реквизитах формы (включая данные объекта), в особенности:
- Хранилище значения, Строка(0);
- Большие коллекции (Таблица, Дерево, Список);
- Произвольный тип (концентрация проблем).
Так как наша проблема (у вас может быть по-другому) воспроизводится даже при очень небольшом количестве данных в ТЧ, и реквизитов у документа (т.е. объекта формы) совсем не много, то их мы не рассматриваем. Остаются реквизиты формы, не равные основному реквизиту "Объект".
Среди них находится несколько реквизитов, имеющих произвольный тип. Могут выглядеть так:
Сопоставляем эти данные с уже собранным ранее замером с помощью конфигуратора, и видим заполнение этих структур достаточно большим количеством элементов (например, можно 5059 в реквизите "СвойстваИзмерений").
Снова вернемся к дампу траффика в Fiddler и найдем там элемент, отвечающий за параметры формы (response/props). Увидим там примерно следующее:И если развернем далее эти элементы, убедимся, что их там несколько тысяч, каждый из которых представляет собой вложенную структуру вида:
Найдем прикладной код, заполняющий эти параметры, и убедимся, что данных там действительно достаточно много (2-3 Мб), и они представляют собой большое количество сложных вложенных структур.
Отключив заполнение данных реквизитов, убеждаемся, что проблема с производительностью формы исчезает, что значит, что причина была найдена правильно.
Выводы и рекомендации
Длительная работа открытия формы обусловлена сериализацией и десериализацией больших коллекций значений при передаче их между клиентом и сервером.
Для того чтобы оценить степень влияния всех факторов, которые имеют значения в этом процессе, можно сделать несколько тестов (замеров), изменяя эти факторы и оценивая корреляцию их значений и длительности. В нашем случае причиной проблем были структуры, хранящие данные справочников территорий и условий труда, поэтому изменяли количество этих элементов и пробовали замерять передачу с клиента на сервер этих данных (процедура ДанныеДляРедактированияВХранилище).
В следующей таблице приведены результаты таких замеров в нашем примере. Сразу следует оговориться, что не стоит никаким образом рассматривать в ней абсолютные значения, так как это будет зависеть еще и от конфигурации компьютера, сети, версии платформы и многого другого, связанного именно с нашим примером. Для нас же важны зависимости и их характер (линейная, экспоненциальная и т.д.). Предлагаем вам проанализировать их самостоятельно (или даже повторить замеры на актуальной версии платформы в вашей среде).
Принимая во внимание полученные таким образом данные, можно предложить следующие возможные пути решения:
В финансовых решениях консолидационного класса или класса ERP предлагается функциональность, связанная с составлением оперативных или мастер-бюджетов, например, работа с бюджетом доходов и расходов.
Экземпляр бюджета — это хрестоматийный пример сложной формы, где есть:
- данные в разрезе каждого месяца года (в колонках);
- группировка по настраиваемой структуре разделов и статей (в строках);
- возможность внесения изменений онлайн;
- автоматический пересчет сумм зависимых формул;
- отрисовка плана и факта рядом на пересечении месяца и статьи;
- вывод в будущих месяцах плановых значений в ячейках факта.
Как видно, логика работы достаточно нагруженная и, как следствие, данных на форме много.
Руководитель подразделения открывает форму экземпляра бюджета и долго ждет ее открытия. Если время ожидания слишком велико, то в конечном итоге менеджер переходит для осуществления процесса бюджетирования в табличный инструмент класса Excel.
После разработки и включения в рабочую базу оказалось, что открытие формы бюджета в терминах структур разделов и статей компании занимает 1,5 минуты и более. Это неприемлемо, тем более что основные пользователи системы — руководители подразделений, и без того сталкивающиеся с нехваткой времени.
Мы поставили перед собой задачу сократить открытие такой формы до времени
Программная и аппаратная инфраструктура
- Нетиповая конфигурация собственной разработки.
Замечание: подобные проблемы могут также быть актуальны для иных систем класса ERP, например:
Используется трехзвенная клиент-серверная архитектура с доступом тонкого клиента через веб-сервер. Сервер СУБД и Сервер 1С:Предприятия совмещены на одной машине.
Сервер СУБД
- Процессор: Intel Xeon CPU E5-2637 v2, 2 процессора 3,5 Ghz.
- Память: 96 GB (разрешено потреблять СУБД не более 73728 MB).
- Жесткий диск SSD.
- MSSQLServer 2014 (12.0.4237.0).
- MS Windows NT 6.1 (7601).
Сервер «1С:Предприятие»
- Тот же сервер, что и сервер СУБД.
- Память: доступна вся свободная память, то есть, не менее 24576 MB.
Веб-сервер
- Процессор: Intel core 2 DUO E7500 2,93 GHz.
- Память: 4 GB.
- MS Internet Information Services 8.5.96.
- MS Windows Server 2012 R2.
Тонкий клиент
- Процессор: Intel Core i5.
- Память: 16 GB.
- Диск SSD.
- 1С 8.3.14.1694 — тонкий клиент.
- MS Windows 10.
Ищем причину медленного открытия формы и устраняем ее в «1С»
1. Для начала расследования снимаем замер производительности в «1С» процесса открытия формы
В замере видно, что лидер по абсолютному времени выполнения — метод «ОткрытьФорму».
Из 104 секунд открытия 64 приходятся на этот метод.
При этом сделать вывод о причинах медленного открытия из этого замера невозможно.
2. Соберем технологический журнал для анализа медленного открытия
Какие события собираем
Собираем события CALL и SCALL.
Выдержка из документации по платформе:
- SCALL — исходящий удаленный вызов (исходящий вызов на стороне источника вызова).
- CALL — входящий удаленный вызов (удаленный вызов на стороне приемника вызова).
Эти события возникают при клиент-серверном взаимодействии.
Бытует мнение, что SCALL всегда возникает при обращении с клиента на сервер, а CALL — при приходе этого обращения на сервер.
Нередко это так и есть, например, когда клиент обращается к серверу.
Однако это не всегда так. Например, могут быть обращения внутри сервера между менеджером кластера и рабочим процессом, между сервером и клиентом и так далее.
Пример иного случая возникновения событий CALL и SCALL.
Цели сбора
Преследуем 2 цели:
- посмотреть длинные по времени вызовы;
- найти «лаги» в технологическом журнале.
С длинными вызовами вопросов не возникает: есть оператор программы, который длится слишком долго, и это можно в явном виде обнаружить в ТЖ. По сути, хотим увидеть то же, что в замере производительности.
Что такое «лаг технологического журнала»? Под ним понимается ситуация, когда в явном виде событий с большим временем исполнения в журнале нет, но косвенно об этом догадываемся за счет присутствия большой паузы между двумя соседними событиями в журнале по одной сессии.
Метод сбора
Метод сбора технологического журнала (далее — ТЖ) — обычный:
- в папке C:\Program Files\1cv8\conf создаем файл logcfg.xml (структура файла ниже);
- ждем, пока в папке с логами, указанной в logcfg, появятся подпапки с именами процессов сервера;
- выполняем открытие формы;
- убираем файл logcfg.xml из папки;
- ждем не более 5 минут, пока система завершит запись файлов журнала;
- забираем файлы технологического журнала из подпапки rphost_.
В нем настроено:
- папка для сбора логов C:\logs;
- отбор по событиям CALL и SCALL;
- отбор по имени базы rarus_fb.
Анализируем данные собранного лога технологического журнала. Нехитрым скриптом посмотрим наиболее долгие вызовы.
Примечание по скрипту
По сути, скрипт отбирает из ТЖ события, с длительностью от 2 знаков (с 10 секунд и более). Т. к. время в ТЖ 8.3 — в микросекундах, то нам нужен отбор по времени > 8 разрядов; чтобы не писать много букв в регулярном выражении, используем синтаксис расширенных регулярных выражений: , который включается ключом -E.
Видим, что существует долгое событие CALL длительностью 85 секунд, на котором происходит большое потребление памяти 554 Мб, а в пике 701 Мб и оно возникает на методе ПолучитьФорму.
Соберем лаги ТЖ.
Сделаем это более сложным скриптом, суть которого в том, чтобы сравнить по времени 2 соседних события ТЖ и найти среди них наибольшие паузы.
- в скрипте делаем отбор по t:clientID, равному ID нашего клиента, чтобы учесть только события по текущему пользователю.
В результате получаем:
В первой колонке — время лага в микросекундах, далее — время старта двух соседних событий.
Видно, что первым номером идет лаг, сопоставимый по времени с временем открытия формы.
Делаем предположение, о том, что тяжелая форма долго загружается с сервера на клиент.
3. Посмотрим на форму в конфигураторе
Что же такое разработчик заложил на форме? Может быть данные формы перегружены избыточной информацией?
Важный элемент расследования — просто посмотреть на творение рук разработчика глазами в конфигураторе «1С».
Видим несколько таблиц значений на форме. Отладчиком посмотрим для реального бюджета, какое количество строк в них.
А строк совсем немало. И всё это при открытии перегружается с сервера на клиент.
Убедимся в этом тезисе.
4. Используем Fiddler в режиме ReverseProxy
Чтобы окончательно убедиться в том, что медленная работа обусловлена «большими» данными формы и понять, что именно это за данные, перехватим их.
Режим Reverse proxy позволяет «вставить Fiddler в разрыв» между веб-сервером и клиентом и проанализировать пакеты обмена.
Настройка Fiddler в режиме ReverseProxy
Настройку будем производить на копии рабочей базы, которая развернута в той же инфраструктуре.
Настройка режима состоит на верхнем уровне из двух этапов:
- настроить на веб-сервере переадресацию url-rewrite на сервер с Fiddler’ом;
- настроить сам Fiddler.
Для настройки веб-сервера вводим правило url-rewrite на сервер finsrv, порт 8888, на котором будет слушать Fiddler.
Устанавливаем на отдельный сервер наш Fiddler и настраиваем в режиме Reverse proxy, как описано здесь.
-
Проверяем в опциях, что установлен флаг «Allow remote computers to connect».
-
if (oSession.host.toLowerCase() == "webserver:8888") oSession.host = "webserver:80";
Отслеживаем взаимодействие между веб-сервером и клиентом «1С»
Зайдем в копию базы и дойдем до открытия формы экземпляра бюджета, но открывать не будем. Перейдем в Fiddler, посмотрим, пакет с каким номером был получен последним, и запомним его номер. Теперь откроем форму бюджета, дождемся окончания открытия и посмотрим все пакеты от запомненного до самого последнего.
Видим входящий запрос с большим объемом данных.
Предполагаем, что это и есть данные формы. Смотрим подробности данных в правом окне:
Обращаем внимание, что прочитать можно только заголовки, а данные, похоже, сжаты, о чем также свидетельствует надпись 1C‑SDCversion и далее — MZ, что соответствует началу сжатой части.
- По 1C-SDCversion — ищем на партнерском форуме «1С» и встречаем упоминание о том, что это метод сжатия deflate.
Вспоминаем, что по умолчанию клиент «1С» запрашивает работу со сжатием данных между клиентом и сервером.
С помощью запуска тонкого клиента со специальным параметром отключаем этот режим.
Делаем повторное открытие формы и видим в Fiddler’е уже вполне читаемую картину.
Обращаем внимание, что без сжатия данные формы весят более 1 Мб, что немало.
Наконец справа видим данные формы:
Переходим на представление «TextView», копируем в буфер и сохраняем как xml.
Обращаем внимание на наличие больших блоков в ветке props c внушительным количеством строк, которое сопоставимо с числом строк таблиц значений на форме:
а также со свойством fullChanged="true". Последнее скорее всего означает разрешение на изменение строк объекта на клиенте.
Выдвигаем предположение о том, что в данных формы на клиента приходят с сервера служебные таблицы значений.
С точки зрения функционирования алгоритма они не требуются на клиенте. Принимаем решение избавиться от таблиц значений на клиенте.
5. Разгружаем форму в «1С»
Что тяжелее всего?
- На форме есть таблицы значений с большим числом строк.
- Обработка объект содержит табличные части с большим числом строк.
Отказываемся от использования таблиц значений на форме и табличных частей в пользу такого подхода:
- на сервере создаем таблицы значений;
- при переходе на клиента помещаем их во временное хранилище, а на форме храним только его адрес;
- после возврата на сервер получаем таблицы значений из временного хранилища.
6. Смотрим в Fiddler результат «разгрузки» формы
Видно, что объем данных формы сократился более чем в 5 раз.
7. Делаем повторный замер производительности и смотрим потребление памяти и лаги в ТЖ
Накатываем изменения на рабочую базу, собираем замер производительности «1С».
Видим, что теперь открытие формы экземпляра бюджета составляет 25 секунд, а метод ОткрытьФорму — всего 2,1 секунды.
Практически пустая база. Количество позиций номенклатуры = 40 тысяч. Количество документов штук 10. Ввод остатков, установка цен.
Открываю форму списка документа при этом количество документов в списке = 0.
Делаю замер времени.
Время ПЕРВОГО открытия 15 секунд. Если открываю второй раз то время открытия 0.2 секунды. Подобная картина повторяется со всеми формами.
Время ПЕРВОГО открытия формы отчета 20 сек. Потом открывается за 0.3 сек.Да Intel Xenon CPU E3-1230 V2
Загрузка процессора 0% С памятью что-то не пойму
Доступно 7 Gb, Свободно 0.5Можно ли указать местоположение файлов кэша Сервера 1С предприятия?
Хочется этот мусор разместить на быстром диске(11) я переопределял переменные TMP, TEMP для каждого пользователя на терминальнике
заодно удобно удалять, когда у кого-то форма разъезжаетсяЯ имею в виду кэш сервера 1с Предприятия. Именно он тормозит работу. Местоположение кэша: C:\Program Files\1cv8\srvinfo\reg_1541
чтобы при обновлениях это вдруг не слетело, можно домашний каталог полностью переопределить для пользователя, под которым запускается ragent
можно сделать ссылку на каталог с другого диска
в линупсах это ln -s, а ссылки ntfs я так и не осилил ):рекомендую после теста на старом месте srvinfo сбэкапить и удалить (можно просто переименовать)
Это за гранью. Через несколько суток работы первое открытие любой формы занимает по 20-30 секунд.
Это же не правильно. Так не должно быть. Я так понимаю нужны постоянные танцы с бубнами вокруг Сервера1с предприятия.
А народ вообще-то работает на 8.3 вообще и с УТ11 в частности?Нет не устанавливаю. Практически типовая УТ11. Немного переделано адресное хранение. Единственно в базу залито 40 тыс. номенклатуры.
Посмотрел, диски на сервере шустрые.
диск С на 80% процентов пустой. диск D - SSD . SQL данные хранит на SSD, файл транзакций на С(16) у меня периодически начинают массово плодиться зависшие процессы с фоновым заданием обновление индекса ППД, точную зависимость от чего пока не установил
раньше ребутил все, а теперь чукча умный - один процесс грохнул и работаем дальше.
влияет на скорость открытия вообще всего, над каждой кнопкой думать начинает. База и все кэши - на ssd.
Все эти индексы ППД первым делом убивать надо. Если на сервере висят штук 5 баз, даже не работающих, индексы ППД положат любой сервер.
Нельзя ли узнать фамилию умника который придумал использовать полнотекстовый поиск в 1С ?
Когда начинает подвисать открытие форм, в базе никто не работает, даже фоновые процессы. Специально смотрел. В лучшем случае открыт конфигуратор и клиент. Загрузка сервера 0% память тоже свободна.(0) > память тоже свободна
вот под виндой я б не стал так утверждать, она сама себе на уме по поводу реального распределения памяти и его отображения.память может в резерве висеть под процесс, который никому не сдался, а 1с в это время в свопе барахтается
а диспетчер задач при этом показывает 95% свободно
(26) В этом что-то есть. В диспетчере задач видно, что Доступно 9.4 Гб
Свободно 0.7 Гб
Но как пишут умные люди, это вполне нормально. Как только потребуется память, она будет сразу освобождена. Как только у меня начнет виснуть я попробую освободить ее. Есть спец. утилита(27) кроме процессов есть filesystem cache, который не виден ни в винде, ни в линуксе. Он ядреного уровня, к процессам не относится. На некоторое время работающей системе (т.е. не сразу после старта) обычно это весь свободный объем настоящей железной оперативки (без свопа).
в линупсе объем памяти, занятый под fs cache хотя бы увидеть можно, но повлиять - никак
в вантузе его и увидеть нельзя, будет рапортовать, что все свободноа любимый 1с будет барахтаться в свопе, потому что кто-то файл открытым на чтение держит
(29) типичный коммент пользователя операционной системы, который не пытался разобраться в ее работе
оракл свой libaio вообще сделал, чтобы в этих приколах не разбираться, а работать напрямую с железом
(28)
Для win7 это 2 показатель группы "Физическая память" на вкладке "Быстродействие".Как только физической памяти станет не хватать какому - то приложению - винда начнет сбрасывать кэш на диск.
Все достаточно прозрачно.
Правда сбрасывает она блоками и, если приложение начинает постоянно потреблять память - винда начинает постоянно сбрасывать блоками, поэтому иногда проще выдавить кэш вручную, запросив у Винды большой блок.
У меня утилитка есть самописная, которую запускаю, когда обработав долго в конфигураторе - (сборка комплекта, ТИИ, и.т.д) - знаю, что работать с ним уже не буду и файловый кэш бесполезен.
У меня файловый кэш был максимальным в 13 гигобайт, больше винда отказывалась забирать, несмотря на все старания.
Есть утилитка RamMap она показывает какие процессы/файлы занимают память системы, эта же утилита позволяет очищать кэш в памяти.
processexplorer fs cache не показывает, поэтому я склонен думать, что этот параметр пользователям винды недоступен
в линуксе обычный top не показывает, htop может показать, если попросить
простая задачка:
предположим, 5 разных пользователей зашли по RDP через канал GPRS
каждый из них решил скопировать к себе кино весом по 5GB (разные) и начал процесс копирования, т.е. открыл файл на чтение
в это время админ решил заменить все фильмы бинарным мусором и перезаписал их, т.е. открыл на запись. Уже начатый процесс копирования должен отдать тот файл, который пользователь начал читать. Т.е., операционная система должна где-то хранить исходные 5х5 = 25 GB кино, которые раздолбаи через GPRS уже начали копировать. Да, такая фунцкция есть у всех современных файловых систем. Однако, программа должна уметь ее использовать. Что-то мне подсказывает, делается это редко. MS SQL сервер умеет это делать. Насчет остальных сильно не уверен.Вот какое наблюдение есть. Только за сегодня размер кеша Сервера1С (C:\Program Files\1cv8\srvinfo\reg_1541\)предприятия составил 0.7 Гб. В SQL размер данных составляет 1.2 Гб.
Они чего в кэш вытаскивают всю базу?
(41) Ничего особенного в кэше не лежит. При ручной остановке и запуске Сервера1С эта папка очищается. Если у вас настроено автоматический перезапуск процесса rphost, то ничего не чиститься.
А теперь смотрите последние наблюдения:
Объем данных, которые ЧИТАЕТ "тонкий" клиент с диска (процесс 1cv8c.exe). Конфигурация УТ11, SQL, управляемые формы. Сервер1С х64. Данные получены с помощью системного монитора ресурсов.
1. Сразу после перезагрузки сервера 1СПредприятия. Размер кеша 60 кб. Все летает. База запускается за 30 сек. Все формы открываются за 1 сек.Такое ощущение, что после первого открытия формы, данные кеша попадают в кеш (память) Windows и открытие форм несколько ускоряется.
А теперь к знатокам. Что же лежит в папке C:\Program Files\1cv8\srvinfo\reg_1541\. И как отключить такое кривое кеширование в Сервере1С.
2. Каталог непонятно чего. С файлами "snccntx.0000000A.dat" размерами по 54 мб. После перезапуска Сервер1С предприятия там один такой файл. Через двое суток интенсивной работы с конфигуратором и базой, таких файлов становится более 10 штук. И база начинает тормозить. Более того Сервер1С предприятия процессы ragent.exe и rmngr.exe начинают жрать ресурсы по 50% ресурсов одного ядра процессора каждыйюСеансовые данные - данные, которые могут мигрировать между процессами rphost при переключении сеанса с одного процесса на другой.
временных хранилищ
и.т.д.Сеансовые данные - данные, которые могут мигрировать между процессами rphost при переключении сеанса с одного процесса на другой
(62) как успехи? У меня такая же фигня. Все формы открываются пусть не 20-30 секунд, но по 5-8, а это тоже не допустимо
Перезапустил ручками сервер 1СПредприятия. Работает 18 часов. Формы и программа открываются на Ура.
Однако сегодня утром обнаружил, что Сервер1С предприятия (ragent.exe) и диспетчер кластера (rmngr.exe) на двоих полностью загружают одно ядро процессора.
Все фоновые задания отключены. Сеансов к Сервер1С нет. Одно подключение к Сервер1с - планировщик. Системный монитор не показывает никакой активности по диску, памяти, сети. SQL профилер не показывает никакой активности с базой.
Я думаю - это БАГ платформы. При этом платформа ведет себя подобным образом стабильно. Через 10 часов эти два процесса начинают жрать процессорное время.
На таких глюкавых платформах работать нельзя.Вот сегодя заметил, что первое открытие любой формы занимает где-то 5 секунд. Повторное открытие - 1-2 секунды. Вчера, после перезагрузки Сервер1с, все открывалось за 1-2 секунды
(75) А там скорее всего все болтается. Из принципа "купим монстра за бабаблобло, за 100500 нефти", а чтобы не простаивал - накатим туда от 1С, до файл-принт-мэйл-сервера.
(74) Можно. Нельзя клиент-серверную восьмерку пускать в терминал. Особенно Тонкий клиент. Она не для этого разрабатывала 3-х звенку.
Ну и в 8.2 у Тонких форм была градиентная заливка, которая через терминалку жестко отрисовывалась. В 8.3 - не знаю, не проверял, может пофиксили.
Ничего там на этом сервере не болтается кроме 1С. А с терминалом удобно держать одну версию из всего зоопарка платформ и быстро обновлять если надо.
На предыдущем месте я пробовал работать в режиме тонкого клиента через rdp и по сети. По сети немного медленнее получалось.(80) Освой для себя административную установку 1С.
Давай, развивайся, думай! Это тебе не про курс рубля ерунду нести!Нет не такси. Практически типовая УТ11. Если вы такой умный, то объясните, чем занимается Сервер1с и кластер предприятия см (64) , съедая ресурсы одного ядра. Не обращаясь к другим ресурсам системы? Может вы знаете способ остановить потребление ресурсов не перегружая Сервер1С?
(81) я про то что в 8.3 тормоза с градиентом не фиксили, а что у автора не знаю.
Такси, кстати, и на клиентском десктопе быстрее чем обычные УФ работает.
Я тоже проходил через эти самые тормоза. Вешались по полной. Я не знал куда щемиться, что происходит. Периодически перегружал сервер приложений. Народ до УТ 11.1 в 7.7 работал. Привыкли, что все летает. Но летало только у менеджеров. Потом по выходным бух-ша что-то там шаманила для себя. А закрытие делалось, вообще, 3 дня.
Сейчас в УТ 11.1 тормоза с открытием форм(особенно, первоначальным), народ чуток попривык. Зато все, что сам дописываю, работает, вроде, шустро.(88) Нельзя же всю УТ11 переписать. Хотя приходится. УТ11 оптимизировано под ларек. А у нас 40 тыс. номенклатуры. Простейшие операции длятся:
1. Удаление помеченных объектов без ссылок - 18 часов. После переписи 30 мин.
2. Открытие документа установка цен номенклатуры на 28 тыс. позиций - 3 минуты, ручное изменение цены в каждой позиции - 2 мин. Чтобы ввести цены вручную требуется 30 суток :)
3. Убогие отчеты.(89) Вот тут идеально Чистов нужен, чтобы показать, на что способен пользователь. А то "зачем нужна ТЗ на 9000 строк на клиенте. 1С сама знает как надо".
Тут ребята 28тыс. строк в док загоняют без лишней скромности.
Нудаладно, вводначальныхостатков.
Но потом правят. Руками.1С к такому не готовили :-)
(90) А как вы прикажете работать с большими базами? Конечно если бы разработчики платформы на управляемых формах написали, что " НЕ НАДО ИСПОЛЬЗОВАТЬ управляемые формы" их если количество позиций в справочнике или строк больше 1000.
Мы бы и не рыпалисьПродолжаем пляску с бубнами. Пока вырисовывается следующая картина.
В 1С83 очень кривой механизм кеширования на клиенте. Первое открытие ЛЮБОЙ формы вызывает чтение файла кеша на клиенте. При запуске программы файл кеша читается до 10 раз. Первое открытие ЛЮБОЙ формы после изменения конфигурации увеличивает файл кеша на 200 кб. После чистки кеша пользователя и первого запуска программы размер файла кеша становится 1.5 мб. Потом он постоянно увеличивается. У меня в процессе активной разработки конфигурации за несколько дней он выростал до 65 мб. После этого время открытия программы составляло до 1 минуты, а время открытия любой формы до 20 сек. После чистки кеша все приходило в норму.
При этом самое интересное, что при использовании SQL и быстрого канала при отсутствии кеширования формы открываются существенно быстрее, чем при кешировании.
О каком быстродействии можно говорить, если при нажатии любой кнопки на клиенте читается и анализируется файл размером 60 мб?(98) Кеширование, к сожалению, отключить не возможно. Но можно выходить из программы каждые 10 мин, а в это время специально обученный человек будет ручками чистить кеш :)
Читайте также: