Перфорированное прерывание заняло слишком много времени, но перфорация не была установлена

Я только что проверил свой dmesg потому что мой сервер начинает крутиться сейчас и потом. Там я прочитал следующую строку:

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

который появляется пару раз.
Я помню, что perf является инструментом анализа эффективности и не помню, чтобы он был установлен. Поэтому я проверил:

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

Мои вопросы:

  • Является ли это признаком надвигающейся бури. Поскольку эта строка приходит несколько раз, а затем есть stackdumps, начиная с rcu_sched detected stalls
  • Откуда они взялись?

Это сообщение приходит из ядра linux. Точнее это происходит от perf_duration function в 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); } 

Я не знаю, что вы точно подразумеваете:

Является ли это признаком надвигающейся бури?

но я подозреваю проблемы с одним из ваших устройств.

PS: Если вы внимательно прочитаете, вы увидите, что в коде сообщение является perf: interrupt took too long но ваше сообщение является perf interrupt took too long . Точка с запятой была добавлена ​​в версии 4.6 ядра.

У меня было подобное сообщение в течение некоторого времени на моей настольной системе. Он появляется после того, как один или иногда несколько ядер останавливаются в непрерывном дискретном вводе / выводе ( D в ps ) в течение нескольких минут или дольше. Я подозреваю, что некоторые условия гонки в планировании ввода-вывода приводят к тупиковой ситуации, но не знают, как отлаживать это. Переключение на планировщик крайних сроков для соответствующего диска вместо CFQ, похоже, помогает:

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

Я наблюдал короткие паузы при планировании с этим, но вторая очередь планировщика крайних сроков, похоже, уменьшает длительный лабиринт.

Если бы кто-то мог пролить свет на это, я тоже был бы признателен.

редактировать

Я не знаю, rcu_sched ли связанные с rcu_sched ошибки / предупреждения, но это вполне возможно. Я не получаю их, возможно, потому что мое ядро ​​настроено по-другому.

Когда одно ядро ​​застопорилось, то, что я вижу с ps ,

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

для процесса, который выполнял операции ввода-вывода. D означает «бесперебойный сон (обычно I / O)» согласно man ps .