Оптимизация производительности ManageEngine ServiceDesk 11
Обновлено 12.02.2020
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в рунете Pyatilistnik.org. В прошлый раз я вам рассказывал, как скачать полный дистрибутив MS Office 365, чтобы у вас всегда был установочный пакет без необходимости его постоянно скачивать. Двигаемся дальше и сегодня я хочу с вами поделиться небольшим опытом по оптимизации производительности ManageEngine ServiceDesk 11.x и выше. Я расскажу, что вы можете предпринять, чтобы улучшить время ответа у портала и снизить нагрузку на сервер приложения. Думаю, что кому-то это будет полезно.
В прошлом году я произвел обновление ManageEngine ServiceDesk Plus 9.3 до ManageEngine ServiceDesk Plus 11 и рассказывал с какими сложностями и моментами я столкнулся:
- Настройка SSO в ManageEngine ServiceDesk
- Установка сертификата на SD
- Как сменить подключение к БД в ManageEngine SD
- Default master key password is not compatible
- ServiceDesk выполнил переадресацию слишком много раз
- Не синхронизируются данные из Active Directory в ManageEngine ServiceDesk
- Пропуск создания резервной копии при обновлении
- ManageEngine ServiceDesk добавляет 50 лет к заявке
- NTLM Failed Redirecting To Login Page
- Duplicate key was found
- Долго загружается ManageEngine ServiceDesk 10000
Не хилый такой получился списочек. Основная проблема загруженных и интенсивно используемых сервисов, это проблема с оптимизаций. Очень часто установив продукт из коробки со стандартными настройками вы долгое время можете его эксплуатировать без особых проблем, но наступают времена, когда количество людей увеличивается, обновляются сторонние компоненты от которых зависит сервис, обновляется операционная система, где работает сам сервис и уже то окружение и те условия которые были изначально, кратно могут отличаться от существующих.
Тут системный администратор начинает производить оптимизацию сервиса, уменьшая нагрузку, отключая не нужные компоненты, увеличивая разные ресурсы, вот об этом и пойдет речь. Опишу свое тестовое окружение.
Тестовая среда ManageEngine ServiceDesk 11
У меня есть тестовая виртуальная машина на гипервизоре Vmware ESXI 6.5, в которой установлена операционная система Windows Server 2012 R2. На ней на текущий момент работает ManageEngine ServiceDesk 11004. На сервере 16 гб оперативной памяти, 2 процессора по 2 ядра, в качестве дисковой подсистемы SSD массив. В какой-то момент пользователи начали жаловаться, что веб-интерфейс открывается очень долго, почти по 15-25 секунд. Когда я запустил мобильную версию браузера (она просто содержит инструменты разработчика), по которым можно отследить какой элемент и сколько времени грузится, то я увидел вот такую не очень приятную картину. Как видно JAVA скрипты в среднем отрабатывают по 3-4 секунды, что не очень хорошо.
Какие компоненты можно оптимизировать
Так как у меня долго открывались JAVA скрипты, то я полез смотреть достаточно ли серверу ресурсов. Я открыл диспетчер ресурсов, кто не помнит для этого можно одновременно нажать три клавиши CTRL+SHIFT+ESC, На вкладке процессов я вижу, что у меня используется всего 7% процессорных мощностей и 28% оперативной памяти, то есть ресурсов хватает. Самый прожорливый был процесс Java(TM) Platform SE binary занимавшим 2,5 ГБ оперативной памяти.
Java вообще очень прожорливая штука и у нее есть свои тонкие настройки минимальных и максимальных значений оперативной памяти, которые она может брат, именно в такой лимит по верхней планке я и уперся. Есть такое понятие java heap size (Java куча) - это объем памяти, выделенный для приложений, работающих в JVM. Объекты в памяти кучи могут быть разделены между потоками. Практический предел размера кучи Java обычно составляет около 2-8 ГБ в обычной JVM из-за пауз сборки мусора. Многие типы приложений могут извлечь выгоду из очень больших куч, таких как вычисления в памяти , базы данных NoSQL , приложения больших данных , аналитика, персонализация веб-сайтов и электронная коммерция.
Когда программа Java запускалась, виртуальная машина Java получает некоторую память из операционной системы. Виртуальная машина Java или JVM использует эту память для всех своих нужд, и часть этой памяти называется памятью кучи Java. Куча в Java обычно располагается внизу адресного пространства и движется вверх. всякий раз, когда мы создаем объект с помощью оператора new или любым другим способом, объекту выделяется память из кучи, и когда объект умирает или собирает мусор, память возвращается в пространство кучи в Java.
Как увеличить размер кучи в Java
Размер пространства кучи по умолчанию в Java составляет 128 МБ на большинстве 32-разрядных JVM от Sun, но он сильно варьируется от JVM к JVM, например, максимальный размер по умолчанию и начальный размер кучи для 32-разрядной операционной системы Solaris (SPARC Platform Edition) составляют -Xms=3670K и -Xmx 64M и значения по умолчанию для параметров размера кучи в 64-разрядных системах были увеличены примерно на 30%.
Кроме того, если вы используете сборщик мусора с пропускной способностью в Java 1.5, максимальный размер кучи JVM по умолчанию будет равен физической памяти/4, а начальный размер кучи по умолчанию будет равен физической памяти/16. Другой способ найти размер кучи JVM по умолчанию - запустить приложение с параметрами кучи по умолчанию и отслеживать использование JConsole, которое доступно в JDK 1.5 и далее, на вкладке VMSummary вы сможете увидеть максимальный размер кучи.
Кстати, вы можете увеличить размер кучи Java в зависимости от потребностей вашего приложения, и я всегда рекомендую это, чтобы избежать использования значений кучи JVM по умолчанию, если ваше приложение является с большим количеством объектов. Вы можете изменить размер кучи пространства с помощью параметров виртуальной машины Java -Xms и -Xmx. -Xms обозначает начальный размер кучи, а -Xmx обозначает максимальный размер кучи в Java.
Перед тем, как мы оптимизируем java heap size в нашем ManageEngine ServiceDesk 11, я бы рекомендовал вам перейти на вкладку "Сообщество", а затем в раздел "Индикатор работоспособности"
У вас откроется превосходная оснастка "Индикатор работоспособности", тут вы сможете обнаружить полезные данные:
- Использование жесткого диска
- Размер ОЗУ
- Внутренняя память - это и есть Xms начальный размер кучи
- Максимальный объем памяти - Xmx максимальный размер кучи в Java
- IP-адрес сервера
- Имя базы данных и многое другое
так как у меня есть куча свободной памяти, то я бы хотел ею поделиться. Перейдите в папку ManageEngine\ServiceDesk\conf и найдите там файл wrapper.conf. Открываем его текстовым редактором и находим пункты:
- # Initial Java Heap Size (in MB)
wrapper.java.initmemory=128 - # Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=2512
Как видите у меня и есть ограничение 2,5 ГБ и в моем случае JAVA упирается в размер кучи. Я выставил ему 5000. так же измените:
- wrapper.java.additional.19=-XX:PermSize=64м можно изменить на wrapper.java.additional.19=-XX:PermSize=512m
- wrapper.java.additional.20=-XX:MaxPermSize=128m можно изменить на wrapper.java.additional.20=-XX:MaxPermSize=512m
Чтобы настройки применились, вам необходимо перезапустить службу servicedesk. Для этого откройте PowerShell и выполните команду:
Проверяем теперь нагрузку на JAVA.
MySQL Tuning
Вы также можете выполнить настройку базы данных MySQL. Перейдите в папку ManageEngine\ServiceDesk\bin и отредактируйте файл startdb.bat на WordPad и добавьте следующие параметры в последнюю строку файла в зависимости от объема ОЗУ.
- Для 1 ГБ оперативной памяти:
--set-variable=query-cache-type=2 --read_buffer_size=128K --read_rnd_buffer_size=1M --sort_buffer_size=1M --myisam_sort_buffer_size=4M --tmp_table_size=32M --max_heap_table_size=32M --key_buffer_size=32M --innodb_buffer_pool_size=128M --bulk_insert_buffer_size=16M --table_cache=512 --thread_cache=32 --innodb_flush_log_at_trx_commit=0 --low-priority-updates
- Для 2 ГБ оперативной памяти:
--set-variable=query-cache-type=2 --read_buffer_size=128K --read_rnd_buffer_size=1M --sort_buffer_size=2M --myisam_sort_buffer_size=4M --tmp_table_size=32M --max_heap_table_size=32M --key_buffer_size=32M --innodb_buffer_pool_size=256M --bulk_insert_buffer_size=16M --table_cache=512 --thread_cache=32 --innodb_flush_log_at_trx_commit=0 --low-priority-updates
- Для 3 ГБ оперативной памяти:
--set-variable=query-cache-type=2 --read_buffer_size=128k --read_rnd_buffer_size=1M --sort_buffer_size=2M --myisam_sort_buffer_size=8M --tmp_table_size=32M --max_heap_table_size=32M --key_buffer_size=64M --innodb_buffer_pool_size=750M --bulk_insert_buffer_size=16M --table_cache=750 --innodb_flush_log_at_trx_commit=0 --low-priority-updates
- Для 4 ГБ оперативной памяти:
--set-variable=query-cache-type=2 --read_buffer_size=128K --read_rnd_buffer_size=2M --sort_buffer_size=2M --myisam_sort_buffer_size=8M --tmp_table_size=32M --max_heap_table_size=32M --key_buffer_size=64M --innodb_buffer_pool_size=1024M --bulk_insert_buffer_size=16M --table_cache=900 --innodb_flush_log_at_trx_commit=0 --low-priority-updates
Отключить краткое описание Поиск
Краткое описание относится к описанию, которое появляется при наведении курсора на ссылку темы запроса в представлении списка запросов. По умолчанию при выполнении операции поиска выполняется поиск краткого описания запроса. Но когда у вас большой объем данных, производительность ServiceDesk Plus со временем снижается. Вы можете отключить эту функцию с помощью запроса:
Очистка список последних элементов
По умолчанию список последних элементов удаляется один раз в 15 дней. Но вы можете улучшить производительность ServiceDesk Plus, увеличив частоту очистки. Пример: если вы хотите очищать список последних элементов каждые 5 дней, используйте запрос:
Максимальный предел для очистки списка последних элементов составляет 90. Если вы хотите отключить очистку, установите значение параметра -1.
Ограничение журнала очистки ошибок
По умолчанию список журнала ошибок удаляется один раз каждые 180 дней. Но вы можете увеличить частоту очистки, чтобы ускорить процесс резервного копирования. Пример: если вы хотите очищать список ошибок журнала каждые 30 дней, используйте запрос,
Максимальное ограничение на очистку списка ошибок составляет 365. Если вы хотите отключить очистку, установите значение параметра -1.
Очистка о входе и выходе из системы
Это таблица, содержащая информацию о сеансе, т.е. информацию о входе и выходе из системы. Эти записи не используются приложением и могут периодически удаляться для повышения производительности базы данных. По умолчанию сведения о сеансе удаляются один раз в 90 дней, но для повышения производительности вы можете увеличить частоту очистки. Пример. Если вы хотите очищать сеанс ACC каждые 30 дней, используйте запрос:
Максимальный предел для очистки данных сеанса ACC составляет 365. Если вы хотите отключить очистку, установите для параметра значение -1.
Удалить сгенерированные системой уведомления
Системные уведомления - это уведомления, созданные и отправленные системой. Вы можете удалить все системные уведомления или вручную проверить уведомления для удаления. Если вы хотите удалить все системные уведомления, выполните запрос:
Чтобы получить список заголовков уведомлений для удаления нежелательных уведомлений, выполните запрос:
Пример: если заголовок уведомления «has been added to the group», используйте запрос, чтобы удалить уведомления под этим заголовком, %has been added to the group%;
Увеличьте размер пользовательского кеша
По умолчанию число объектов данных пользователя, которые будут кэшироваться, равно 500. Но в случае высокопроизводительных компьютеров с хорошими техническими характеристиками, это значение можно увеличить, чтобы кэшировать больше данных для быстрого ответа. Пример: если вы хотите увеличить количество кешей до 1000, используйте запрос:
Увеличьте размер кэша для техников
По умолчанию число объектов данных технического персонала, которые будут кэшироваться, равно 300. Но в случае высокопроизводительных компьютеров с хорошими техническими характеристиками, это значение можно увеличить, чтобы кэшировать больше данных для быстрого ответа. Пример: если вы хотите увеличить кэш до 1000, используйте запрос:
Увеличение количества идентификаторов сообщений
По умолчанию число идентификаторов сообщений, которые будут кэшироваться, равно 1000. Но в случае, если у вас много оперативной памяти, это значение можно увеличить, чтобы кэшировать больше данных для быстрого ответа. Пример: если вы хотите увеличить количество кешей до 2000, используйте запрос:
Увеличение количества E-mail идентификаторов/идентификаторов пользователей Cache Count
По умолчанию число идентификаторов электронной почты/идентификаторов пользователей, которые будут кэшироваться, равно 1000 , но это значение можно увеличить, чтобы кэшировать больше данных для быстрого ответа. Пример: если вы хотите увеличить количество кешей до 2000, используйте запрос:
Дополнительные ссылки
- https://www.manageengine.com/products/service-desk-msp/help/adminguide/general-features/performance-guide.html
На этом у меня все, я надеюсь, что вам удалось увеличить производительность вашей системы ManageEngine ServiceDesk 11. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.
Добавить комментарий