Увеличение производительности информационной системы 1С 8 различными способами (блокировочный механизм, оптимизация кода, параллельные вычисления)   

Версия для печати   

Технический директор компании Софтпоинт. Эксперт по производительности, один из авторов мониторинга PerfExpert, репликации информационных БД. Под его руководством выполнено более 300 проектов по производительности 1С.


Наша компания и я, в частности, более 7 лет занимаемся разработкой и оптимизацией систем на базе 1С. Кроме этого, мы занимаемся обменом между базами 1С в режиме online, различными интеграциями, кластеризацией, масштабируемостью и параллельными вычислениями. У нас более 400 успешных проектов по производительности, из них более 100 на системе 1С версий 8.1 и 8.2. Чтобы вы понимали уровень систем, которые мы оптимизируем, я  могу привести параметры оптимизированных систем  – до 1500 в одной базе данных и по размерам файлов баз данных – это более 2 Террабайт.

            Соответственно, за это время, шаг за шагом совершенствовали свои методы,  эволюционировали свои технологии, и пришли к некоторым результатам и выводам, с которыми хотим вас ознакомить.

Классификация проблем производительности

            Давайте немножко помечтаем:

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

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



  • Первая группа – легковоспроизводимые проблемы. Я уверен, что вы с ними сталкивались повсеместно. Это может быть оптимизация запросов, не оптимальность алгоритма в коде приложения, различные неэффективные индексы. По этим проблемам много литературы. Компания«1С» и прочие крупные франчайзинговые компании разрабатывают курсыпо совершенствованию навыков программистов и администраторов 1С по вопросам производительности. Эти проблемы, как правило, можно вычислить и исправить собственными силами без специальных нестандартных инструментов.
  • Есть также другой тип проблем. Это проблемы непостоянные и непредсказуемые. Наверняка, вы тоже отчасти с этим сталкивались, но возможно, представляли совсем другую их природу. Это могут быть проблемы, которые появляютсянеожиданно. Например, это может быть падение на каком-нибудь узле – пользователя, сервера приложений, это может быть торможение в определенный момент. В общем-то, причинами этого всего может быть что угодно. Это может быть работа регламентного задания, которая приводит к сбою по определенным причинам или вызывает общее торможение системы в момент своей работы. Для таких проблем обычно должна использоваться другая методика решения.
  • Третий вид проблем (я специально эти проблемы выделил в особую группу) – это проблемы предсказуемые, но сложно решаемые. Вы понимаете, что никакими стандартными средствами 1С не решить определенные задачи (для примера возьмем проведение больших регламентных документов, восстановление последовательностей, которые не укладываются у вас в определенное время). Соответственно, про такие проблемы вы понимаете, что их надо решать, но не понимаете, как это сделать. Для решения подобных проблем используются такие технологии, как, параллельные вычисления, распределенные дисковые хранилища и пр.

На экране не зря приведена картинка с медицинской рукой, которая измеряет дыхание или меряет пульс. То есть, если привести аналогию с оптимизацией – в общем-то, все те же самые «профилактические процедуры» вы можете встретить в медицине. Для лечения системы мы используем практически все те же самые средства, которые врачи используют для лечения человека – система это тоже многофакторный сложный организм. К ее исследованию нельзя подходить «в лоб» - без учета хотя бы основных факторов, делать какие-то заключения.

      «Жили мы, жили без проблем…и вдруг…», - собственно, так и бывает. Проблемы есть всегда, поговорим о способах их решения. В момент, когда в отрасли компьютерной техники происходил бурный рост - увеличивалась частота процессора и количества транзисторов – те проблемы, которые у нас тогда все были -  решались простой покупкой нового оборудования – частота растет, диски улучшаются, объем памяти увеличивается – все можно решить в рамках такого подхода. А где-то уже в начале 2000-х годов, когда в продажу поступили сравнительно дешевые компьютеры с многоядерными процессорами, решение проблем производительности стали решатьсянетривиально. Для того чтобы решить эти проблемы – недостаточно купить оборудование. А в ряде случаев, мы вообще считаем, что покупка нового оборудования – это неэффективный подход без правильного и логическогоаргументирования необходимости.

Поиск причин проблем производительности

      Если взять ситуацию, при которой ваша система хоть какое-то время в начальном периоде приемлемо работала, то основные причины, в порядке популярности, выглядят именно так:

 

  • Плохое качество контроля (систему запустили) – не следили за ее параметрами
  • Бурный рост компании привел к тому, что увеличились информационные потоки, а IT-инфраструктура не поспевает за этим процессом. Конфигурация, предназначенная для автоматизации бизнеса вашей компании, сначала разрабатывалась одним программистом, потом происходили рокировки в числе разработчиков, образовывались тупиковые ветки функционала, алгоритмы, в которых никто не может разобраться…Система вышла из-под контроля, не только с точки зрения функционала, но и производительности.
  • При внедрении нового функционала мы не всегда проверяем, насколько это можно делать. В частности, не проводятся нагрузочные тестирования, либо тестирование не затрагивает новый функционал. Эта причина, в основном связана с уровнем развития IT-инфраструктуры в целом в организации. Чаще всего на это закрывают глаза, думая, что купив дорогостоящие программные или аппаратные ресурсы это решится само собой.

Особенности проектов по оптимизации производительности информационных систем

Для того чтобы вы проще понимали, какие особенности в отличие от проектов интеграции и автоматизации вы встречаете в проектах производительности – мы хотим сделать акценты на некоторых особенностях проектов производительности, которые надо учитывать:

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

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


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

Вторая особенность проектов по оптимизации производительности


Вторая особенность проектов производительности в том, что проблемы производительности распределены во времени неравномерно.

Если мы решаем проблемы из второй и третье групп проблем (проблемы непостоянные и непредсказуемые или предсказуемые, но сложно решаемые), то – обычно бывает, что система в принципе – работает. 2 часа стабильной работы -  15 минут «простоя». Дальше опять – работаем весь день – 15 минут «простой». Может быть много факторов, от которых это зависит – регламентные операции, административные мероприятия – отгрузки, акции, сезонность – множество факторов… Но, необходимо помнить, что эти «зависания» системы сосредоточены в определенных моментах времени, которые зачастую достаточно непродолжительны.

Третья особенность проектов по оптимизации производительности

Итак – переходим к третьей особенности:




Не надо думать, что проблем большое количество – 100, 1000. Не смотря на то, что у вас 100000 строчек кода, проблем у вас ограниченное количество. Экономисты эффективно пользуются законом Парето, который говорит о том, что 20% усилий можно добиться 80% результата.

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

Как показывает практика, основных проблемных мест от двух до четырех. Основная цель – их найти.

Четвертая особенность проектов по оптимизации производительности

Четвертая особенность заключается в том, что объективных данных недостаточно – некоторые данные могут быть получены только от пользователей. А субъективное мнение пользователей не всегда соответствует реальному положению дел.



У вас есть объективные результаты – количество ошибок, длительности проведения и прочее.А еще есть пользователи, - которые, под влиянием множества факторов могут давать неправильную оценку, искажать ситуацию своим субъективным мнением.

Опять же – вернемся к медицине. Человек приходит на прием. Перед тем, как отправить пациента на комплексное обследование, врач просит его заполнить анкету, в которой много-много вопросов и симптомов, по каждому из которых нужно дать ответ в виде оценки по 10-бальной шкале (болевые ощущения, крепкий сон, проблемы с пищеварением и пр.). Оценив ответы пациента, врач направляет его на сдачу анализов. И теперь – уже видна комплексная картина – анализы человека в качестсве объективной оценки болезни и собственная субъективная оценка ситуации самим пациентом. Комплексно оценив картину, врач назначает лечение. И уже после лечения опять просит пациента заполнить всю ту же анкету. Даже если пациент опять напишет, что все у него так же плохо, как и было раньше, на психологическом уровне коэффициенты все-таки уже будут смещены в положительную или в отрицательную сторону.Поэтому важно составить объективную картину происходящих событий.

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

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

Первое требование к ведению проекта по оптимизации производительности системы

            Первое требование – это непрерывный качественный мониторинг. За этими простыми словами скрывается очень большой смысл.



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

            Конечно, исправлять надо и то и другое – но все-таки важна определенность. Нужно использовать это требование и собрать максимальное количество знаний, чтобы потом можно было вернуться к истории и посмотреть - а что творилось в этот момент.

Второе требование к ведению проекта по оптимизации производительности системы

            Второе требование – это StepbyStep «Шаг за шагом» в реализации проекта.


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

            Почему? Потому что система – это сложный организм, при полном решении первой все остальные проблемы (вторые и последующие) перераспределяются.

            Вам нет смысла оптимизировать все строчки, потому что, возможно, после первой итерации они сами уйдут из проблемных. Эту сложность параллельной работы надо учитывать.

Третье требование к ведению проекта по оптимизации производительности системы

            Третье требование – вы должны принять тот факт, что нахождение первопричины может занять гораздо больше времени, чем ее исправление.



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

Четвертое требование к ведению проекта по оптимизации производительности системы

Четвертое требование – касается аргументации.



Мы должны взять себе за правило, что по всем своим решениям – будь то «Переключатель установить в состояние», а «Этот флажок установить в это состояние» - касательно настроек MSSQL, Windows, 1C… - вы должны четко знать, что к этой рекомендации для вашей системе были предпосылки от таких-то данных.

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

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

Пятое – это даже не требование. Это необходимость.



Особенность этого требования-необходимости:в начале проекта оптимизации вы должны определить свои главные цели (ваш планируемый результат) - нельзя вступать в проект и делать «Оптимизацию ради оптимизации». В общем-то, если вы не видите четких критериев, что улучшиться -  вы ввязываетесь в очень тяжелое дело.

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

Видитепериодические всплески на втором графике. Этот график – длительность ваших операций. Особенно по второму графику, очевидно, что длительность определенных операций может увеличиваться в разы (в пять, в шесть раз). Периодичность таких увеличений совпадает. У вас есть объективные данные, для того, чтобы посмотреть внимательно, что происходит в это время. Возможно, это какие-то фоновые административные задачи, а возможно, какие-то еще операции.

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

Есть несколько направлений оптимизации производительности:

·         Оптимизация блокировочного механизма

·         Оптимизация конфигурации

 

Предпосылки к оптимизации блокировочного механизма

            Рассмотрим предпосылки к оптимизации блокировочного механизма.




Основной принцип должен быть такой –если у вас в системе есть ОШИБКА НА БЛОКИРОВКАХ и увеличение по сравнению с однопользовательским режимом длительности выполнения транзакций, например, проведения документов, В УСЛОВИЯХ НЕДОЗАГРУЖЕННОСТИ АППАРАТНЫХ РЕСУРСОВ –тов этом случае у вас есть полные предпосылки к оптимизации блокировочного механизма.

            У вас может возникнуть резонный вопрос -  а что значит «недозагруженность»? Дело в том, что в условиях полной загрузки оборудования становится, очевидно, что, скорее всего именно перегрузка оборудования является причиной того, что у вас повышен уровень блокировок. А вот уже недозагруженность говорит о том, что ресурсы свободны и ничего не мешает транзакциям выполняться максимально быстро. Следовательно – есть блокировки, мешающие параллельной работе.

            Вопрос аудитории - а если нет ошибокна блокировках? – к чему это может быть предпосылкой? Тут надо проверять глубже. Если есть ошибки, значит, сработали «таймауты». Возможно, ваши длительности просто не достигли «таймаута». Вам надо посмотреть, собрать более полную информацию из SQL, из 1С в виде технологического журнала (если это управляемые блокировки) и посмотреть, естьли вообще событие ожидания.

Предпосылки к оптимизации конфигурации 1С

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



В общем-то, ничего, кроме большой длительности выполнения операций в 1С и не является предпосылкой к тому, чтобы оптимизировать конфигурацию 1С.Единственное – выполнять оптимизация следует после правильной настройки оборудования и ПО.

Предпосылки к оптимизации конфигурации 1С посредством параллельных вычислений

            Какие еще могут быть предпосылки к оптимизации? Например, предпосылки к оптимизации посредством параллельных вычислений.



Это длительность операций в 1С. Недозагруженность аппаратных ресурсов. И в операции есть набор «независимых» действий друг от друга (ничего независимого в нашей жизни, к сожалению, нет)- просто эти действия мы можем как-то логически выполнять независимо друг от друга, для того, чтобы выполнять эти действия в разных потоках. Потом результат объединить.

Инструмент, применяющийся в проектах по оптимизации производительности.

            Теперь - самое интересное. Что же нам позволяет соблюдать все требования при ведении проектов по оптимизации?



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

            Это система – не часть системы 1С, она внешний наблюдатель, «бортовой самописец» вашей информационной системы.

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

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



На этом слайде видно, какие строки кода 1С вызвали проблемы, и можем привлечь все свои ресурсы 1С на эти пять строчек, которые занимают 70% ресурсов по CPU и более 70% по диску. Вы сразу видите, как каждая строчка вашего кода влияет на работоспособность MSSQL и это измерение конкретных ресурсов CPU и конкретных величин логического чтения с диска. Вы понимаете, что от этого зависит и эффективность кэша и дисковая нагрузка.

Инструмент для анализа и воспроизведения запросов 1С

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




Инструмент для анализа серверных вызовов (замера трафика между тонким клиентом и сервером приложений)

            В планах – в нашем сервисе развивать инструмент для тонких клиентов, который создан для того, чтобы было можно оценить влияние клиент-серверного взаимодействия между тонким клиентом и сервером приложений. У разработчиков уже есть рекомендации относительного того, как надо правильно писать код при работе с тонким клиентом. Но – тем не менее, есть ряд рабочих систем, где код написан без учета этих рекомендаций. То есть – там используется слишком много клиент-серверных вызовов и это делает невозможным параллельную быструю работу тонких клиентов (к тому же, это сложно отлаживается). Этот комплекс помогает замерять трафик между тонким клиентом и сервером приложений. Замеряет длительности, устанавливает, была ли это синхронизация данных и т.д.



Механизм работы сервиса

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



Какие это дает возможности?

Во-первых, эта ВК это делает очень быстро. Практически не нагружая систему (нагрузка составляет порядка 2-3%). Самое главное- эта информация приходит от клиента – это реальный отклик системы. Это очень важно.

            Более того, система перехватывает все ошибки, которые были у пользователя, в том числе и синтаксические и ретранслирует их в мониторинг для того, чтобы вы ПРОактивно действовали в вопросе некорректной работы и кода ошибок у пользователей.

           

Административные возможности

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



 

Применение сервиса мониторинга производительности на практике

Хотелось бы показать на практике, как можно использовать сервис мониторинга производительности. Перед нами стоит простой пример – но достаточно показательный. Цель – показать один из способов анализа и решения проблем производительности.

            Пользователи жалуются на «торможение» в программе.



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



Здесь важно помнить следующую вещь: кому вы хотите сделать лучше – диску или пользователю? Вероятней всего пользователю...

            Вы ведь не проанализировали, а почему диск у вас тормозит. Вы «априори» заявили, что у вас все правильно и диск – это самое узкое место. На самом деле это не совсем так, а точнее совсем не так. Для того чтобы узнать причину, почему диск тормозит, вы как раз и можете использовать данные мониторинга производительности. Здесь наглядно видны преимущества графического представления данных о нагрузке на систему.



Вы видите графики, которые расположены друг под другом. Эти графики могут быть собраны с абсолютно разных машин. С помощью линейки, которую вы можете двигать по экрану, вы можете смотреть корреляцию (зависимость графиков). И вы получаете результат – оказывается, что график «Ожидаемый срок жизни страницы памяти», который описывает прогнозируемое время, которое страница данных задерживается в кэше MSSQL, зависит от графика «Очередь к диску», а именно в момент, когда происходит провал графика «Ожидаемый срок жизни страницы памяти» значительно увеличилась очередь к диску. Вы нашли причину того, почему у вас тормозит диск – «сбрасывание кеша».

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

            Какой вывод надо делать в этой ситуации:



Находится второй умелец, который говорит - а давайте мы увеличим память. А что такого? Раз кэш проседает, значит, памяти не хватает.

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

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



Наилучшее решение – проанализировать ситуацию с вытеснением данных из кеша: что на это повлияло – какие процессы, какие запросы повлияли на то, что кэш памяти упал – для этого нам опять пригодится сервис мониторинга производительности. Обратившись к его данным, мы можем увидеть трассировку запросов SQL в этот момент. Анализ запросов даст ответ, которые из них явились причиной падения показателя «Ожидаемый срок жизни страницы памяти».

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



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