perf interrupt demorou muito mas o perf não foi instalado

Question

Acabei de verificar meu dmesg porque meu servidor começa a travar de vez em quando. Lá eu li a seguinte linha:

perf interrupt took too long (2528 > 2500), lowering kernel.perf_event_max_sample_rate to 50000

que aparece algumas vezes.
Lembro-me de perf ser uma ferramenta de análise de desempenho e não me lembro de tê-lo instalado. Então eu verifiquei:

~$ dpkg -l *perf*
dpkg-query: no packages found matching *perf*

Minhas perguntas:

• Isso é um sinal de uma tempestade que se aproxima. Porque esta linha vem algumas vezes e depois há dumps de pilha começando com rcu_sched detected stalls
• De onde eles vêm?

Answer 1

Esta mensagem vem do kernel do linux. Mais precisamente, ele vem do perf_duration function em linux/kernel/events/core.c :

static void perf_duration_warn(struct irq_work *w)
{
    printk_ratelimited(KERN_INFO
        "perf: interrupt took too long (%lld > %lld), lowering "
        "kernel.perf_event_max_sample_rate to %d\n",
        __report_avg, __report_allowed,
        sysctl_perf_event_sample_rate);
}

Eu não sei exatamente o que você quer dizer com:

Is this a sign of an oncoming storm?

mas suspeito de problemas com um dos seus dispositivos.

P.S .: Se você ler atentamente, verá que no código a mensagem é perf: interrupt took too long , mas sua mensagem é perf interrupt took too long . Os dois pontos foram adicionados na versão 4.6 do kernel.

    

Answer 2

Eu recebi uma mensagem semelhante há algum tempo no meu sistema Desktop. Ele aparece após um ou vários núcleos ficarem inativos em E / S de disco ininterrupto ( D in ps ) por minutos ou mais. Eu suspeito de alguma condição de corrida no planejamento de E / S que leva ao deadlock, mas não sei como depurar isso. Mudar para o agendador de prazo para o disco apropriado, em vez de CFQ, parece ajudar:

# echo deadline > /sys/block/sdX/queue/scheduler 

Eu observei pausas curtas no agendamento com isso, mas a segunda fila do agendador de prazo parece atenuar a longa paralisação.

Se alguém pudesse lançar mais alguma luz sobre isso, eu também apreciaria isso.

Editar

Não sei se os rcu_sched errors / warnings estão relacionados, mas é bem possível. Eu não os obtenho, porque meu kernel é configurado de maneira diferente.

Quando um núcleo está parado, o que vejo com ps é

$ ps axu | grep ' D'
dirk      4720 13.0  5.1 1615772 842444 pts/3  Dl+  07:27  24:54 iceweasel -P default

para o processo que estava fazendo o I / O. D significa "sono ininterrupto (geralmente I / O)" de acordo com man ps .