代码之家 › 专栏 › 技术社区 › Mikko Rantalainen

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

xorg debugging ubuntu performance linux

3

Mikko Rantalainen · 技术社区 · 7 年前

我在哪里有问题 Xorg服务器突然变得非常慢,CPU使用率达到100% 。通过谷歌搜索这一问题表明,解决这个问题的“最先进”调试方法是开始随机杀死X个客户端,直到问题消失,然后你就知道哪个客户端是有问题的(祝你在杀死它后尝试调试进程好运)。没有一个X客户机占用大量CPU(每个客户机最多占用1%的CPU)。系统仍然有2GB的可用RAM。

有人知道更好地诊断问题的方法吗? 基本上我在找 top 替换Xorg,它会直接将我指向导致Xorg大部分CPU使用的客户端进程。我已经知道了 xrestop 这与Xorg内存使用情况相同,但这个问题是关于CPU使用情况的。

另一个原因可能是GPU内存不足,这可能会导致通过PCI express总线推送位图,而不是直接从GPU内存渲染显示。如果这显示为内核级别的CPU使用率(例如。 顶部 ),这可能是我看到的问题,但我想更好地理解原因。当我在这个有问题的系统上写这篇文章时,似乎大多数的减速都发生在输入处理或字体呈现上,但我不知道如何更好地诊断这个问题。

我知道是 可能的 使用另一台计算机并连接到 ssh ,附上 gdb 处理到有问题的Xorg服务器并开始挖掘,但我希望有更简单的方法。

如果我得到了问题客户端的PID甚至窗口句柄,那么找出根本原因会更容易(例如。 https://unix.stackexchange.com/q/5478 ).我也不需要因为副作用而扼杀行为良好的过程。

1 回复 | 直到 7 年前

1

Mikko Rantalainen 7 年前

下面是一个脚本,用于确定是否是某个客户机导致了问题(尽管没有帮助解决我的问题):

#!/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发送任何事件。请注意,如果中途终止此脚本,可能会导致某个进程处于停止状态。邮寄 SIGCONT 来解决这个问题。如果你等脚本完成,一切都会好起来。(另见: https://unix.stackexchange.com/a/298650 )

在我的例子中,无论哪个客户端被停止,Xorg都会一直运行缓慢,所以我想我看到的问题是Xorg内部的问题,我需要使用FlameGraphs( http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html )找出问题的真正原因。