В нашей тестовой среде у нас есть множество приложений, распределенных по нескольким серверам и доменам Glassfish. Чтобы упростить управление версиями, я хотел бы иметь один домен Glassfish для каждого клиента на каждое приложение (что-то вроде тяжелой версии множества экземпляров причала).
Я слышал, что Glassfish требует больших ресурсов, поэтому я хотел бы приблизительно измерить, сколько экземпляров поместится в доступной оперативной памяти. Я знаю, что могу это сделать, запустив инстансы и наблюдая top вывод, но на какой конкретной статистике мне следует сосредоточиться, чтобы получить точную оценку потребления ресурсов на каждый экземпляр?
С помощью top определение требований к памяти - это больше искусство, чем точная наука. Есть два основных способа сделать это.
В обоих случаях перед запуском исследуемой программы (в вашем случае GlassFish) вы хотите получить базовый уровень использования ресурсов системы. Затем вы идете по одному из двух путей:
Это способ я лично делаю это, потому что я чувствую, что это дает лучшую картину общего использования ресурсов.
Кроме того, если вы ошибетесь, вы, вероятно, получите большее число, а не меньшее.
top где-нибудь в терминале и обратите внимание на вывод заголовка.last pid: 26611; load averages: 0.50, 0.38, 0.34 up 42+18:51:53 11:44:41
34 processes: 1 running, 33 sleeping
CPU: 0.9% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.1% idle
Mem: 447M Active, 112M Inact, 233M Wired, 22M Cache, 111M Buf, 170M Free
Swap: 2048M Total, 220K Used, 2048M Free
last pid: 26571; load averages: 0.35, 0.35, 0.33 up 42+18:49:00 11:41:48
34 processes: 1 running, 33 sleeping
CPU: 2.7% user, 0.0% nice, 1.2% system, 0.0% interrupt, 96.1% idle
Mem: 606M Active, 109M Inact, 235M Wired, 22M Cache, 111M Buf, 12M Free
Swap: 2048M Total, 224K Used, 2048M Free
Active + wired) и бесплатно (Free) объем памяти.Повторите вышеизложенное для дополнительных экземпляров исследуемой программы и нанесите изменение на график, чтобы определить тенденцию / кривую.
Этот метод исследует отдельные процессы, связанные с исследуемой программой.
Действуйте, как указано выше, но не смотрите на top Заголовок output смотрит на отдельные процессы, которые запускаются при запуске программы (в качестве примера я буду использовать Postgres):
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
4883 pgsql 1 58 0 181M 146M sbwait 0 24.3H 6.59% postgres
5842 pgsql 1 44 0 149M 119M sbwait 1 376:03 0.00% postgres
2051 pgsql 1 44 0 62944K 34836K select 1 21:39 0.00% postgres
2054 pgsql 1 44 0 31672K 4220K select 1 6:31 0.00% postgres
2052 pgsql 1 44 0 62944K 5368K select 0 6:00 0.00% postgres
2053 pgsql 1 44 0 62944K 5484K select 1 1:11 0.00% postgres
4884 pgsql 1 44 0 62944K 9144K sbwait 1 1:00 0.00% postgres
1902 pgsql 1 44 0 62944K 5348K select 1 0:46 0.00% postgres
Суммируем резидента (RES) размер для каждого процесса, связанного с вашим приложением, и обратите внимание, что в качестве используемой оперативной памяти. (разница между резидентным размером и виртуальным размером (VSIZE, или просто SIZE).
При использовании этого метода есть некоторые предостережения:
Инфляция или дефляция размера
RESРазмер идентификатора не раскрывает всей картины: загружаются общие библиотеки, и они не учитываются в резидентном размере, поэтому, если вы суммируете размер резидента, как я сказал выше, ваше число будет ниже фактического использования.
Общие библиотеки ЯВЛЯЮТСЯ считается в виртуальном размере, (VIRT или просто SIZE), но они учитываются для каждой программы, использующей их, поэтому, если вы суммируете виртуальный размер, ваше число будет выше фактического использования - часто значительно выше.
Некоторые версии top также разделите Swap отдельно - если ваша программа имеет утечку памяти (или много данных, которые устаревают и выгружаются), это также может исказить ваши цифры.
Отсутствующие процессы
Если вы не подсчитываете все связанные процессы, которые возникают в результате запуска вашей программы, ваш общий показатель использования ОЗУ будет ниже фактического.
Наконец, есть одно предостережение, относящееся к обоим этим методам: Динамические приложения испортят ваши числа.
Под этим я подразумеваю, что такая программа, как Postgres или Apache, которая либо порождает новые потоки, либо новые дочерние процессы для обслуживания запросов пользователей, не будет давать точной картины в статических условиях: вам нужно создать рабочую нагрузку на программу, чтобы вы могли измерить влияние рабочей нагрузки на систему (это еще одна причина, по которой я считаю, что совокупный путь проще: вам не нужно выслеживать всех дочерних элементов, вы можете просто прочитать заголовок по мере увеличения рабочей нагрузки).
В идеале вы должны сильно нагружать сервер во время тестирования, чтобы гарантировать, что нормальные производственные нагрузки не заставят его начать загружать пространство подкачки. Кроме того, после того, как вы сделали свой размер, вы всегда должны добавлять немного амортизирующей ОЗУ (я использую 10% сверх наихудших рабочих результатов) и убедитесь, что ваша система имеет достаточно ОЗУ для обработки этого в качестве условия пиковой нагрузки.
Помните: ОЗУ дешево, а время простоя - дорого. Вы всегда можете добавить больше ОЗУ для решения проблемы во время сборки сервера, и предельные затраты, вероятно, будут ниже, чем необходимость выключения системы для добавления ОЗУ позже.
Обратите внимание, что все мои top вывод из FreeBSD - ваша конкретная маркировка может отличаться. Обратитесь к странице руководства для top в вашей системе, чтобы определить соответствующие поля.