Блог

Ниже приведен мой сценарий.

У меня есть 2 тестовых сценария: — один может использовать от 5 ГБ до 15 ГБ памяти кучи, а другой сценарий может использовать от 5 ГБ до 12 ГБ.

Если у меня есть компьютер с памятью 32 ГБ,

Могу ли я назначить XMS 1GB XMX 22GB при выполнении первого скрипта (хотя моему скрипту требуется 15 ГБ), а для второго скрипта я могу назначить XMS 1GB и XMX 12GB

Поскольку сумма максимальных значений превышает 32 ГБ (общая память)

Во втором случае я назначаю так —>

для сценария 1: XMS 22 ГБ XMX 22 ГБ

для сценария 2: XMS 12 ГБ и XMX 12 ГБ

Сумма не более 34 ГБ.

Работает ли это случайно, как показано ниже —— >

Если для первого скрипта выделено 12 ГБ, заблокирована ли эта память для этого процесса / скрипта? и могу ли я не использовать неиспользуемую память для других процессов?

или

Если для первого скрипта выделено 12 ГБ, он использует столько, сколько ему требуется, и любой другой процесс может использовать оставшуюся память? ЕСЛИ это работает таким образом — мне не нужно специально назначать кучу для двух сценариев отдельно.

Если вы установите минимальную память кучи через Xms параметр, JVM зарезервирует эту память, и она будет недоступна для других процессов.

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

Например, посмотрите на мой ноутбук, который имеет 8 ГБ общей физической оперативной памяти:

Он имеет 8 ГБ физической памяти, из которых 1,2 ГБ свободны. Это означает, что я могу безопасно выделить 1 ГБ оперативной памяти для Java

Однако, когда я даю 8 ГБ Java как:

 java -Xms8G
  

он все еще работает

15 ГБ — все еще работает

и когда я пытаюсь выделить 20 ГБ, происходит сбой, потому что он не помещается в физическую виртуальную память.

Вы должны избегать подкачки, потому что это означает, что JMeter не сможет отправлять запросы достаточно быстро, даже если тестируемая система поддерживает это, поэтому обязательно измерьте, сколько у вас доступно физической оперативной памяти, и ваш тест не должен превышать это значение. Если вы не можете достичь этого на одной машине — вам придется перейти на распределенное тестирование

Кроме того, «одновременный» запуск 2 разных скриптов — это не то, что вам следует делать, потому что речь идет не только о памяти, одно ядро процессора может выполнять только одну команду за раз, другие команды ожидают в очереди и обслуживаются переключением контекста, что является дорогостоящей и медленной операцией.

И последнее, но не менее важное: выделение максимальной КУЧИ — не лучшая идея, потому что таким образом сборки мусора будут менее частыми, но будут длиться намного дольше, что приведет к выпадению пропускной способности, сохраняйте использование кучи от 30% до 80%, как в статье об оптимальном размере кучи