Журнал Системный Администратор, Март 2008

Журнал Системный Администратор

Март 2008

Цена: $4.5 US

  Подписаться

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


Анализируем производительность «1С:Предприятие»

Андрей Луконькин

При одновременной работе с базами данных «1С:Предприятие» большого количества пользователей неизбежно возникает проблема конфликта блокировок, приводящая к снижению производительности в целом. Рассмотрим новый инструмент, позволяющий анализировать текущую производительность многопользовательской системы – конфигурацию «1С:Центр управления производительностью».

В начале нужно понять, что же «мешает» базе быстро работать, что делает её эксплуатацию менее удобной. Под блокировками понимается ограничение доступа к некоторому ресурсу при работе базы в многопользовательском режиме.

Конфликт блокировок – это ситуация, которая приводит к тому, что один из двух конкурирующих процессов ставится в очередь, что вызывает замедление работы системы, а в некоторых случаях может привести к ошибке «lock timeout» или «deadlock».

Система блокировок MS SQL Server является одним из важнейших механизмов обеспечения целостности данных информационной базы в многопользовательском режиме работы. Но, с другой стороны, она же значительно замедляет работу, а удовлетворительная скорость работы пользователей с базой данных – одно из важнейших условий функционирования системы.

С использованием конфигурации «1С:Центр управления производительностью» («1С:ЦУП») версии 1.0 (бета) можно увидеть проблемы производительности и узнать, можно ли что-нибудь сделать для её увеличения.

Приведу основные возможности «1С:ЦУП»:

n  Мониторинг показателей производительности работающей системы:

m визуальная оценка текущего состояния системы в реальном времени;

m запись и хранение исторической информации о производительности системы;

m анализ сохраненных данных за произвольный период времени.

n  Анализ проблем производительности системы:

m сбор подробной технической информации об основных проблемах производительности, имеющихся в системе;

m автоматическое получение полного контекста каждой проблемы на всех уровнях функционирования приложения;

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

m стек вызовов строк кода конфигурации, в результате работы которых возникла проблема;

m выполнение запросов к СУБД, в результате которых проявилась данная проблема;

m автоматическое ранжирование всех имеющихся проблем по степени важности;

m рассмотрение проблем по убыванию влияния на общую производительность системы.


Оставшая часть статьи доступна только подписчикам. Если вы желаете продолжить чтение этой статьи, то вам необходимо подписаться на эту статью или весь номер.

Подписаться на весь номер

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