如何更好地诊断哪个客户端导致高 Xorg CPU 使用率?

How to better diagnose which client is causing high Xorg CPU usage?

我遇到了 Xorg 服务器突然变慢并且 CPU 使用率达到 100% 的问题。对此进行谷歌搜索表明,此问题的 "state of art" 调试方法是开始随机杀死 X 客户端,直到问题消失,然后您就知道哪个客户端是有问题的(祝您好运,在杀死它后尝试调试进程) . None 的 X 客户正在吃很多 CPU(每人最多约占 CPU 的 1%)。并且系统还有 2GB 的可用内存。

有人知道更好地诊断问题的方法吗? 基本上我正在寻找 top Xorg 的替代品,它将直接指向客户端进程导致大多数 CPU 使用 Xorg。我已经知道 xrestop 这与 Xorg 内存使用情况相同,但这个问题专门针对 CPU 用法。

造成此速度下降的另一个原因可能是 运行 GPU 内存不足,这可能会导致通过 PCI-express 总线推送位图,而不是直接从 GPU 内存渲染以显示。如果这在内核级别显示为 CPU 使用情况(例如 top),这可能是我遇到的问题,但我想更好地了解原因。当我从有问题的系统写这篇文章时,似乎大多数减速发生在输入处理或字体渲染中,但我不知道如何更好地诊断这个问题。

我知道 可能 使用另一台计算机并连接 ssh,将 gdb 进程附加到有问题的 Xorg 服务器并开始挖掘,但我希望能轻松一点。

如果我得到了问题客户端的 PID 甚至 window 句柄,找出根本原因会更容易(例如 https://unix.stackexchange.com/q/5478)。而且我不需要杀死表现良好的进程作为副作用。

这是一个脚本,用于确定是否是某个客户端导致了问题(尽管对我的问题没有帮助):

#!/bin/bash

WINDOW_IDS=$(xwininfo -tree -root | grep -o -P '\b0x[0-9a-f]+' | sort -u)

PIDS=""
for ID in $WINDOW_IDS
do
    if [ "$ID" = "0x0" ]
    then
        continue
    fi
    #printf "Window %s PID=" "$ID" 
    PID=$(LC_ALL=C xprop -id "$ID" _NET_WM_PID | cut -d' ' -f3-)
    if [ "$PID" = "not found." ]
    then
    #   printf "%s\n" "(unknown)"
    #   See also: https://unix.stackexchange.com/a/84981
        true
    else
    #   printf "%s\n" "$PID"
        PIDS="$PIDS $PID"
    fi
done

PIDS=$(printf "%s\n" $PIDS | sort -u)

# go through the list of processes connected to Xorg:

for PID in $PIDS
do
    printf "%s: %s\n" "$PID" "$(cat /proc/$PID/cmdline)"
    sleep 0.1s # wait for the previous line to get on the screen before stopping e.g. compositing manager 
    # Stop the process for 5 secs and let the process continue after that.
    kill -STOP "$PID" && sleep 1s && kill -CONT "$PID"
done

我们的想法是让每个客户端依次停止 5 秒,如果这可以解决问题 5 秒,那么您就找到了问题所在。此脚本将 SIGSTOP 发送到无法忽略的目标进程,并阻止目标进程获得 CPU 时间,因此它也无法将任何事件发送到 Xorg。请注意,如果您在中间终止此脚本,您可能会以其中一个进程处于 STOPPED 状态而告终。发送 SIGCONT 来解决问题。如果您等待脚本完成,一切都应该没问题。 (另请参阅:https://unix.stackexchange.com/a/298650

就我而言,无论哪个客户端停止,Xorg 都会继续变慢,所以我猜我看到的问题是内部 Xorg 问题,我需要使用 FlameGraphs (http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html) 来找出问题的真正原因。