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

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

  • Ядро Паника из-за ОЗУ?
  • Приостановка процесса с помощью -SIGSTOP для достаточно длинных причин. Ядро Oops Stack Overflow
  • Загрузка «Linux from Scratch» не вызывает # подсказки
  • Знайте, когда адрес памяти выровнен или не выровнен
  • Запуск массива btrfs RAID 5 в Arch Linux
  • Как прокручиваться после паники ядра?
  • Использование пользовательского имени для корневого устройства в GRUB
  • Слишком маленькая ошибка области Hotplug
  • 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

    создавать исполняемые файлы по трубопроводам

    Как установить определенную версию reiserfsprogs?

    Является ли Linux действительно вредоносным ПО безопасным? Или люди просто не хотят создавать их для Linux?

    Как заставить OpenVPN автоматически подключаться к шлюзу в любое время

    Можно ли использовать XNU на GNU / Linux?

    Использование более или менее в этом сценарии

    Как пропустить ошибки разрешенного отказа при запуске find в Linux?

    Netid в ss-продукте запутывает

    хотите последнюю строку при дублировании awk?

    Установка раздела Windows без разрешения на выполнение

    Как последний «Bash Bug» или эксплоит затрагивают системы, требующие аутентификации?

    Пользователь, не являющийся пользователем Samba, не может писать для совместного использования

    вывод команды команды в переменную

    Поведение Rsync с измененными файлами

    LD_LIBRARY_PATH потерян при использовании команды mount

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