CftClub.ru
Клуб специалистов ЦФТ-Банк

Что ограничивает быстродействие ERP-систем, II часть

 
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Новости и публикации
Предыдущая тема :: Следующая тема  
Автор Сообщение
Alquimista
Участник


Вступление в Клуб: 25.06.2007
СообщениеСр Авг 22, 2007 08:42   Что ограничивает быстродействие ERP-систем, II часть Ответить с цитатой

<< Что ограничивает быстродействие ERP систем, I часть

Мартынов Дмитрий, Мольков Вячеслав

Что ограничивает быстродействие ERP-систем, II часть

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


Блокировки данных

Сложность диагностики: нужно определить именно те транзакции (Группы запросов к СУБД), которые являются причиной регулярной блокировки данных.
Решение: наращивание мощности сервера, сокращение длины транзакций.

Разработчики современных систем любят применять транзакционные схемы: завершение операции одного пользователя в ERP сдерживается завершением операции другого пользователя. Так работает инструмент транзакции СУБД, заложенный разработчиком системы и обеспечивающий целостность изменений в базе данных. Т.е. при выполнении операции из нескольких изменений с данными действует правило: если одно из изменений сделать невозможно (по каким либо причинам, которые, например, могут являться частью алгоритма), то все другие изменения надо отменить или не совершать.

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

Пример 2: Бывают взаимные блокировки: первый пользователь заблокировал таблицу А и хочет внести изменения в таблицу Б, а второй наоборот заблокировал таблицу Б и хочет внести изменения в таблицу А.

В каждой ERP тысячи типов операций, каждая из которых формирует разные транзакции, использующие различные таблицы. Заранее предсказать потенциальные блокировки очень сложно – каждый проект индивидуален. При накоплении данных в системе скорость работы падает, а время выполнения операций (транзакций) увеличивается, и блокировки начинают вносить свою дополнительную лепту в падение быстродействия.

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

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


Индексы

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

"Не заставляйте меня впечатывать во все мои файлы метаданные, которые я могу искать, используя язык запросов. Просто сделайте мне одолжение и поищите впечатанную мною строку на чертовом жестком диске, быстро, используя полнотекстовые индексы и другие технологии, наскучившие еще в 1973."
Как Microsoft проиграла битву за API
Джоэл Сполски 2005г.


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

Наличие индекса почти всегда замедляет операции добавления, удаления и изменения записи в таблице

Решая проблему по ускорению операций за счет использования индексов, многие не редко создают себе новую проблему, но не замечают этого. С одной стороны индексы ускоряют, а с другой - замедляют операции. Чтобы использовать индексы правильно, надо знать, как они устроены. Устроены они просто.

Если в таблице данные построены в любой неопределенной последовательности (это базовый принцип языка SQL), то в индексе наоборот данные лежат в строгой последовательности по типу словаря от "А" до "Я".
В разных транзакциях по-разному используются те же таблицы.

В транзакции А по таблице 1 делается проверка, а затем в таблицу 2 добавляется запись, в транзакции Б в таблицу 1 добавляется запись.

Если добавить индекс в таблицу 1, то транзакция А может ускориться, а транзакция Б может замедлится.

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

Конечно, это удобно и именно этот механизм является основным инструментом при работе с огромными базами данных. Тут действует закон: если количество записей увеличивается на порядок (в два раза – порядок-то двоичный), то скорость поиска возрастает всего на одну операцию. Т.е. если количество данных выросло в 1000 раз, то скорость поиска замедлилась на 10 операций, что при современных скоростях серверов не будет заметно.

Однако при работе с индексами имеются ресурсоемкие операции: добавление и удаление записи. Рассмотрим на примере того же словаря: попробуем добавить еще одно слово в наш словарь от "А" до "Я"? Это приведет к его переформатированию: все слова, которые лежат после добавляемого слова, надо сдвинуть вниз. Конечно, современные табличные процессоры СУБД с помощью специальных инструментов заметно оптимизируют эти операции, но скорость добавления записей в таблицу при использовании индексов все равно больше.

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

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


Забытые на пульте пассатижи

Сложность диагностики: трудно однозначно определить причину замедления процессов.
Решение: ведение журнала операций ИТ-персонала с КИС в департаменте ИТ, постоянный мониторинг изменения скорости работы.

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

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

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

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


Цепная реакция

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

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


Чаще всего к аварии c данными приводит не одна, а целая серия ошибок. Может быть так: плохая настройка системы вызывает тяжелый "Select" внутри наиболее используемой операции. Не отключены счетчики производительности на сервере. Это усугубляется недостатком оперативной памяти. Транзакции становятся долгими по времени. Результатом длинных транзакций становятся блокировки. Учащаются взаимные блокировки. И т.д. Эта "страшилка" является обычной ситуацией.

Заметное расширение рынка ERP и увеличение количества внедрений привело к существенному падению среднего качества проектов.

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

Когда диагноз поставлен, можно сделать изменения. Например: изменить топологию сети, поменять оборудование сети, изменить настройку сетевой системы, по возможности внести изменения в код сисемы ERP, изменить структуру данных ERP, изменить настройку ERP, добавить индексы в ERP, увеличить мощность сервера (добавить процессоры, поставить более быстрые диски), добавить оперативной памяти, проверить по журналу: после каких изменений система стала тормозить, найти забытые пассатижи, изменить настройки СУБД. Некоторые сравнительно простые действия почти не несут риска и могут быть выполнены и без диагностики.


Есть надежный способ

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

Далеко не во всех системах есть встроенная функция очистки данных оперативных таблиц. Чаще всего, это надо делать вручную. Такая операция является длительной и обычно требует остановки системы. Она требует тщательной подготовки, поскольку ошибка может привести к нарушению целостности данных и неправильной работе ERP. Иногда проще повторить внедрение, чем экспериментировать с данными системы: взять систему на момент внедрения, ввести в нее начальные финансовые и складские остатки и начать работу. Но это и не совсем внедрение, т.к. все уже умеют работать с ERP и уже хорошо знают ее особенности и возможности.

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

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

© www.erpnews.ru

>> Что ограничивает быстродействие ERP систем, III часть
Показать сообщения:   
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Новости и публикации Часовой пояс: GMT + 3
Страница 1 из 1

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Рейтинг@Mail.ru