Проверить, не менялась ли исторически тактовая частота процессора в RHEL6
getrusage (2)предложения RUSAGE_SELFили RUSAGE_CHILDREN; вызывающая оболочка может использовать только RUSAGE_CHILDREN, который будет включать ваш процесс, а также дочерние элементы этого процесса. Поэтому, как указывает Стефан Шазела , ваш процесс должен будет вызватьgetrusage(RUSAGE_SELF, &usage)изнутри себя , что, если ваш процесс нельзя отредактировать, это должно произойти с помощью некоторого LD_PRELOADтрюка.
Другим вариантом может быть использование средств профилирования ядра типа DTrace или SystemTap для отчета об использовании во время выхода из процесса; следующие отчеты все значения выхода процесса:
probe kprocess.exit {
printf("%s[%d]: %s\n %s\n %s\n\n",
execname(), pid(), cmdline_str(),
task_time_string(),
proc_mem_string()
);
}
мы также можем профилировать определенный PID или имя исполняемого файла с помощью соответствующего кода, здесь снова с помощью SystemTap:
probe kprocess.exit {
if (pid() != target()) next;
printf("%s[%d]: %s\n", execname(), pid(), task_time_string());
}
Хотя это может потребовать дополнительного тестирования, чтобы подтвердить, что происходит, когда вместо этого процесс уничтожается сигналом и т. д.
Даже в не -виртуализированной среде lscpuи /proc/cpuinfoмогут возвращать неверные значения.
Но в виртуализированной среде хост виртуальной машины может предоставлять вам произвольные значения через эти интерфейсы.
Обычно можно использовать некоторые счетчики ЦП для получения реальной частоты ЦП.
Но держу пари, что хост виртуальной машины также может манипулировать такими счетчиками.
Если вы доверяете хосту виртуальной машины и знаете, что информация, доступная через /proc/cpuinfo, правдоподобна, вы можете использовать стандартный агент сбора метрик, такой как telegraf или collectd, в своей гостевой виртуальной машине и настроить его для периодического чтения значения из этого файла. (или выполните вспомогательный скрипт, предоставляющий это значение в стандартном формате ).