Повышение производительности 1С для администраторов. Оптимизация производительности 1с


Как ускорить и оптимизировать работу в 1С Предприятие

Оптимизация с помощью обновления 1С

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

Многие давно пользуются возможностью автоматически обновить программу. Хотя этот вопрос легко решается и вручную для 1с Предприятие 8.3, обновление которого не доставит хлопот.

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

В последнем случае архив с данными по обновлению скачивается отдельно. Его распаковка происходит в любой папке, которая считается наиболее удобной для пользователя. После надо запустить файл .exe. В следующем окне просто нажимаем кнопку «Далее».

Появится ещё одна страница. На ней пользователь выбирает путь, в котором установка завершается. Но этот шаг рекомендуется делать только продвинутым владельцам персонального компьютера. Функций по умолчанию обычно вполне хватает для решения большинства проблем. По умолчанию, в данном случае указана одна папка, куда устанавливаются сразу все обновления. Это гораздо удобнее, чем когда конечные пути разные. Просто несколько раз нажимаем на кнопки «Далее» в программе 1с Предприятие 8.3, обновление конфигурации которой должно проходить быстро.

Осталась только финальная кнопка, которая и предлагает «Установку».

Как ускорить работу 1С, если платформа тормозит

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

Обновление версии 7.7

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

О версии 8.0 и 8.1

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

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

Что касается версии 8.1, то до неё обновиться можно несколькими способами:

  1. вручную;
  2. в автоматическом режиме;
  3. обращение к специалистам компаний, предоставляющих услуги в данной сфере.

Работа с нетиповыми или модифицированными версиями

Первоначально любая конфигурация относится к типовым разработкам. Она перестаёт быть таковой, если на предприятии вносят определённые изменения. Например, во время установки. Есть два класса, которые выделяются у нетиповых конфигураций:

  1. изменённые;
  2. созданные с нуля, учитывающие потребности конкретного предприятия.

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

Актуальность конфигураций может поддерживаться следующими действиями:

Советы при обновлении для оптимизации 1С

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

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

Дополнительные причины торможения

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

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

Как повысить скорость и удобство работы в 1С

arprime.ru

Методика поиска причин низкой производительности сервера 1с / Хабр

Недавно столкнулся с необычным случаем, у заказчика отвратительно работал сервер 1с, чтобы было понятно о чем идет речь, приведу такой пример — запуск толстого клиента мог занимать десяток минут. Когда измерили тестом Гилева, то результат был ниже худшего. Посмотрев ближайшие результаты замеров других пользователей, я понял, что это не единственный случай. Речь не идет об оптимизации, когда надо поднять на 10-20% производительность, речь идет о поиске причин низкой производительности, и её устранению. Согласитесь это несколько разные вещи. На просторах интернета множество статей как раз о повышении производительности, которые ограничиваются только настройкой сервера 1с и (или) настройкой сервера баз данных. А вот статей, рассматривающих случаи низкой производительности, особенно если причин несколько, и эти причины находятся на разных уровнях, я не встречал. Обычно администраторы бросаются смотреть результаты мониторинга. Тот случай, с которым я столкнулся, показывал практически нулевую загрузку процессора, наличие свободной ОЗУ, отсутствие очереди у сетевого интерфейса, и только очередь к диску показывала, что не все в порядке. Пришлось устроить проверку по полной программе, это, конечно, занимает много времени, требует исключения сервера из рабочего процесса, но зато дает результат. Возможно для кого-то подобный подход недопустим, более того, некоторые считают это непрофессиональным подходом, но им я ничем помочь не смогу.
Аппаратный уровень
Звучит банально, но именно с проверки работоспособности железа стоит начать. Дело в том, что можно только догадываться о проблемах с оборудованием, если смотреть на уровне операционной системы. В моем случае, не работал один из дисков в дисковом массиве. Как ни странно жесткий диск оказался исправным и, после водворения его на место, заработал, правда пришлось подождать некоторое время, пока не синхронизируются все данные (видать давно он был отключен). Если бы всё этим и закончилось, тогда бы и не было этой статьи. На всякий случай сервер подвергся аппаратному тестированию (стресс-тесты, тест памяти, физической проверки дисков и контроллеров), которые не выявили каких-либо проблем.
Уровень операционной системы
Вторым пунктом нашей программы стала проверка и настройка операционной системы, суть которой заключается в следующем:
  1. привести в порядок файловую систему;
  2. отключить ненужные службы, удалить ненужные и, самое главное, вредоносные программы;
  3. проверить оптимальность настроек операционной системы.
Под приведением в порядок файловой системы подразумевается самые очевидные операции, которые, как это не странно выглядит, многими администраторами считаются неприменимыми к серверным операционным системам. Речь идет о:
  1. проверке логической структуры диска;
  2. удалении временных и ненужных файлов;
  3. дефрагментации файловой системы.
Справедливости ради, надо заметить, что для SSD-дисков дефргаментация действительно ничего не дает, а только увеличивает количество циклов записи. В моем случае, после приведения файловой системы в порядок сервер немного «ожил», но этого все равно было недостаточно. Я думаю, не нужно объяснять, зачем нужна антивирусная проверка и отключение неиспользуемых служб, но пренебрегать этим не стоит. Посмотрите, может были установлены какие-то программы, которые сейчас уже не нужны на этом сервере. Ну и сделайте обновление системы и программ. Что касается оптимальности настроек операционной системы, то в моем случае был выставлен экономный режим электропитания. После включения режима максимальной производительности тест Гилева показывал удовлетворительные результаты, но тот конкретный сервер должен был показывать более высокие результаты. Для выяснения причин был произведен мониторинг использования ресурсов, хотя с самого начала было понятно, что искать надо те процессы, которые много занимают дисковую подсистему. В моем случае лучшим показателем явился «Длина очереди к диску». Напомню, что остальные показатели были в норме, они конечно немного изменились по сравнению с первоначальными, но в целом индикатором так и осталась длина очереди к диску. Результаты мониторинга были очевидны: «расхитителями» ресурсов оказались процессы сервера 1С и сервера баз данных.
Уровень служб
В моем случае сервер 1с находился вместе с сервером баз данных MS SQL на одной машине, но аппаратная конфигурация сервера вполне обеспечивала их совместную деятельность, а вот настройки этих двух служб были совсем не оптимальными. Этим настройкам посвящено множество статей, например, эта, здесь мы сфокусируем внимание только на тех, что не требуют дополнительных вложений, например, приобретение жесткого диска. Для сервера MS SQL в каждой базе были увеличены значения параметра авторасширения базы до 500 Мб, так как базы 1С являются быстрорастущими. Также был настроен ежедневный план обслуживания, в котором кроме создания дампа базы добавлено обновление статистики, очистка процедурного кэша и дефрагментация индексов. В моем случае, это заметно уменьшило количество операций записи. В качестве дополнительных мер можно порекомендовать еженедельно производить дефрагментацию базы и реорганизации индексов. Для сервера 1С были изменены параметры «Количество ИБ на процесс» и «Количество соединений на процесс» рабочего сервера, первый получил значение 1, а второй 25. Подобные советы больше похожи на «танцы с бубном», но они дают результат. В рассматриваемом случае изменение этих параметров привело к значительному уменьшению операций чтения-записи на сервере, и он заработал в ожидаемом режиме. Тест Гилева также подтвердил прирост производительности.
Уровень баз
Сделав замеры под рабочей нагрузкой и после выхода пользователей, я столкнулся со странным результатом — под нагрузкой тест Гилева показывал лучшие результаты, чем при простое! Было также замечено огромное количество фоновых заданий выполняемых на тестовых базах. Тестовые базы использовались сисадминами для проведения различных тестовых задач. Я попросил удалить их — и все встало на свои места. Следует ли держать тестовые базы на рабочем сервере, решать конечно вам, но лучше для этого найти какое-то другое решение, например, использовать файловый вариант. У одной из баз не удавалось уменьшить журнал транзакций, а у другой базы не пересоздавались индексы. Для обоих случаев есть одно простое и эффективное решение. Прежде чем его описать, следует уточнить, что здесь имеет место одинаковое наименование разных объектов: базы 1С и базы MS SQL, первые могут быть не базами MS SQL, а, например, базами PostgreSQL. В свою очередь вторые не обязательно будут базами для 1С. Исходя из этого резервные копии баз 1С (dt-файл) могут быть развернуты и на других СУБД, но ни кто не запрещает вам из этой же копии развернуть на MS SQL. Снимаем резервные копии баз 1С средствами 1С, после чего удалить 1С-базы из сервера 1С, а потом создать их вновь, залив содержимое из dt-файла. Приведя все базы в порядок, мне уже не к чему было придраться: сервер работал ровно, дисковая подсистема работала в штатном режиме, пользователи радовались быстрой работе в 1с, администраторы удивлялись как теперь быстро проходят обновления.
Заключение
Если использовать только один уровень для поиска причин низкой производительности, то можно оставить без внимания причины, лежащие на других уровнях, то есть результат будет не достигнут. Приведенный пример наглядно показывает, что причин может быть несколько, и каждая из них может лежать на своем уровне. Надеюсь, что данный материал поможет кому-то побороть проблему низкой производительности 1С-сервера.

habr.com

производительность | Gilev.ru | Ускоряем 1С:Предприятие

Поговорим о виртуализации.

Последние несколько лет стала очень широко использоваться виртуализация, администраторы очень быстро увидели плюсы для себя: очень удобно работать с такой машиной, легко переносить её между несколькими физическими серверами, можно настроить отказоустойчивую схему, когда одну виртуальную машину могут обслуживать более одного физического сервера. Кроме того, виртуалка перезагружается на порядок быстрее. Кто не знает, приличный физический сервер может спокойно перезагружаться по 10-15 минут: пока всё потушит, пока сразу после старта неспешно всё у себя проверит, затем даст возможность контроллерам дисковых накопителей потестировать себя и диски всласть, и только после этого начинает грузить операционную систему. Виртуальный же сервер все проверки проскакивает за секунды, с точки зрения железа это всего лишь обычная программа. А для руководства компании мощнейший плюс виртуализации состоит ещё и в том, что можно взять например десять устаревших серверов, и запихнуть их функции на один физический, получается серьёзная экономия что на модернизации оборудования как такового, что на площади серверной комнаты, что на электричестве, нужном для работы и охлаждения сервера. Или можно арендовать в дата-центре вместо десяти слабеньких серверов один сильненький за меньшие суммарно деньги. К тому же, если например раньше вам потребовалось бы увеличить в два раза мощность двух из этих десяти серверов, это могло повлечь за собой необходимость апгрейда этих серверов. А в виртуальной системе достаточно изменить настройки выделения ресурсов. Ну и если вдруг мощности конкретного хост-сервера перестало хватать, можно вынести отдельные виртуалки на другой сервер, причём в некоторых случаях можно их даже не выключать.

Ну то есть замечательная технология. А есть ли у неё минусы? К сожалению, есть.

Главный и основополагающий для нас минус — это снижение производительности (по нашим данным, вендоры сообщают о замедлении относительно физических серверов от 9 до 24%). Причём снижение это идёт сразу по нескольким уровням. Во-первых, что бы там ни рассказывали производители процессоров и виртуальных сред, технология виртуализации сама по себе предполагает выполнение команд не в оригинальной среде, а в её имитации, которая называется эмуляцией. Эмуляция по ресурсам совсем не бесплатна, она отнимает в лучшем случае несколько процентов производительности по сравнению с исполнением того же кода на этом же оборудовании, но без виртуальной среды.

Во-вторых, свои штрафы накладывает эмуляция сетевых интерфейсов и эмуляция сетевых дисков, которые тоже отнимают каждая свои процентики.

Что делает уважающий себя администратор, дорвавшийся до виртуалок? Он берёт старый сервер, где крутились одновременно сервер 1С и сервер СУБД, и раскладывает роль сервера 1С в одну виртуалку, а роль сервера СУБД в другую. С точки зрения отказоустойчивости и балансировки нагрузки — он большой молодец. Такую схему разносить по нескольким физическим серверам проще, распределить нагрузку по незагруженным серверам например.

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

Почему? Например, потому что раньше сервер 1С и сервер СУБД внутри одной операционной системы общались между собой по протоколу Shared Memory, и это было очень быстро. А теперь используют сетевой интерфейс, а даже внутри одного сервера виртуализация сети- задача по ресурсам совсем не бесплатная.

А кроме того, есть ещё и неудобные для 1С сочетания факторов, вот как на снимке: использование сетевого интерфейса WMXNET3 практически гарантирует узкое место на передаче данных 1С по сети.

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

Мы же выделим один наиболее значимый. Теперь кроме всех прочих факторов, добавляется ещё один, совершенно непредсказуемый для виртуальной машины: на этом же железе может исполняться неизвестное количество других виртуальных машин, нагрузка которых может колебаться от условного 0 до 100%. Благодаря этому можно наблюдать например такую картину: сидит один пользователь в базе, на сервере 1С кроме него никого нет, и запускает один и тот же несложный отчёт, например взаиморасчёты по отдельным контрагентам с расшифровкой по документам. Объём данных примерно одинаковый, и время формирования должно быть примерно одинаковым, но нет! То отчёт формируется за секунду, а то приходится ждать целую минуту. Почему? А потому что на этом же физическом сервере в это время например другой бухгалтер в другой базе на другом сервере запустил закрытие месяца, и сервер страшно занят. Изнутри виртуальной машины вот это внешнее влияние отследить совершенно никак невозможно, только с тоской наблюдать, как скачут замеры времени ключевых операций.

Что делать в данном случае? Обеспечить гарантированно высокую производительность системы можно только в том случае, когда ей никто не может помешать. То есть ответ простой: если высокая производительность какой-то конкретной базы 1С является ключевым показателем работы сервера, то всех остальных пассажиров приходится подвинуть. Либо на конкретном примере с объективными замерами показываем админам, что разница в производительности слишком велика, чтобы её игнорировать, и дальше конкретно эта база 1С обслуживается физическим сервером без виртуализации, либо разгружаем виртуальный сервер от всех сторонних виртуальных машин, и эта база 1С обслуживается виртуальным сервером, но её производительность в любом случае становится стабильной.

В книжке 1С эксперта на 22й странице методика считает, что наиболее значимый вклад составляют плохая работа запроса и плохая работа кода. При этом способность среды выполнять действия с необходимой скоростью не рассматривается. Считается, что во-первых скорость среды неизменна, хотя в виртуальной среде это может быть совсем не так. Кроме того, схожая по внешним признакам среда на практике может кардинально отличаться способностью выполнять такой же объём работ за единицу времени. На сервер может быть возложена куча других задач («резиновый сервер»: купили дорогой, надо использовать ) Обычно, когда проводят нагрузочное тестирование – его всегда проводят с имитацией деятельности в базе, но в реальной жизни надо учитывать и имитировать любую другую стороннюю нагрузку (веб-сервер, терминальный сервер, другая ERP), которые могут отнимать непредсказуемую часть ресурсов сервера. В учебнике приводится упрощённый вариант, которого в жизни обычно не бывает. Написанное в учебнике правильно, но этого явно недостаточно для того, чтобы решать задачу по-настоящему. Умение разложить состав нагрузки по составляющим источникам позволяет существенно сократить объём денег и усилий, необходимых для решения проблем.

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

В качестве ещё одного примера: у нас в своё время был неприятный опыт отладки запроса на базе 1С, размещённой в облаке Амазон. Сервер 1С был развёрнут на одной амазоновской виртуалке, сервер СУБД на другой. Сидим на тестовом сервере в одном сеансе, никого больше нет. Запускаем один и тот же довольно несложный запрос и замечаю, что время его выполнения может отличаться на порядок. То есть к примеру он может выполниться за 3 секунды, в следующий раз за 25, потом за 10. Внутри тестовых серверов не происходит ничего, что могло бы объяснить такую разницу. Всё зависит от того, сколько и каких виртуалок ещё развёрнуто на тех же физических серверах, какую они генерируют загрузку процессоров, памяти, дисков и сети.

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

www.gilev.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы решаете проблемы из второй и третьей групп (проблемы непостоянные и непредсказуемые или предсказуемые, но сложно решаемые), то обычно бывает, что система в принципе хорошо работает почти весь день. 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 2017 COMMUNITY.

1c-e.ru

Повышение производительности 1С для администраторов | Gilev.ru

Зубатов Денис Андреевич, Анжелюс:

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

Томских Никита Леонидович, ИНК:

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

 

Михайловский Николай Николаевич, Альфа Моторс:

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

 

Прудько Артур Анатольевич, ЕВРОСТОК:

Хочу поблагодарить команду Гилева, а в частности Дмитрия Юхтимовского за курсы. Очень много полезной информации, нюансы на которые сразу и не обратишь внимание. 1С имеет кучу специфичных моментов, которые рассмотрены на курсе.См. полный отзыв.

 

Герман Кригер, Парфюм Лидер:

Курс просто фантастический. Очень понравился преподаватель Дмитрий Юхтимовский. Он дал очень интересный и объемный обзор подходов к замеру быстродействия, поиску узких мест.См. полный отзыв.

 

Гуревич Евгения Валерьевна, ТопПром:

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

 

Рудаков Сергей Алексеевич, ЭФКО:

Была получена хорошо преподнесенная структурированная информация по способам повышения производительности информационных систем на базе 1С. Научился выявлять наиболее «узкие» места в производительности 1С. Всем рекомендую. См. полный отзыв.

www.gilev.ru

Оптимизация MS SQL для 1С

В этой статье мы рассмотрим методику оптимизации системы 1С Предприятие 8.2 или 8.3, которая работает на СУБД MS SQL. Материал будет изложен в виде пошаговой инструкции.

Анализ загруженности оборудования

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

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

Для анализа нагрузки оборудования необходимо использовать системную утилиту «Performance monitor» (Монитор ресурсов, perform.exe).

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

Получите 267 видеоуроков по 1С бесплатно:

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

Общая оптимизация

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

Поэтому для ускорения процесса вторым этапом рекомендуется произвести общие действия по оптимизации системы. Необходимо найти узкие места с помощью 1С:ЦУП и попытаться исправить их. Обычно в конфигурациях находится 3-6 «больных» мест, излечив которые, система начинает работать существенно быстрее. Такими местами может стать обычный неоптимальный запрос или неправильное использование объектов метаданных.

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

Оценка удовлетворенности пользователей (APDEX)

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

С помощью методики APDEX можно оценить степень удовлетворённости пользователей в интегральном значении. По этой оценке в дальнейшем можно объективно оценить проделанную работу. Подробнее о методике оценки производительности APDEX.

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

Поиск и устранение оставшихся проблем производительности 1С

Далее необходимо локализовать оставшиеся проблемы низкой скорости 1С. Условно все проблемы можно разделить на два вида:

Проблемы производительности можно легко решить. Для их анализа можно воспользоваться такими инструментами, как SQL Profiler, ЦУП, технологический журнал и т.д.

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

Если Вас не устраивает скорость работы системы 1С, не расстраивайтесь, в большинстве случаев такие проблемы решаемы – обратитесь к специалисту.

К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.

programmist1s.ru

Оптимизация и ускорение работы 1С

Оптимизация и ускорение работы 1С

Оптимизация производительности 1С

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

Оптимизация производительности необходима в случаях: 

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

Симптомы необходимости в оптимизации продуктов 1С варьируются от ярковыраженных хронических сбоев до периодически возникающих проблем:

Жалобы пользователей на

А также:

Долгое проведение документов.

Скорость выполнения критичных бизнес-операций не приемлема требованиям бизнеса.

Оптимизация запросов 1С

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

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

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

Оптимизация баз 1С

Как правило, оптимизация баз 1С (как SQL так и других) требуется в случаях:

Выполнение специалистами работ по оптимизации 1С позволяет достичь следующих результатов:

www.rbd.by


Prostoy-Site | Все права защищены © 2018 | Карта сайта