【发布时间】:2018-09-06 10:25:32
【问题描述】:
我遇到了问题,Xorg 服务器突然变得非常慢并且它的 CPU 使用率达到 100%。谷歌搜索表明这个问题的“最先进”调试方法是开始随机杀死 X 客户端,直到问题消失,然后你知道哪个客户端是有问题的客户端(祝你好运,在杀死它后尝试调试进程) .没有一个 X 客户端正在消耗大量 CPU(每个最多大约 1% 的 CPU)。而且系统还有 2GB 的可用 RAM。
有人知道更好地诊断问题的方法吗? 基本上我正在寻找 Xorg 的 top 替代品,这将直接指向导致 Xorg 占用 CPU 最多的客户端进程.我已经知道xrestop 这与 Xorg 内存使用情况相同,但这个问题专门针对 CPU 使用情况。
导致速度变慢的另一个原因可能是 GPU 内存不足,这可能会导致通过 PCI-express 总线推送位图,而不是直接从 GPU 内存渲染到显示器。如果这显示为内核级别的 CPU 使用率(例如top),这可能是我看到的问题,但我想更好地了解原因。当我从有问题的系统中写这篇文章时,似乎大多数减速都发生在输入处理或字体渲染中,但我不知道如何更好地诊断。
我知道可能使用另一台计算机并与ssh 连接,将gdb 进程附加到有问题的Xorg 服务器并开始挖掘,但我希望能更容易一些。
如果我得到问题客户端的 PID 甚至窗口句柄,找出根本原因会更容易(例如https://unix.stackexchange.com/q/5478)。而且我不需要杀死行为良好的进程作为副作用。
【问题讨论】:
-
您可以在同一台机器上的不同虚拟控制台中的
Xorg上使用gdb -
打字时减速最为明显,因此我宁愿在尝试调试问题时将物理键盘连接到 Xorg。而且由于原因可能是对 Xorg 设置的多个小请求的结果,因此仅使用
gdb可能很难找出原因。也许我需要 FlameGraph (brendangregg.com/FlameGraphs/cpuflamegraphs.html),但我没有适合当前运行的自定义内核映像的工具(即perf)。 -
您还可以尝试使用
strace或类似工具查找与X 服务器进行大量来回通信的客户端。例如,如果您有 10 个客户端进程,其中 9 个不经常与 X 服务器通信,但一个不断发送和接收大量小消息,我怀疑“健谈”客户端是罪魁祸首。
标签: linux performance ubuntu debugging xorg