anisiya_12 (anisiya_12) wrote,
anisiya_12
anisiya_12

Categories:

Что ограничивает быстродействие ERP систем 1-я, 2-я и 3-я части

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

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

Почему тормозят многие ERP?

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

А почему тогда все так медленно?

Многие пугаются даже самой постановки вопроса. ERP-системы представляются людям, не связанным с ИТ, сложными монстрами, которыми управляют шустрые программисты и ИТ-консультанты, сами до конца не ведающие, каким образом устроена их система. Хуже то, - многие консультанты и программисты, знающие определенные части ERP, имеют свое представление о ERP в целом. В таком контексте вопрос о том, по каким причинам система все-таки «тормозит», кажется сложным и требующим отдельной комиссии для каждого случая.

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

Начнем с очевидных:

Сети

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

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

Низкая скорость сети влияет на возможность работы с данными на удаленном компьютере. Особенно это заметно, если вы работаете с Интернетом через обычную модемную связь. Но, бывает, что и в корпоративных сетях возникают проблемы. Эти проблемы становятся ощутимыми в территориально-распределенных сетях от 100 компьютеров. Чаще всего причина кроется в неправильной топологии (структуре) сети. Есть два ключевых компонента топологии: коммутаторы (switch) и концентраторы (hub). Концентратор - это простое устройство, быстро рассылающее пришедший пакет на все подключенные к нему компьютеры (не только туда куда нужно). Иными словами, пакет данных широковещательно размножается. При неправильном использовании концентраторов мы получим сеть с множеством лишних пакетов. Каждый компьютер сети затратит немало времени на их фильтрацию. Современный коммутатор(switch), наоборот, умный, и тратит свое заметное время на обработку пакета и маршрутизацию: отправляет его только нужному адресату. При неправильном использовании коммутаторов мы получим значительную задержку во времени при доставке пакета на нужный компьютер.

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

Зоопарк систем

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

«Электроника- это наука о контактах: или их нет там, где они должны быть, или они есть там, где их не должно быть» .
Студенческий фольклор.

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

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

Оперативная память

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

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

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

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

В случае если приложению не хватает оперативной памяти, оно начинает записывать информацию на диск, и потом считывает ее обратно и так далее. В этот момент и происходит видимое временное зависание. Это заметно даже на персоналках, при работе в нескольких программах одновременно. Но если говорить про ERP-приложения, то увеличение количества оперативной памяти больше 2-х Gb имеет смысл только для сервера СУБД.


Структуры и хранилища данных

Сложность исправления: если в системе уже есть данные, то изменение - это длительная операция, которая возможна только при остановке системы.
Решение: возможно, что тяжелый запрос к СУБД – «SELECT» можно заменить более легким или разложить на два подзапроса. Если же необходимо изменение структуры данных, то, чем раньше будут сделаны изменения, тем легче их будет выполнить.

«Если говорить прямо, то практически весь SQL базируется на единственном
краеугольном камне, а именно - операторе «SELECT»
PL/SQL в Oracle

Данные ERP-систем в отличие от данных в Интернете структурированы и жестко взаимосвязаны. Они хранятся в таблицах. Основным оператором при программировании разработчиком запросов SQL для получения данных из таблиц является оператор «Select». Но именно он часто и является источником торможения многих систем. На скорость его работы может заметное влиять накопленный объем данных.

Упрощенно оператор «Select» - это перемножение матриц (выборок из различных таблиц). Действие этого оператора зачастую плохо оптимизируются. В увеличении быстродействия помогают индексы, правильный выбор таблиц и их взаимосвязи. Неправильное использование «Select» при критической массе данных приводит к перемножению больших таблиц данных (например, 10`000`000x10`000`000 записей и больше. Но в современном мире уже существует единичные суперкомпьютеры, которые умеют делать такую операцию мгновенно, а типовые, даже дорогие сервера, на этом тормозят). Современные ERP могут содержать много SQL-кода, и среди прочих правильных «Select» нередко встречаются неправильные (непродуманные или не оптимизированные разработчиком) системы. Опытные специалисты хорошо знают эти места и заранее при настройке системы ищут способы их обхода. Но, как упоминалось в статье « Проблемы быстродействия ERP» интеграторы не любят специалистов с таким опытом.

Индексы тут - не панацея. Эффективность использования индексов в «Select» по нескольким таблицам заметно падает в отличие от работы с одной таблицей.

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

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

Что ограничивает быстродействие 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 и уже хорошо знают ее особенности и возможности.

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

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

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

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

С чего начать и потом не пожалеть об этом

А сосед горе-ученика тоже был слепой <…> подмастерье приготовил в точности такие же лепешки и положил ему на глаза. На следующий день у незрячего соседа глаза вообще вытекли <…> «Как же так. Учитель, я сделал, как ты сказал в прошлый раз!» <…> мудрец ответил: «Слепота бывает по разным причинам: от сухости организма, от влажности, от жары, от холода и т.д. У тысячи слепых бывает тысяча причин. Иди, сынок. Тебе работать только пекарем».
Мирзакарим Норбеков «Опыт дурака или ключ к прозрению».

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

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

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

Мы выделим следующие факторы, влияющие на выбор конкретного способа борьбы с торможением:

1. Ограничения на операцию – в каком случае операцию сделать не возможно;

2. Время, сложность и стоимость подготовки определяется квалификацией и стоимостью специалистов, которые это могут сделать, а также необходимым объемом работы (стоимость оборудования не учитывается);

3. Возможность протестировать результаты операции до установки на работающую систему;

4. Время операции – время, на которое бизнес, использующий систему, будет остановлен;

5. Риск не получить желаемого эффекта – обратно пропорционален п.3;

6. Возможность «откатить» нежелательные последствия неправильных изменений (плохая оценка по данному пункту может быть скомпенсирована хорошей оценкой по п.5);

Каждую характеристику (кроме п.1) оценим по пятибалльной шкале, но, чтобы не возникло путаницы для отрицательных характеристик, будем указывать отрицательные значения. Значение - 5 для п.2 и п.4. может означать, что время заранее определить не возможно. Аналогично - 5 для п.2 означает непредсказуемость стоимости/сроков подготовки операции.

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

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

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


Таблица 1. Вероятные показатели операций по оптимизации КИС

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


Таблица 2. Что можно сделать до начала внедрения ERP

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


Подведем итог

Можно выделить 3 категории операций.

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

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

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

Источник

Tags: erp, будни нашего городка, житиё_моё, работа
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 30 comments