web-dev-qa-db-ja.com

perf割り込みに時間がかかりすぎたが、perfがインストールされていない

サーバーがときどきクラッシュし始めるので、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で始まるスタックダンプがあるため
  • これらはどこから来たのですか？
kernel-panicperf
7
Martin B.

このメッセージはLinuxカーネルからのものです。より正確には perf_duration functionlinux/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);
}

私はあなたが正確に何を意味するのかわかりません：

これは嵐の兆候ですか？

しかし、私はあなたのデバイスの1つに問題を疑っています。

PS：注意深く読むと、コードにメッセージがperf: interrupt took too longですが、メッセージはperf interrupt took too long。コロンはカーネルバージョン4.6で追加されました。

4
Ortomala Lokni

しばらくの間、デスクトップシステムに同様のメッセージが表示されました。無停電ディスクI/O（D内のps）で1つまたは複数のコアが数分以上ストールした後に表示されます。デッドロックにつながるI/Oスケジューリングの競合状態が疑われますが、これをデバッグする方法がわかりません。 CFQの代わりに適切なディスクのデッドラインスケジューラに切り替えると役立つようです。

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

私はそれを使ってスケジューリングの短い一時停止を観察しましたが、デッドラインスケジューラの2番目のキューは長いストールを軽減するようです。

誰かがこれについてもう少し光を当てることができれば、私もそれを感謝します。

編集

rcu_schedエラー/警告が関連しているかどうかはわかりませんが、可能性は十分にあります。カーネルの設定が異なるため、取得できません。

1つのコアが停止している場合、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は、man psによると、「割り込み不可能なスリープ（通常はI/O）」を意味します。

3
dirkt