Должен ли я запускать свое приложение с несколькими экземплярами (т. Е. На машинах) с большим объемом памяти или с большим количеством экземпляров с небольшим объемом памяти? Какая стратегия оптимальна? С этим вопросом можно часто сталкиваться. После создания приложений в течение 2 десятилетий, после создания инструментов проектирования / устранения неполадок JVM (GCeasy, FastThread, HeapHero), я все еще не знаю правильного ответа на этот вопрос. В то же время я считаю, что и на этот вопрос нет бинарного ответа. В этой статье я хотел бы поделиться своими наблюдениями и опытом по этой теме.

История двух многомиллиардных предприятий

Поскольку наши инструменты проектирования / устранения неполадок JVM широко используются на крупных предприятиях, у меня была возможность увидеть реализации корпоративных приложений мирового класса в действии. Недавно мне довелось увидеть две быстрорастущие технологические компании (если я назову их имя, каждый, читающий эту статью, узнает их). Головные офисы обеих компаний находятся в Кремниевой долине. Их бизнес - это технологии, поэтому они знают, что делают, когда дело доходит до инженерии. Они любимицы с Уолл-стрит, пользующиеся большим успехом. Их рыночная капитализация составляет несколько миллиардов долларов. Они являются образцом современных процветающих предприятий. Для нашего разговора назовем эти два предприятия компанией-A и компанией-B.

Меня безмерно удивляет то, что оба предприятия приняли «две крайности», когда дело касается объема памяти. Компания-A установила размер кучи (то есть -Xmx) равным 250 ГБ, тогда как компания-B установила размер кучи равным 2 ГБ. то есть размер кучи компании A в 125 раз больше, чем размер кучи компании B. Оба предприятия уверены в своих настройках размера памяти. Как говорится: «Доказательства в пудинге», оба предприятия масштабируют и обрабатывают миллиарды критически важных для бизнеса транзакций.

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

Большой объем памяти может быть дорогим

Большой размер памяти с несколькими экземплярами (то есть с машинами) обычно дороже, чем с небольшим объемом памяти, большим количеством экземпляров. Вот простая математика, основанная на стоимости экземпляров AWS EC2 в регионе Восток США (Северная Вирджиния):

m4.16xlarge - ОЗУ 256 ГБ - Стоимость инстанса Linux по требованию: 3,2 доллара в час

T3a small - 2 ГБ ОЗУ - стоимость инстанса Linux по требованию: 0,0188 доллара США в час

Таким образом, чтобы иметь объем оперативной памяти 256 ГБ, нам нужно было бы получить 128 экземпляров «T3a small» (т.е. 128 экземпляров x 2 ГБ = 256 ГБ).

128 x T3a small - 2 ГБ ОЗУ - Стоимость инстанса по требованию Linux: 2,4064 доллара в час (т. Е. 128 x 0,0188 доллара в час)

Это означает, что большой объем памяти с несколькими экземплярами стоит 0,793 доллара в час (т.е. 3,2–2,4064 доллара) больше, чем небольшой объем памяти с большим количеством экземпляров. Другими словами, стратегия «большой объем памяти с несколькими экземплярами» на 33% дороже.

Конечно, можно привести еще один контраргумент: вам может понадобиться меньше инженеров, меньше электричества, меньше недвижимости, если у вас меньше машин. Также может быть проще установить исправления и обновить серверы.

Бизнес-запросы

В некоторых случаях объем памяти вашего приложения зависит от характера вашего бизнеса. Вот реальный инцидент, с которым мы столкнулись: когда мы создавали HeapHero (инструмент анализа дампа кучи), размер памяти нашего инструмента должен был быть больше, чем файл дампа кучи, который он анализирует. Предположим, что размер файла дампа кучи составляет 100 ГБ, тогда размер памяти инструмента HeapHero должен быть более 100 ГБ. Выбора нет.

Допустим, вы кэшируете большой объем (скажем, 200 ГБ) данных для максимизации производительности приложения, тогда размер вашей кучи должен быть более 200 ГБ. У тебя не будет выбора. Таким образом, в некоторых случаях размер вашей памяти будет зависеть от бизнес-требований.

Производительность и устранение неполадок

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

  • Вы можете использовать JVM без паузы (например, «Azul»).
  • Необходимо выполнить правильную настройку ГХ, чтобы сократить время пауз.

Точно так же, если вам нужно устранить любую проблему с памятью, вам придется записывать дампы кучи из приложения. Дамп кучи - это, по сути, файл, который содержит всю информацию о памяти вашего приложения, например, какие объекты присутствовали, каковы их ссылки, сколько памяти занимает каждый объект,…. Дампы кучи приложений с большим объемом памяти также будут иметь очень большой размер. Также сложно анализировать дампы кучи большого размера. Даже лучшие в мире инструменты для создания дампа кучи, такие как Eclipse MAT, HeapHero, имеют проблемы с анализом дампа кучи размером более 100 ГБ. Воспроизведение этих проблем в лаборатории тестирования, хранение файлов дампа кучи, совместное использование файлов дампа кучи - все это проблемы.

Эмоции на первом месте, затем объяснение

Прочитав такие книги, как «Как мы принимаем решение», написанные Джоном Лерером, я совершенно убежден, что ваш предыдущий опыт, эмоции играют ключевую роль в определении объема памяти вашего приложения. Раньше я работал в крупном финансовом учреждении. Главный архитектор этого финансового учреждения предлагал нам запускать наши JVM с очень большим объемом памяти, объясняя это следующим образом: «Раньше мы запускали мэйнфреймы с очень большим объемом памяти»

Заключение

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

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