perf 中断时间太长但 perf 未安装

Question

我刚刚检查了我的服务器，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*

我的问题：

• 这是暴风雨即将来临的征兆吗？因为这一行出现了几次，然后出现了以以下开头的堆栈转储rcu_sched detected stalls
• 这些从哪里来？

Answer 1

该消息来自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 中添加的。

Answer 2

一段时间以来，我的桌面系统上一直出现类似的消息。它会在一个或有时几个核心在不间断磁盘 I/O ( Din ps) 中停滞几分钟或更长时间后出现。我怀疑 I/O 调度中的某些竞争条件会导致死锁，但不知道如何调试它。切换到适当磁盘的截止时间调度程序而不是 CFQ 似乎有帮助：

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

我观察到调度过程中有短暂的暂停，但截止日期调度程序的第二个队列似乎减轻了长时间的停顿。

如果有人能对此有更多的了解，我也将不胜感激。

编辑

我不知道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

用于执行 I/O 的进程。D根据 ，表示“不间断睡眠（通常是 I/O）” man ps。

Answer 3

如果您正在加密交换空间，则可能会经常引发此错误。

经常。

dm_crypt 是罪魁祸首。

虽然没有丢失信息。