ERP   /\/   Управление   /\/   Системы     (Лучшие)

Интернет - ERP - CRM - Axapta - 1С

• Зачем предприятию ERP
• Что ограничивает быстродействие ERP - Часть 1
• Что ограничивает быстродействие ERP - Часть 2
• Бакалавр по ERP и бесплатные системы
• Бухгалтерия и управление: тигр и кошка в одной клетке?

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

Часть 1. Словарь проблем и решений

Человек ползает под фонарем, подходит милиционер.
- Вы что то потеряли
- Да, ключи, вон в тех кустах посеял.
- А почему ищите здесь?
- Здесь светлее.

Бородатый анекдот про научные изыскания.
В нашем случае про то, как обычно решающих проблемы быстродействия.

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

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

Начнем с очевидных:
(Внимание! В статье активно используются различные технические термины.) Если Вас это не пугает, то продолжим...

Сети

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

"Если бы Эдисону пришлось найти иголку в стоге сена, он <…> начал бы осматривать соломинку за соломинкой, пока не отыскал бы искомое".

Никола Тесла

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

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

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

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

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

Электроника это наука о контактах - или их нет там где они должны быть, или они есть там где их не должно быть

Студеньческий фольклер

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

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

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

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

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

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

Структуры данных

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

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

PL/SQL в Oracle

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

Упрощенно оператор select представляет из себя перемножение матриц. Действие этого оператора плохо оптимизируются. Здесь помогают индексы и правильный выбор таблиц. Неправильное его использование при критической массе данных приводит к перемножению больших таблиц (например 10 000 000 Х 10 000 000 записей и больше, но мире существует единичные суперкомпьютеры которые умеют делать такую операцию мгновенно, а типовые, даже дорогие сервера на этом тормозят).
Современные ERP содержать много кода и среди прочих правильных select нередко встречаются и такие неправильные. Опытные специалисты хорошо знают эти места и заранее при настройке системы ищут способы их обойти. Но как мы говорили Интеграторы не любят специалистов с таким опытом (см. статью Проблемы быстродействия ERP).
Индексы не панацея. Эффективность использования индексов в selectе по нескольким таблицам заметно падает в отличии от работы с одной таблицей.

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

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

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

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

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

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

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

Индексы

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

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

Как Microsoft проиграла битву за API Джоэл Сполски 2005г.

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

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

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

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

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

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

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

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

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

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

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

С т а т ь и

() Интернет

(+) ENTERPRISE RESOURCE PLAN

() CRM

() Dynamics Ax (Axapta)

() 1С