Присоединился: 2 года назад
В данном тригере используется, как я понял, макрос $MEMORY.UTIL.MAX
Курю уже не первые сутки, как можно поменять значение данного макроса?Вменяемой информации пока не нашел.
по дефолту $MEMORY.UTIL.MAX имеет значение 0,9 (90%), а это для многих производственных сред (в частности MS SQL Server, который резервирует и не освобождает себе память) слишком низкое значение, я бы его поднял до 98%
Аналогичные проблемы с утилизацией места на дисках. Если диск большого объема, то ворнинги на 80% и критическое значение в 90% явно занижены для боевой среды.в данном случае, вроде, макрос $VFS.FS.PUSED.MAX.CRIT и $VFS.FS.PUSED.MAX.WARN
Присоединился: 9 лет назад
макрос, если я правильно понимаю, что это макрос, т.к. начинается на $? на скриншоте выделил, но где его найти так и не нашел
Кстати, еще момент, т.к. триггер унаследовался через 2 шаблона, то не могу его на хосте отредактировать. Я правильно понял этот момент?
Это сообщение было изменено 2 года назад 2 раз от pk
Англо-русский толковый словарь терминов и сокращений по ВТ, Интернету и программированию. .
.
Смотреть что такое «CPU utilization» в других словарях
Доступная память: доступная память = свободная + буферы + кэшированные, т.е. 308 = 209 + 6 + 92Используемая память: Used memory = used-buffers-cached, то есть 686 = 785-6-92
2. Изменить тип и формулуТип выберите Расчетный # Тип расчета
Если состояние элементов или триггера не поддерживается, возможно, возникла проблема с выражением, и вам необходимо проверить и протестировать
Память меньше 10%. В настоящее время ресурсы памяти сервера фактически ограничены. Вы можете использовать этот триггер для запуска сценария для перезапуска служб, которые занимают больше памяти. Как правило, службы на сервере относительно фиксированы. Те, кто потребляет больше памяти, — это те , Вы можете выбрать несколько перезапусков (один экземпляр с осторожностью), и лучше всего контролировать службу, чтобы избежать сценария автоматического перезапуска службы, не запускающего службу.
Универсальный англо-русский словарь.
.
.
Смотреть что такое «memory utilization» в других словарях
Как обычно, Duncan Epping написал отличный пост об использовании памяти виртуальными машинами на хостах VMware ESX. Постараемся объяснить это на русском языке. Итак, если открыть вкладку Summary в vSphere Client для виртуальной машины, мы увидим вот такую картину:
Здесь есть 2 главных параметра:
- Memory — это то количество оперативной памяти, которое вы выделили виртуальной машине при создании. За это количество гостевая ОС не выйдет при ее использовании. Это же количество памяти вы увидите в гостевой ОС.
- Memory Overhead — это количество памяти, которое может потребоваться гипервизору на поддержание работы виртуальной машины сверх используемой памяти (т.е. расчетные накладные расходы на виртуализацию, но не текущие).
Далее мы видим панель Resources, здесь есть такие показатели:
- Consumed Host Memory — это количество физической памяти хоста ESX, выделенной виртуальной машине. Обычно это значение не больше значения Memory на предыдущей картинке. Но может быть и больше, поскольку Consumed Host Memory включает в себя и Memory Overhead, но не с картинки выше, а реально используемый гипервизором Overhead (о котором будет идти речь ниже). И важный момент — счетчик Consumed для Memory на вкладке «Performance» не включает в себя Overhead.
- Active Guest Memory — это количество памяти, которое по мнению гипервизора VMkernel активно используется гостевой операционной системой. Вычисляется этот параметр на базе статистических показателей. То есть, если ОС не очень активно использует память, то можно ей ее немного подрезать в условиях нехватки ресурсов.
Теперь идем на вкладку «Resource Allocation». Здесь все немного сложнее:
Появляются вот такие показатели:
Для Host Memory (видим, что это 2187 МБ = сконфигурированная память 2048 МБ + Overhead):
- Consumed — это, опять-таки, объем потребляемой виртуальной машиной физической памяти хоста ESX (постоянно меняется). И он включает в себя накладные расходы гипервизора по памяти.
- Overhead Consumption — это текущий объем затрат памяти на поддержание виртуальной машины (здесь 42 МБ в отличие от расчетного в 110 МБ)
А формула такова: Consumed = Private + Overhead Comsumption
Для Guest Memory (2048 МБ сконфигурировано в настройках):
- Private — это объем памяти физически хранимый хостом для виртуальной машины (см. формулу выше).
- Swapped — это объем памяти, ушедший в файл подкачки vswp. То есть это не файл подкачки Windows, а файл подкачки в папке с виртуальной машиной. Само собой этот показатель должен быть нулевым или совсем небольшим, поскольку своппинг, который делает ESX (а точнее VMkernel) — это плохо, т.к. он не знает (в отличие от Windows), какие страницы нужно складывать в своп, поэтому кладет все подряд.
- Compressed — это объем памяти, который получен после сжатия страниц с помощью механизма Memory Compression (то есть, хранимый в VM Compression Cache).
- Ballooned — это объем памяти, который забрал balloon-драйвер (vmmemctl), чтобы отдать ее другим нуждающимся виртуальным машинам.
- Unaccessed — это память, к которой гостевая ОС ни разу не обращалась (у Windows — это близко к нулю, так как она обнуляет память при загрузке, у Linux должно быть как-то иначе).
- Active — опять-таки, активно используемая память на основе статистики гипервизора.
На хорошем и производительном хосте VMware ESX метрики Compressed, Ballooned, Unaccessed — должны быть около нуля, так как это означает что машины не борются за ресурсы (то есть не сжимают страницы и не перераспределяют память между собой). Ну и, конечно, если показатель Active маленький, стоит задуматься об урезании памяти (но сначала посмотрите в гостевую ОС, она лучше знает, чем гипервизор, все-таки).
Ну и последняя секция Resource Settings:
- Worst Case Allocation — это сколько будет выделено виртуальной машине при самом плохом раскладе (максимальное использование ресурсов), то есть вся память будет использоваться, да еще и накладные расходы будут (т.е., Configured + максимальный Overhead).
- Overhead Reservation — это сколько зарезервировано памяти под Overhead гипервизором.
Ну и в заключение очень рекомендую документ «The Yin and Yang of Memory Overcommitment in Virtualization» — как раз для VMware vSphere.
