«Тепер поговоримо про найненажерливішого учасника нашого експерименту — JMeter. Його споживання ресурсів зашкалює: мінімум 5 Гб пам’яті;» Для сценарію з 1 реквестом, рілі?))
1) проблема в тому, що автор дивиться моніторинг докер контейнера і робить висновок, що саме стільки джиметр і використовує. Але реальність така: те що ми бачимо в таск менеджері/актівіті моніторі це зарезервована память. Її джава просто зайняла, оскільки ви їй дозволили це в параметрах -Xms -Xmx. Якщо поставимо -Xms=4g -Xmx=4g, то бачитимемо 4 гіга в моніторингу, але насправді використовуватися може 300mb
Після таких статей якраз і з’являються питання «я бачив в статті, шо джиметр використовує х100 більше памяті ніж інші, порадьте альтернативу»
2) jmeter, або точніше jvm буде використовувати ту память, яку ви їй виділите. А garbage collection, очистка/вивільнення пам’яті, буде запускатися, коли eden space в heap заповнюється до певного рівня. В залежності від загального розміру heap, розмір eden space буде відрізнятись, тобто якщо ви виділили 4 гіга пам’яті, джиметр використовуватиме більше пам’яті, перед тим як запустити очистку, ніж якщо б ви виділили джиметру 500 мегабайт. Для того щоб зрозуміти скільки насправді використовується памяті під час вашого тесту, можна підключитись профайлером до джиметра, або налаштувати моніторинг heap, наприклад використовуючи jolokia2 в telegraf.
Візьмемо для прикладу сценарій з статті, з одним реквестом і 100 потоками, без затримок. Підняв локально мок, зробив аналогічний сценарій і запустив тест на 3х конфігураціях джиметру: 1) -Xms=4g -Xmx=4g heap. Реальне використання heap було max 2.5gb, хоча в актівіті моніторі було 4gb. 2) -Xms=500mb -Xmx=500mb heap. Реальне використання heap max 375mb. 3) -Xms=200mb -Xmx=200mb heap. Реальне використання heap max 170mb.
У всіх трьох випадках throughput був ~12000rps, тобто просадки по навантаженню, при зменшенні виділеної пам’яті, не було. Чому так вийшло, що зменшивши кількість пам’яті, всеодно все ок? Тому що, в залежності від загалього розміру пам’яті, розмір eden space також різний: 120mb, 316mb і 2.5gb відповідно. І насправді для такого простого скрипта джиметру норм працювати і з 200mb пам’яті, але якщо ви щедро виділили більше, він не буде часто витрачати ресурси процесора на garbage connection, а буде використовувати весь доступний об’єм eden space.
Підсумовуючи, використання ресурсів напряму залежить від складності вашого сценарію, наскільки він оптимізований, конфігурації інструмента, яке навантаження ви генеруєте ТА ЧИ ПРАВИЛЬНО ВИ АНАЛІЗУЄТЕ ВИКОРИСТАННЯ РЕСУРСІВ. Ну і у випадку з джиметром, ствердження, що вам необхіодно мінімум 5гігів пам’яті для сценарію з одним реквестом, та навіть не з одним, точно не відповідає дійсності :)
«Тепер поговоримо про найненажерливішого учасника нашого експерименту — JMeter. Його споживання ресурсів зашкалює:
мінімум 5 Гб пам’яті;»
Для сценарію з 1 реквестом, рілі?))
1) проблема в тому, що автор дивиться моніторинг докер контейнера і робить висновок, що саме стільки джиметр і використовує. Але реальність така: те що ми бачимо в таск менеджері/актівіті моніторі це зарезервована память. Її джава просто зайняла, оскільки ви їй дозволили це в параметрах -Xms -Xmx.
Якщо поставимо -Xms=4g -Xmx=4g, то бачитимемо 4 гіга в моніторингу, але насправді використовуватися може 300mb
Після таких статей якраз і з’являються питання «я бачив в статті, шо джиметр використовує х100 більше памяті ніж інші, порадьте альтернативу»
2) jmeter, або точніше jvm буде використовувати ту память, яку ви їй виділите. А garbage collection, очистка/вивільнення пам’яті, буде запускатися, коли eden space в heap заповнюється до певного рівня.
В залежності від загального розміру heap, розмір eden space буде відрізнятись, тобто якщо ви виділили 4 гіга пам’яті, джиметр використовуватиме більше пам’яті, перед тим як запустити очистку, ніж якщо б ви виділили джиметру 500 мегабайт.
Для того щоб зрозуміти скільки насправді використовується памяті під час вашого тесту, можна підключитись профайлером до джиметра, або налаштувати моніторинг heap, наприклад використовуючи jolokia2 в telegraf.
Візьмемо для прикладу сценарій з статті, з одним реквестом і 100 потоками, без затримок.
Підняв локально мок, зробив аналогічний сценарій і запустив тест на 3х конфігураціях джиметру:
1) -Xms=4g -Xmx=4g heap. Реальне використання heap було max 2.5gb, хоча в актівіті моніторі було 4gb.
2) -Xms=500mb -Xmx=500mb heap. Реальне використання heap max 375mb.
3) -Xms=200mb -Xmx=200mb heap. Реальне використання heap max 170mb.
У всіх трьох випадках throughput був ~12000rps, тобто просадки по навантаженню, при зменшенні виділеної пам’яті, не було. Чому так вийшло, що зменшивши кількість пам’яті, всеодно все ок? Тому що, в залежності від загалього розміру пам’яті, розмір eden space також різний: 120mb, 316mb і 2.5gb відповідно. І насправді для такого простого скрипта джиметру норм працювати і з 200mb пам’яті, але якщо ви щедро виділили більше, він не буде часто витрачати ресурси процесора на garbage connection, а буде використовувати весь доступний об’єм eden space.
Підсумовуючи, використання ресурсів напряму залежить від складності вашого сценарію, наскільки він оптимізований, конфігурації інструмента, яке навантаження ви генеруєте ТА ЧИ ПРАВИЛЬНО ВИ АНАЛІЗУЄТЕ ВИКОРИСТАННЯ РЕСУРСІВ.
Ну і у випадку з джиметром, ствердження, що вам необхіодно мінімум 5гігів пам’яті для сценарію з одним реквестом, та навіть не з одним, точно не відповідає дійсності :)