Память, потраченная впустую приложением spring boot

Автор оригинала: Ram Lakshmanan.

Одним из широко растрачиваемых ресурсов в современном мире является память. Из-за неэффективного программирования удивительное (иногда “шокирующее”) количество памяти тратится впустую. Мы видим, что этот шаблон повторяется в нескольких корпоративных приложениях. Чтобы доказать это, мы провели небольшое исследование. Мы проанализировали знаменитое приложение spring boot pet clinic, чтобы посмотреть, сколько памяти оно тратит впустую. Это приложение было разработано сообществом, чтобы показать, как фреймворк приложений spring можно использовать для создания простых, но мощных приложений, ориентированных на базы данных.

Среда Весенняя загрузка 2.1.4.РЕЛИЗ Java SDK 1.8 Tomcat 8.5.20 MySQL 5.7.26 с разъемом MySQL/J 8.0.15

Стресс-тест Мы использовали Apache JMeter, популярный инструмент нагрузочного тестирования с открытым исходным кодом, для проведения нашего стресс-теста. Мы выполнили нагрузочный тест в течение 30 минут с приведенными ниже настройками:

Количество потоков (пользователей) – 1000 (Количество пользователей, подключенных к цели) Период нарастания (в секундах) – 10. Временные рамки для запуска всех запросов. В соответствии с нашей конфигурацией каждые 0,01 секунды будет запускаться 1 новый поток, т. е. 100 потоков в секунду. Количество циклов – Навсегда. Эти 1000 потоков выполняют тестовые итерации спина к спине. Продолжительность (секунд) -1800. После увеличения 1000 потоков непрерывно работают в течение 1800 секунд. Инжир: Настройки Jmeter

В нашем нагрузочном тесте мы отрабатывали следующие сценарии:

*Добавьте в систему нового владельца домашнего животного. *Просмотр информации, относящейся к владельцу домашнего животного. *Добавьте нового питомца в систему. *Просмотр информации, относящейся к домашнему животному. * Добавьте информацию, относящуюся к посещению, в историю посещений домашнего животного. * Обновите информацию, касающуюся домашнего животного. * Обновите информацию, касающуюся владельца домашнего животного. *Просмотр информации о владельце путем поиска его имени. *Просмотр информации обо всех владельцах.

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

Мы захватили дамп кучи из приложения Spring Boot Pet Clinic во время выполнения теста. (существует 7 различных вариантов захвата дампа кучи из приложений Java/Android. Вы можете выбрать тот вариант, который вам удобен).

Мы загрузили захваченный дамп кучи в инструмент HeapHero. Инструмент создал этот прекрасный отчет, показывающий, что 65% памяти тратится впустую из-за неэффективного программирования. Да, это простое приложение ванили, в котором, как предполагается, реализованы все лучшие практики, что тоже на широко известной платформе тратит 65% памяти.

В отрасли есть сотни инструментов для отображения объема используемой памяти. Но редко мы сталкиваемся с инструментами, которые могут измерить объем памяти, потраченный впустую из-за неэффективного программирования. Герой кучи – это простой инструмент, который анализирует ваши дампы кучи и показывает, сколько памяти тратится впустую из-за неэффективного программирования.

! [круговая диаграмма. PNG](https://ucarecdn.com/90d4bdad-1d06-41d3-8e60-0de354e3828b/Рис.: Диаграмма, сгенерированная Хитроу, показывает, что 65% памяти тратится впустую приложением Spring Boot pet clinic

Анализ потерь памяти Из отчета вы можете заметить следующее:

15,6% памяти тратится впустую из-за повторяющихся строк 14,6% памяти тратится впустую из-за неэффективных примитивных массивов 14,3% памяти тратится впустую из-за повторяющихся примитивных массивов 12,1% памяти тратится впустую из-за неэффективных коллекций

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

Рис.: Повторяющиеся Строки

Вы можете заметить, что 15,6% памяти тратится впустую из-за повторяющихся строк. Пожалуйста, обратите внимание

Строка Голди была создана 207 481 раз. ‘ Посетите страницу “строка была создана 132 308 раз”. Посещение ” было описанием, которое мы упомянули в тестовом сценарии.” Строка Бангалора была создана 75 374 раза. ‘ Бангалор” – это название города, которое мы указали в тестовом сценарии.” 123123123″ было создано 37 687 раз”. Строка Махеша была создана 37 687 раз. Очевидно, “Голди” – это имя питомца, которое было введено на экране с помощью тестового сценария.’ Посещение ” – это описание, введенное на экране с помощью тестового сценария. Точно так же и ценности. Но возникает вопрос, почему так много тысяч раз создаются одни и те же строковые объекты.

Мы все знаем, что строки неизменяемы (то есть, как только они созданы, они не могут быть изменены). Учитывая, почему создаются эти многие тысячи повторяющихся строк?

Инструмент HeapHero также сообщает путь кода, в котором создаются эти повторяющиеся строки.

Рис.: Путь к коду, из которого исходят повторяющиеся строки

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

Неэффективные коллекции Еще одной основной причиной потери памяти в приложении spring boot pet clinic является неэффективная реализация коллекций. Ниже приведена выдержка из отчета о погоде:

Рис.: память, потраченная впустую из-за неэффективных коллекций

Вы можете заметить, что в 99% LinkedHashSet в памяти нет никаких элементов. Если элементов нет, зачем вообще создавать LinkedHashSet? При создании нового объекта LinkedHashSet в памяти зарезервировано место для 16 элементов. Все пространство, отведенное для этих 16 элементов, теперь потрачено впустую. Если вы выполните ленивую инициализацию Linkedhashset, то эта проблема не возникнет.

Плохая Практика:

private LinkedHashSet myHashSet = new LinkedHashSet();

public void addData(String key, String value) {

 myHashSet.put(key, value);
}

Наилучшая практика:

private LinkedHashSet myHashSet;

public void addData(String key, String value) {

      if (myHashSet == null) {

 myHashSet = new LinkedHashSet();
      }

myHashSet.put(key, value);
}

Аналогично, еще одно наблюдение: 68% ArrayList содержит в себе только 1 элемент. При создании объекта ArrayList в памяти зарезервировано место для 10 элементов. Это означает, что в 88% элементов ArrayList 9 пространство тратится впустую. Если вы можете инициализировать ArrayList с помощью емкости, этой проблемы можно избежать.

Плохая практика: Инициализация коллекций по умолчанию.

new ArrayList();

Наилучшая практика: Инициализируйте коллекции с помощью емкости

 new ArrayList(1);

Память стоит недешево Можно возразить, что память такая дешевая, так почему же мне нужно беспокоиться об этом? Справедливый вопрос. Но память моих друзей недешева в эпоху облачных вычислений. Существует 4 основных вычислительных ресурса: *Процессор *Память *Сеть *Хранение

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

Для большинства приложений это память . Процессор всегда находится на уровне 30-60%. Всегда есть много места для хранения. Трудно насытить сеть (если только ваше приложение не транслирует много видеоконтента). Таким образом, для большинства приложений в первую очередь насыщается память. Несмотря на то, что процессор, хранилище и сеть используются недостаточно, просто потому, что память становится насыщенной, вы в конечном итоге предоставляете все больше и больше экземпляров EC2. Это увеличит ваши вычислительные затраты в несколько раз.

С другой стороны, все без исключения современные приложения тратят от 30 до 90% памяти из – за неэффективных методов программирования. Даже выше Spring boot pet clinic без особой бизнес-логики тратит 65% памяти. Реальные корпоративные приложения будут тратиться впустую в аналогичном объеме или даже намного больше. Таким образом, если вы сможете написать эффективный код с памятью, это снизит ваши вычислительные затраты. Поскольку память является первым ресурсом, который насыщается, если вы сможете уменьшить потребление памяти, вы сможете запускать свое приложение на меньшем количестве экземпляров сервера. Возможно, вам удастся сократить 30-40% серверов. Это означает, что ваше руководство может снизить на 30-40% стоимость центра обработки данных (или поставщика облачного хостинга), а также расходы на техническое обслуживание и поддержку. Это может привести к экономии средств в несколько миллионов/миллиардов долларов.

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

Оригинал: “https://www.codementor.io/@suryab/memory-wasted-by-spring-boot-application-10zfdddlpo”

Читайте ещё по теме: