Estou investigando o desempenho de um servidor de banco de dados multithread. Existe uma carga de trabalho específica que é executada em aproximadamente 61 segundos em uma máquina específica. O pid do processo de banco de dados era 79894 quando executei perf na carga de trabalho.
Além dos threads de software no servidor de banco de dados, há vários threads relacionados ao Linux, que normalmente ficam inativos em um sistema inativo, que se tornam ativos enquanto minha carga de trabalho está em execução. Portanto, quero usar a opção -a de perf, bem como a opção -p.
Eu executo perf de duas maneiras e obtenho resultados um pouco diferentes em cada maneira.
As primeiras maneiras de executar o seguinte comando perf em uma janela
perf stat -p 2413 -a
e execute imediatamente a carga de trabalho do banco de dados em outra janela. Quando a carga de trabalho do banco de dados termina, eu controlo C fora do desempenho e obtenho os seguintes resultados
Performance counter stats for process id '79894':
1,842,359.55 msec cpu-clock # 30.061 CPUs utilized
3,798,673 context-switches # 0.002 M/sec
153,995 cpu-migrations # 0.084 K/sec
16,038,992 page-faults # 0.009 M/sec
4,939,131,149,436 cycles # 2.681 GHz
3,924,220,386,428 stalled-cycles-frontend # 79.45% frontend cycles idle
3,418,137,943,654 instructions # 0.69 insn per cycle
# 1.15 stalled cycles per insn
402,389,588,237 branches # 218.410 M/sec
5,137,510,170 branch-misses # 1.28% of all branches
61.28834199 seconds time elapsed
O segundo método é executar
perf stat -a sleep 61
em uma janela e execute imediatamente a carga de trabalho do banco de dados em outra janela. Após 61 segundos, o perf e a carga de trabalho terminam e o perf produz os seguintes resultados
Performance counter stats for 'system wide':
4,880,317.67 msec cpu-clock # 79.964 CPUs utilized
8,274,996 context-switches # 0.002 M/sec
202,832 cpu-migrations # 0.042 K/sec
14,605,246 page-faults # 0.003 M/sec
5,022,298,186,711 cycles # 1.029 GHz
7,599,517,323,727 stalled-cycles-frontend # 151.32% frontend cycles idle
3,421,512,233,294 instructions # 0.68 insn per cycle
# 2.22 stalled cycles per insn
402,726,487,019 branches # 82.521 M/sec
5,124,543,680 branch-misses # 1.27% of all branches
61.031494851 seconds time elapsed
Como usei -a em ambas as versões, esperava obter aproximadamente os mesmos resultados.
Mas com o sono,
cpu-clock is 2.5 times what you get with the -p version,
context-switches are double what you get with the -p version
and the other values are more or less the same
Então, 2 perguntas,
(1) which set of results do I believe?
and
(2) how can there be more stalled-cycles-frontend than cycles in the sleep version?