A soma de todos os PIDs “utime” é o total de utime do sistema?

Para medir o tempo total de CPU de um usuário, estou usando o campo "utime" em /proc/[pid]/stat:

utime %lu   Amount of time that this process has been scheduled in user
            mode, measured in clock ticks (divide by
            sysconf(_SC_CLK_TCK).  This includes guest time, guest_time
            (time spent running a virtual CPU, see below), so that
            applications that are not aware of the guest time field do
            not lose that time from their calculations.

(do homem proc (5) )

Portanto, meu "user utime" é a soma utimede todos os PIDs que este usuário está executando.

Espero que isso me dê um valor exato para o número de segundos de CPU que esse usuário gastou. Estou no caminho certo?

Algumas das coisas que ainda não entendo ou levo em consideração:

Cada PID também possui um PID pai (ou zero). Mas estou contando todos os PID, não apenas aqueles com um ppid de 0. Isso está correto?
Existem, além do horário de trabalho, horário, horário e horário. Preciso me preocupar com isso? Estou assumindo que utime é o número total de segundos da CPU para um PID, sem contar o pai.

Se eu calcular o tempo total da CPU do sistema usando /proc/uptime, esse valor será bastante próximo da minha soma para todos os usuários, mas a diferença é significativa. Por exemplo (em minutos):

system cpu_time:         96.13
sum of users_cputime:   111.45

Correção:

Recebo valores de "aparência sensata" para todos os tipos de coisas. No momento, estou usando a soma de utime, stime, cutime e cstime. E relata valores que, embora eu não os entenda, se correlacionam muito bem com as medidas de time.

Se eu estou completamente no caminho errado, há outra pergunta:

Qual é a maneira mais justa de monitorar o tempo total de CPU - por usuário? (+500 Recompensas) no Ask Ubuntu

process cpu proc

— Stefano Palazzo
fonte

/proc/cputimenão possui nenhuma informação sobre o tempo gasto pelos processos de execução das CPUs, por isso estou intrigado com o cálculo do seu "system cpu_time". Se você estiver fazendo algo com o segundo número, é o tempo gasto na tarefa inativa ; Não sei exatamente o que isso significa na prática.

— Gilles 'SO- stop be evil'

Seu "tempo de usuário" teria que adicionar os valores de utime de todos os processos mortos também. Como você leva isso em consideração?

— Gilles 'SO- stop be evil'

Mhh. O que chamo de "tempo da CPU do sistema" é apenas o primeiro valor de / proc / uptime, "segundos do sistema". Eu pensaria que isso era muito alto, pois também conta com os threads do kernel, mas como você pode ver, a soma de todos os valores de "utime" ainda é maior que a hora do sistema em / proc / utime. O seu link, até onde eu sei, explica o porquê. Embora fique claro: não estou realmente interessado nesse número. Estou interessado em "tempo de CPU por usuário".

— Stefano Palazzo

Quanto ao segundo comentário: No momento, eu estava planejando medir isso periodicamente (digamos a cada segundo), o que ignoraria os processos de vida curta.

— Stefano Palazzo

Portanto, o cálculo do tempo da CPU do sistema é ($ 1- $ 2 / $ number_of_cups) de onde $ 1 e $ 2 são os valores /proc/uptime? Então acho que a E / S atribuída à tarefa ociosa explicaria a diferença. Como não sei nada sobre o assunto, suspeito que esteja perdendo algo importante: não esperaria que muita coisa acontecesse na tarefa ociosa, especialmente considerando que sua soma de cputime de usuários provavelmente está perdendo muito tempo. processos vividos.

— Gilles 'SO- stop be evil'

A maneira tradicional de registrar e rastrear o tempo de CPU do usuário é a contabilidade do processo . No Linux, instale os utilitários de contabilidade GNU , geralmente fornecidos por um pacote chamado acct. Não tenho certeza de quão preciso será em acompanhar o tempo gasto em processos de vida muito curta, mas pelo menos listará todos os processos já executados.

Execute lastcommpara obter uma lista de todos os comandos executados por qualquer usuário e o tempo gasto em cada um (arredondado para ~ 10ms para processos de curta duração, esperamos ver muitos 0.00). Execute sapara exibir várias somas e estatísticas. Em particular, sa -mexibe totais por usuário. As estatísticas acumuladas por saexecução a partir da última rotação dos logs contábeis (normalmente localizadas em /var/log/account/).

Observe que você não irá capturar todos os processos amostrando a intervalos, e não muito longe. Você perderá quase todos os processos de vida curta e os últimos segundos de processos longos. A contabilidade de processos lista todos os processos anteriores.

Em /proc/$pid/stat, o tempo do usuário é o tempo gasto na computação, em oposição ao tempo do sistema gasto na E / S. Qual contar depende do que você deseja fazer com as informações.

Contar todos os PIDs está certo. Não sei o que o pai PID tem a ver com isso.

No lado do sistema, sua descrição /proc/uptimeparece errada. A Wikipedia está certa como eu escrevo. O primeiro campo é o tempo real decorrido desde a inicialização do sistema, menos o tempo gasto em suspensão ou hibernação. O segundo campo é o tempo acumulado gasto na tarefa inativa em todas as CPUs. Não tenho certeza do que isso realmente significa; certamente não é o tempo total ocioso na minha máquina. No kernel, o valor é somado na partir de variáveis atualizados em .uptime_proc_showaccount_idle_time

— Gilles 'SO- parar de ser mau'
fonte

E quanto aos processos de execução muito longos? Aguarda o saencerramento do processo antes de informar que é hora da CPU?

— Stefano Palazzo

@StefanoPalazzo Sim, os dados contábeis são gravados quando um processo morre. Isso também significa que você não obtém dados para processos que estavam sendo executados após uma falha no sistema, tanto quanto eu sei.

— Gilles 'SO- stop be evil'

Isso é um problema - significa que não posso usá-lo, pois teremos muitos processos de execução longa.

— Stefano Palazzo