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

Я только что проверил свой 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
  • Откуда они взялись?

2 Solutions collect form web for “Перфорированное прерывание заняло слишком много времени, но перфорация не была установлена”

Это сообщение приходит из ядра 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 .

Interesting Posts

Какие исправления Debian исправляют shellshock lcamtuf CVE-2014-6277 и CVE-2014-6278?

Как найти файлы, заканчивающиеся на ~ и pyc?

Как исправить графические проблемы с приложениями Qt? (дельфин: 14635): Gdk-WARNING **: ошибка shmget: ошибка 28 (на устройстве не осталось места)

Почему ln -s не говорит, что сбой при создании символической ссылки на существующий символический каталог?

tar: исключить gzip-файл и не пытаться его уничтожить

Не удалось восстановить grub2 после установки arch-linux

Команда sudo service не найдена при установке mongodb

Параметр rsync для исключения частичных файлов

Ноутбук дает бесконечный ввод клавиатуры для любого дистрибутива Linux

Измените приглашение при запуске терминала из сценария bash (но не затрагивайте все терминалы)

Являются ли определенные части сценариев запуска необходимыми или просто хорошей практикой?

Ремонт отказов RAID6?

Пользовательский режим linux сразу прерывается

Найдите идентификатор процесса приложения java в сценарии bash (чтобы узнать, запущено ли целевое приложение)

использование ключа GPG в Gajim без кодовой фразы

Linux и Unix - лучшая ОС в мире.