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

Публикация № 333695

Администрирование - Производительность и оптимизация (HighLoad)

оптимизация производительности оптимизация ИТ систем мониторинг производительности торможение системы зависание системы

51
Наша компания более 7 лет занимается разработкой и оптимизацией систем на базе 1С:Предприятие. Кроме этого, мы занимаемся разработкой технологии обмена между базами данных 1С:Предприятие в режиме online, различными интеграционными решениями, кластерными технологиями, масштабированием систем и параллельными вычислениями. За истекший период мы внедрили более 400 успешных проектов по производительности, из них более 100 для систем 1С:Предприятие версий 8.1 и 8.2. Чтобы вы понимали масштабы информационных систем, приведу ее показатели: количество пользователей – до 1500 в одной базе данных и по размеру БД – это более 2 Терабайт Соответственно, за это время, шаг за шагом мы получали новые данные, эволюционировали свои технологии, и пришли к некоторым результатам, с которыми хотим вас ознакомить. Статья написана по итогам доклада, прочитанного автором на Конференции IE 2012 15-16 ноября 2012 года. Также она напечатана в Журнале Инфостарта №1.

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

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

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

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

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

    Вторая группа - это проблемы непостоянные и непредсказуемые. Наверняка, вы тоже отчасти с этим сталкивались, но, возможно, представляли совсем другую их природу. Это могут быть проблемы, которые неожиданно появляются. Например, это падение на каком-нибудь узле – пользователя, сервера приложений или торможение системы в определенный момент. В общем-то, причинами этого всего может быть что угодно, в том числе выполнение регламентного задания, которое приводит к сбою или вызывает общее торможение ИС в момент своей работы. А может быть – банальная халатность персонала. Для таких проблем обычно должна использоваться другая методика решения и обнаружить их можно только при многопользовательском режиме работы.

    Третья группа – это проблемы предсказуемые, но сложно решаемые, я специально выделил их в особую группу. О них частично упоминал Алексей Лустин в своем докладе. Вы понимаете, что никакими средствами 1С не решить определенные задачи (для примера возьмем проведение больших регламентных документов, восстановление последовательностей, которое не укладывается у вас в определенное время). Соответственно, вы понимаете, что эти проблемы есть, вы понимаете, что их надо решать, но не понимаете, как это сделать. Для решения подобных задач используется ряд технологий, такие как параллельные вычисления, распределенные дисковые хранилища и пр.

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

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

 

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

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

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

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

Интересно обсудить отличие проектов оптимизации, от автоматизации.Есть несколько специфичных особенностей проектов производительности, которые надо учитывать:

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

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

Другими словами, объясним "на пальцах" посредством аналогии из медицины: если человек испытывает сильную боль, то более слабая боль отходит на второй план – человек ее даже не чувствует. Это обстоятельство всегда надо учитывать, и не заблуждаться на счет того, что проблемы все находятся на поверхности. Не факт, что очевидные для вас причины текущих проблем производительности являются единственными.

 

 

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

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

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

 

 

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

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

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

Как показывает практика, проблемных мест ограниченное количество (3-5 ). Основная цель – их найти.

 

 

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

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

 

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

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

 

 

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

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

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

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

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

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

 

 

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

Второе требование – это Step by Step

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

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

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

 

 

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

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

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

 

 

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

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

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

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

 

 

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

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

 

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

 

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

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

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

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

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

 Когда вам звонит пользователь – это уже Реакция на событие.

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

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

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

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

У вас тормозит диск, и пользователи жалуются на «торможение».

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

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

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

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

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

  

Соответственно, что надо делать в этой ситуации:

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

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

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

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

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

Выводы

"Не важно кто ударит по гвоздю, важнее кто покажет куда бить". Аналогично с оптимизацией: намного сложнее найти первопричину, чем ее устранить. 

  

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

Теперь – самое интересное. Я хочу рассказать вам о нашей новинке.

 В этом году нам удалось очень сильно продвинуться в плане горизонтального масштабирования серверов баз данных SQL Server.

 Фирма 1С разработала кластер сервера приложений. Этот кластер позволяет масштабировать нагрузку на второе звено трехзвенной архитектуры. Вы знаете, что терминалы давно масштабировались, с этим не было проблем. Были проблемы с масштабированием сервера MS SQL.

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

Более того, это может делаться в несколько режимов. Первый режим, который полностью работоспособен, работает по технологии Always on – технологии, которая появилась в MS SQL 2012 (технологии синхронной репликации). При работе в этом режиме, эти три узла синхронно обновляются в рамках транзакций. Единственное ограничение – у нас не может быть больше четырех узлов.

****************

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.

51

Скачать файлы

Наименование Файл Версия Размер
Презентация
.ppt 4,08Mb
19.08.16
7
.ppt 4,08Mb 7 Скачать

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Дата
1. ivanov660 1648 11.03.15 21:43 Сейчас в теме
1. Скажите, а 1500 пользователей это вообще или одновременно работающих?
2. К сожалению, не увидел примеров решений (всего один) и много воды (до конца просматривал через три строчки). Хотелось бы почитать про вопросы в стиле "знаю-как" (симптом-анализ-решение).
2. gallam99 224 12.03.15 20:41 Сейчас в теме
(1) ivanov660,
Ответы
1. 1500 работающих и это не предел. Максимальное количество более 3000
2. В презентации и был один пример, в котором показана цепочка рассуждений. А по поводу воды ... Советую внимательнее прочитать первую часть презентации, там много ответов ... Их только надо понять.
3. finkont 18.03.15 10:53 Сейчас в теме
Добрый день!
Отличная статья, есть информация для размышления. Пользователи как раз жалуются что базы стали работать медленнее после 16 часов.
Единственное, много орфографических ошибок, поправьте, пожалуйста.
Если можно ответьте на вопрос: есть несколько десятков небольших баз, до 2 Гб , фирма зарабатывает аутсорсингом бухгалтерии. Базы типовые. Я отключил через консоль сервера 1С выполнение регламентных заданий почти на всех базах, т.к., на мой взгляд, там много лишних. Никто не жаловался что возникли какие-то проблемы. Ранее процессоры были загружены под 90 процентов, очередь диска доходила до 15. Сейчас процессоры редко до 50 загружены, очередь диска не увеличивается больше 2. Но быстродействие, со слов пользователей, не улучшилось. Есть еще одна проблема, почти полностью занята вся оперативная память, т.к. на сервере одновременно работает SQL и сервер 1С. В эти выходные планирую перенести часть баз на другой физический сервер с SQL. Предполагаю что это поможет освободить ОП и быстродействие улучшится.
Собственно сам вопрос: насколько действенно отключение регламентных заданий на типовых базах и может ли это привести к проблемам? Может еще что-то вкратце посоветуете или скажете что сделал неправильно.
Спасибо!
4. gallam99 224 18.03.15 11:07 Сейчас в теме
(3) finkont,
Несколько вопросов:
1. Какой функционал в регламентах отключенных был?
2. Есть ли средства объективного контроля параметров производительности (пример, логирование длительности основных операций - проведение документов, отчетов и прочее)? Как один из способов - внедрение в код 1С замеров и сохранение, например, в регистр сведений.

От пользователей не всегда объективная информация.
По поводу памяти - статья http://infostart.ru/public/336003/ - случай с отсутствием свободной физической памяти.
Решается он не переносом БД, а скорее переносом роли сервера приложения 1С на другой физический сервер. Проблема совмещения ролей сервера БД и сервера приложения состоит в том, что ограничивать память, потребляемую сервером приложения мы не можем и он, таким образом, съедает всю свободную (а это подробнее описывается в статье выше).

По ошибкам попрошу копирайтеров проверить, текст настолько знаком, что сам ошибок не вижу)))

5. finkont 18.03.15 11:39 Сейчас в теме
(4)
1. Всего порядка 35, некоторые каждые 60 секунд, например, ПланированиеОбработкиЗаданий. ПерестроениеАгрегатов - раз в неделю, в субботу.Подозреваю, что есть задания, которые было бы лучше не отключать, но пройти порядка 100 баз, и выбирать что отключать, что нет, на это уйдет 2-3 дня.
2. Такого нет.

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

По поводу использования ОП рабочими процессами 1С, недавно прочитал статью про их перезапуск при превышении прописанного объема памяти, https://helpf.pro/faq8/view/1502.html. Правда пока не решился это использовать, т.к. надо сначала протестировать как будет работать, а тестовой среды нет. А вообще жаль, что 1С пока не сделала настроек подобно SQL, чтобы можно было ограничить используемый объем ОП.

В любом случае, спасибо за статью и остальную информацию. Буду продолжать смелые эксперименты. Если получится, о результатах отпишусь.
6. kosmo0 81 18.03.15 12:33 Сейчас в теме
Теперь – самое интересное. Что же нам позволяет соблюдать все требования при ведении проектов по оптимизации?
Нам это позволяет система мониторинга PerfExpert, которая первоначально была разработана специально для внутренних нужд (сейчас это уже коммерческий продукт).
- вот ключевая часть статьи. По большому счету эта статья является презентацией. Общие рассуждения плюс один, более-менее, подробный разбор конкретного случая.

Вы ждете от статьи конкретных алгоритмов оптимизации производительности? Хм.
7. dancer 5 18.03.15 12:45 Сейчас в теме
Копирайтеру двойка по русскому. Писать на тему ИТ и не знать, что терабайт - не от Терры, а от тера (τέρας - чудовище), - это моветон и, повторюсь, двойка по русскому.
9. gallam99 224 18.03.15 13:59 Сейчас в теме
(6) kosmo0,
целью материала и было освещение общих вопросов (но это не значит, что они неважные).
По поводу средства мониторинга - можно подобрать любой инструмент, который удовлетворяет требованиям к ведению проектов по оптимизации, мы предлагаем PerfExpert.
Один пример показан для наглядной демонстрации поиска первопричины (это чтобы теория вначале была подкреплена практикой в конце).

Конкретных алгоритмов оптимизации - их очень много, описывается в различных других статьях (и описать все невозможно).

10. logarifm 1054 25.03.15 11:38 Сейчас в теме
В итоге статья - это Реклама. что у нас есть штучка которой мы умеем делать что-то... А по сути решений никаких эта статься не несет в себе.
Henistaromin; uralev; Silenser; +3 Ответить
11. Velifer 02.06.15 12:10 Сейчас в теме
(1) ivanov660,

Вот здесь я делал проект на 5000 пользователей в единой базе.
Хотя всего соединений с одним класером 1С получилось почти 10 тыс

http://www.youtube.com/watch?v=0KN5DdkbS2g
Оставьте свое сообщение

См. также

Мониторинг количества использованных программных лицензий, выданных выделенным сервером лицензирования 8

Инструменты и обработки Системный администратор Архив с данными v8 Linux Абонемент ($m) Zabbix

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

1 стартмани

22.11.2019    803    Sloth    0       

Подборка решений для взаимодействия со ФГИС «Меркурий» Промо

С 1 июля 2019 года все компании, участвующие в обороте товаров животного происхождения, должны перейти на электронную ветеринарную сертификацию (ЭВС) через ФГИС «Меркурий». Инфостарт предлагает подборку программ, связанных с этим изменением.

Быстрая реструктуризация базы данных 36

Инструменты и обработки Системный администратор Программист Внешняя обработка (ert,epf) v8 v8::УФ 1cv8.cf Россия Windows Абонемент ($m) Производительность и оптимизация (HighLoad) Конфигурирование 1С

Внешняя обработка для быстрой реструктуризации клиент-серверной базы данных. Способ ускорения реструктуризации - замена таблиц большого объема пустыми копиями перед проведением обновления БД и возврат к исходным таблицам после обновления с предварительной корректировкой их структуры. Полностью автоматизировано создание и выполнение всех требуемых скриптов SQL. Представлены версии обработки для обычных форм (1С:Предприятие 8.2 (8.2.19.130)) и управляемого приложения (1С:Предприятие 8.3 (8.3.9.1818)).

1 стартмани

05.11.2019    5609    18    dmitrydemenew    34       

Влияние БСП на производительность базы 1С с добавленными метаданными 6

Инструменты и обработки Программист Расширение (cfe) v8 УТ11 Абонемент ($m) Производительность и оптимизация (HighLoad) Адаптация типовых решений БСП (Библиотека стандартных подсистем)

Повод для статьи — заметное снижение быстродействия при переводе учета с УТ 11.1 на 11.4 по «нашим» не стандартным метаданным (регламенты работы с массовым заполнением/проведением документов/регистров). Предварительно причину увидел во влиянии БСП. Была создана тестовая подсистема, быстродействие которой оцениваем в демобазе "Управление торговлей". С включенными и выключенными подписками БСП.

5 стартмани

04.11.2019    1712    2    VsHome    1       

Новый раздел на Инфостарте - Electronic Software Distribution Промо

Инфостарт напоминает: на нашем сайте можно купить не только ПО, связанное с 1С. В нашем арсенале – ESD-лицензии на ПО от ведущих вендоров: Microsoft, Kaspersky, ESET, Dr.Web, Аскон и другие.

  • Низкие цены, без скрытых платежей и наценок
  • Оперативная отгрузка
  • Возможность оплаты с личного счета (кешбек, обмен стартмани на рубли и т.п.)
  • Покупки идут в накопления для получения скидочных карт лояльности Silver (5%) и Gold (10%)

Кто круче: "ИЛИ" или "ОБЪЕДИНИТЬ ВСЕ" в запросе? 14

Статья Программист Внешний отчет (ert,erf) v8 v8::СПР v8::Запросы ЗУП2.5 MySQL Абонемент ($m) Производительность и оптимизация (HighLoad)

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

1 стартмани

14.09.2019    2474    azazana    27       

Оптимизация прав ролей 17

Инструменты и обработки Системный администратор Программист Внешняя обработка (ert,epf) v8::УФ v8::Права 1cv8.cf Россия Windows Абонемент ($m) Производительность и оптимизация (HighLoad) Роли и права

Решение вопроса по неоптимальной настройке (избыточной) ролей, влияющей на производительность системы (потребление оперативной памяти). Алгоритм работы следующий: Выгрузка конфигурации в файлы - Обработка (изменение) файлов прав ролей - Загрузка измененных прав в конфигурацию. Проверено на платформе начиная с 8.3.12.

1 стартмани

09.09.2019    2919    2    toxilamer    11       

Подборка программ для взаимодействия с ЕГАИС Промо

ЕГАИС (Единая государственная автоматизированная информационная система) - автоматизированная система, предназначенная для государственного контроля за объёмом производства и оборота этилового спирта, алкогольной и спиртосодержащей продукции. Инфостарт рекомендует подборку проверенных решений для взаимодействия с системой.

Еще один тест 1C: Postgres SQL 11 Pro Enterpise против MSSQL 14 под Windows 2012 Server R2 14

Статья Системный администратор Архив с данными v8 Windows Абонемент ($m) Производительность и оптимизация (HighLoad)

Проработав 15 лет с MSSQL в 2017 начал активно СУБД Postgres SQL. За два года успел поработать в 9 версии Postgres и в 10-ой. И пришел к выводу, что существуют реальное замедление работы баз после перехода на Postgres. Недавно вышла 11 версия Postgres Pro Enterpise, которая обещает почти 2-х кратное ускорение над 11 Pro Standart и 10-ой версией. Закупив лицензию Postgres 11 Pro Enterpise Это я и решил проверить на 1С.

1 стартмани

05.09.2019    5986    9    ogidni    84       

Онлайн-интенсив "Бизнес-процессы для подготовки к экзамену 1С:Специалист по платформе" 12 декабря 2019 г. Промо

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

777 рублей

Менеджер потоков: реализация "любой" задачи в потоках 51

Статья Программист Нет файла v8 Абонемент ($m) Производительность и оптимизация (HighLoad)

Менеджер потоков – один их новых инструментов, который упрощает работу разработчиков. Насколько легко с ним, на конференции Infostart Event 2018 Education показал начальник отдела автоматизации 1С Иван Филимонов компании «Трансстроймеханизация».

01.08.2019    5090    18    DarkAn    6       

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

Ловец дедлоков СУБД 46

Статья Системный администратор Программист Архив с данными v8 Россия MS SQL Абонемент ($m) Производительность и оптимизация (HighLoad) Практика программирования Разработка

Анализ простейшего дедлока СУБД в рабочей базе с использованием ЦУП (центра управления производительностью) и profiler MS SQL (Microsoft SQL Server). Эта статья будет полезна людям, изучающим вопросы оптимизации работы 1С, или тем, у кого возникают дедлоки в рабочей базе. UPD 09.07.2019 добавлено воспроизведение блокировки в случае установки управляемой блокировки перед чтением набора записей регистра сведений. UPD 10.07.2019 добавлена тестовая база с примером.

1 стартмани

08.07.2019    6940    2    azazana    79       

Мониторинг производительности и искусственный интеллект 38

Статья Программист Конфигурация (md, cf) v8 Абонемент ($m) Производительность и оптимизация (HighLoad) Практика программирования Разработка

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

1 стартмани

01.07.2019    5051    3    ivanov660    28       

Перенос данных УТ 10.3 => УТ 11 / КА 2 / ERP 2 (ЕРП 2) (документы, остатки и справочная информация из "1С:Управление торговлей, ред. 10.3" в УТ 11 / КА 2 / ERP 2). Обновлен до УТ 10.3.56.х, УТ 11.4.10.х, КА 2.4.10.х и ERP 2.4.10.х! Промо

Уже более 100 компаний приобрели перенос и выполнили переход на УТ 11 / КА 2 / ERP 2 с помощью нашей разработки! Обработка перехода с УТ 10.3 на УТ 11 / КА 2 / ERP 2 позволяет перенести не только остатки на указанную дату (как типовой перенос), но и все возможные документы за выбранный период. При выходе новых релизов этих программ оперативно выпускаем обновление обработки. Предоставляем техническую поддержку. Можем сделать бесплатный тестовый перенос!

29700 руб.

Взаимодействие при редактировании одних и тех же данных [Расширение] УТ11 6

Инструменты и обработки Системный администратор Программист Расширение (cfe) v8 УТ11 Россия Абонемент ($m) Производительность и оптимизация (HighLoad)

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

2 стартмани

14.04.2019    2348    2    noprogrammer    0       

С 2020 года сервис «Продление поддержки конфигурации 1С:УПП» подорожает вдвое Промо

Успейте продлить поддержку УПП до повышения цен! Фирма «1С» предупредила об изменении цен на сервис «Продление поддержки конфигурации "1С:Управление производственным предприятием"». С 1 января 2020 года сервис подорожает в два раза.

Методика оптимизации программного кода 1С: проведение документов 85

Инструменты и обработки Программист Архив с данными v8 v8::УФ Абонемент ($m) Обработка документов Производительность и оптимизация (HighLoad) Инструментарий разработчика

Описание простого метода анализа производительности программного кода 1С, способов его оптимизации и оценки результатов в виде числовых показателей прироста производительности. Не требует сторонних программных продуктов, используются только типовые возможности платформ 1С. Методика проверена на линейке платформ начиная с 1С:Предприятие 8.2 (обычные формы, управляемые формы). Позволяет ускорить проведение проблемных документов в 3 и более раз, провести проверку корректности формирования проводок оптимизированным кодом и подтвердить результаты оптимизации реальными замерами производительности в режиме предприятия. К публикации приложены демонстрационные базы для режимов обычного и управляемого приложения на платформе 1С:Предприятие 8.3 (8.3.9.2033).

1 стартмани

19.03.2019    15481    14    dmitrydemenew    83       

Перенос документов и справочников ERP 2 / КА 2 / УТ 11 => БП 3.0 Промо

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

19700 руб.

Исправление ЦУП 2.1.2 1

Инструменты и обработки Системный администратор Программист Расширение (cfe) v8 1cv8.cf Windows Абонемент ($m) Производительность и оптимизация (HighLoad)

Расширение для конфигурации Центр управления производительностью, редакция 2.1 (2.1.2.11), которое позволяет настроить регламентный мониторинг. Работает на платформе 1С:Предприятие 8.3 (8.3.13.1644).

2 стартмани

21.01.2019    2722    5    Neco    0       

Многопоточное тестирование производительности по методике APDEX (управляемые формы) 12

Инструменты и обработки Системный администратор Программист Внешняя обработка (ert,epf) v8 1cv8.cf Windows Абонемент ($m) Производительность и оптимизация (HighLoad)

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

10 стартмани

09.01.2019    4779    8    capitan    24       

Перенос документов, остатков и справочников КА 1.1 => КА 2 / УТ 11. Обновлено до КА 2.4.10.х и УТ 11.4.10.х! Промо

Более 130 компаний выполнили переход на КА 2 или УТ 11 с помощью нашей разработки! Позволяет перенести не только остатки и справочники (как типовая обработка), но и документы за нужный период времени. Предоставляем техподдержку, оперативно исправляем замечания, выпускаем обновления при выходе новых релизов программ 1С. Вы можете проверить разработку до покупки: сделаем бесплатный тестовый перенос из вашей базы КА 1.1 и предоставим доступ к базе-результату через веб-клиент!

29700 руб.

Решение проблемы быстродействия в ERP на рабочем примере 59

Инструменты и обработки Программист Конфигурация (md, cf) v8 ERP2 Абонемент ($m) Производительность и оптимизация (HighLoad)

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

3 стартмани

18.12.2018    9050    46    ivanov660    8       

Короткое нагрузочное тестирование PostgreSQL простыми запросами 25

Статья Системный администратор Программист Архив с данными v8::УФ Windows Абонемент ($m) Производительность и оптимизация (HighLoad)

Короткое нагрузочное тестирование PostgreSQL простыми запросами. Прилагаются результаты в файлах pgBadger и perfmon.

1 стартмани

10.12.2018    7207    1    vasilev2015    22       

Очный семинар по регулярному менеджменту Александра Фридмана "Вы или Хаос", 12 декабря 2019 г. , Санкт-Петербург Промо

Семинар по регулярному менеджменту от Александра Фридмана для собственников, первых лиц и топов. Технология управленческого планирования, комплексного управления временем и другими ресурсами, выполнением поручений, делами, информацией, контактами (встречи-звонки-почта).

от 11000 до 29000 рублей

PostgreSQL для 1С 8.3: ускоряем резервное копирование и восстановление для отдельной базы очень большого размера 112

Статья Системный администратор Программист Архив с данными v8 1cv8.cf Россия PostgreSQL Абонемент ($m) Производительность и оптимизация (HighLoad) Тестирование и исправление

В этой статье разберем оптимизацию работы с моментальным снимком отдельной базы 1С в кластере PostgreSQL средствами pg_dump.exe, pg_restore.exe, psql.exe в среде Windows Server 2008,2012,2016. А также разберем проблемные ситуации и неожиданные ограничения при работе 1С в связке с PostgreSQL. Для Linux все аналогично.

1 стартмани

03.12.2018    17897    30    vsasav    68       

Многопоточная обработка данных 47

Инструменты и обработки Системный администратор Программист Конфигурация (md, cf) v8 v8::УФ 1cv8.cf Абонемент ($m) Производительность и оптимизация (HighLoad) Администрирование данных 1С

Конфигурация "Универсальные механизмы: пакеты данных". Набор инструментов для быстрой организации отказоустойчивой многопоточной обработки данных.

1 стартмани

23.11.2018    12195    46    _ASZ_    14       

Перенос данных КА 1.1 / УПП 1.3 => БП 3.0 (перенос остатков, документов и справочников из "1С:Комплексная автоматизация 1.1" / УПП 1.3 в "1С:Бухгалтерия 3.0"). Обновлен до версий КА 1.1.115.х, УПП 1.3.127.х! Промо

Разработка позволяет перенести остатки по всем счетам бух.учета в программу "1С:Бухгалтерия предприятия 8", ред. 3.0 на выбранную дату начала ведения учета. Также переносятся документы за период и вся необходимая справочная информация. Правила оперативно обновляю при выходе новых релизов. Рассылка обновлений правил бесплатно в течение 12 месяцев. Есть видеодемонстрация проведения переноса данных. Конфигурации при использовании обмена остаются полностью типовыми. Перенос данных возможен в Бухгалтерию 3.0 версии ПРОФ, КОРП или базовую.

24700 руб.

Замер производительности. КА 2, УТ 11 1

Отчеты и формы Системный администратор Программист Внешний отчет (ert,erf) v8 УТ11 Абонемент ($m) Статистика базы данных Производительность и оптимизация (HighLoad)

Отчет позволяет замерять на актуальных базах КА2 и УТ11 (в том числе на демо-базах) три параметра: время выборки данных, время передачи с клиента на сервер, время вывода данных. Тестировал на релизах КА 2.4.1.240 и УТ 11.4.5.32.

1 стартмани

22.11.2018    4546    5    FarFar    9       

Скорость работы 1С8 файловой по сети 87

Статья Системный администратор Программист Архив с данными v8 1cv8.cf Абонемент ($m) Производительность и оптимизация (HighLoad)

Как я увеличил скорость работы файловой 1С8 по сети, изменив формат БД и размер страницы.

1 стартмани

01.11.2018    19170    11    Vlx    55       

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Мониторинг здоровья MS SQL Server 16

Инструменты и обработки Системный администратор Архив с данными MS SQL Абонемент ($m) Производительность и оптимизация (HighLoad)

Описывается очередной изобретенный "велосипед" для мониторинга здоровья MS SQL Server, который мы используем в glassdoor.com - втором крупнейшем в США сайте для соискателей работы.

1 стартмани

23.10.2018    6061    10    Aleksey.Bochkov    2       

Мониторинг показателей систем 1С 8.3 с помощью Zabbix 163

Инструменты и обработки Системный администратор Внешняя обработка (ert,epf) v8 1cv8.cf Абонемент ($m) Внешние источники данных Zabbix

Опишу свой опыт мониторинга наших систем 1С с помощью Zabbix и ту пользу, которую можно извлечить из этого.

1 стартмани

05.10.2018    23251    37    akimych    48