Да, я читал, что это нормально, но в моем случае несоответствие огромно, и я не могу это объяснить, просто посмотрите:
Я побежал sar
команда на некоторое время (последние строки):
04:53:01 PM all 0.40 0.00 3.41 0.00 0.00 96.19
04:53:06 PM all 0.40 0.00 3.01 0.00 0.00 96.59
04:53:11 PM all 0.80 0.00 3.81 0.00 0.00 95.39
04:53:16 PM all 1.60 0.00 2.81 0.00 0.00 95.59
04:53:21 PM all 0.40 0.00 3.21 0.00 0.00 96.39
04:53:26 PM all 0.80 0.00 2.81 0.00 0.00 96.39
Average: all 0.76 0.00 2.97 0.01 0.01 96.25
А это CloudWatch за то же время:
у меня есть cpulimit
(https://github.com/opsengine/cpulimit) демон установлен (как описано здесь, адаптированный для Amazon Linux). Я использую микро-экземпляр, поэтому использую cpulimit (чтобы избежать троттлинга). Поэтому, когда я включаю его, использование CloudWatch подскакивает ровно до 40%, а в отчете top / sar ± 1%. Когда я его выключаю, CloudWatch сообщает ± 1%, как и top / sar.
Есть идеи здесь? Это сбой, или я использую неправильные инструменты (или неправильные инструменты)?
Редактировать: Я провел несколько экспериментов, используя этот замечательный инструмент и пришел к интересным результатам. По сути,% ЦП CloudWatch не связан линейно с% верхнего ЦП. Это приблизительные результаты:
Top% CW% Steal%
4% 40% 0%
10% 85% 0%
20% 100% 0%
50% 100% 30%
Оптимальная нагрузка 20%, это именно то, что был описан здесь. Проблема в том, что он делает утилиту ЦП CloudWatch бесполезной для микро-экземпляра.
Вам выделяется только часть процессора. Sar измеряет использование всего ЦП, а cloudwatch измеряет использование доли. Судя по графику, вам выделено 0,075 ЦП.