Как лучше диагностировать, какой клиент вызывает высокую загрузку процессора Xorg? - PullRequest
Новая
       9

Как лучше диагностировать, какой клиент вызывает высокую загрузку процессора Xorg?

0 голосов
/ 06 сентября 2018

У меня проблемы, когда Сервер Xorg внезапно становится очень медленным, и его загрузка ЦП достигает 100% . Гугл об этом говорит о том, что «отладочный» метод для этой проблемы состоит в том, чтобы случайным образом убивать X-клиентов, пока проблема не исчезнет, ​​а затем вы узнаете, какой из них был проблемным (удачи в попытке отладить процесс после его уничтожения) , Ни один из клиентов X не потребляет много ЦП (около 1% ЦП каждый). И система все еще имеет 2 ГБ доступной оперативной памяти.

Кто-нибудь знает метод для лучшей диагностики проблемы? В основном я ищу top замену для Xorg, которая напрямую указала бы мне на клиентский процесс, который вызывает наибольшую загрузку ЦП для Xorg. Я уже знаю о xrestop, что то же самое для использования памяти Xorg, но этот вопрос конкретно об использовании процессора.

Еще одной причиной этого замедления может быть нехватка памяти графического процессора, что может привести к передаче растровых изображений по шине PCI-express вместо рендеринга непосредственно из памяти графического процессора для отображения. Если это показывает использование ЦП на уровне ядра (например, top), возможно, это проблема, с которой я сталкиваюсь, но я хотел бы лучше понять причину. Когда я пишу это из проблемной системы, кажется, что наибольшее замедление происходит при обработке ввода или рендеринге шрифта, но я не знаю, как лучше это диагностировать.

Я знаю, что возможно использовать другой компьютер и подключиться к ssh, присоединить процесс gdb к проблемному серверу Xorg и начать копать, но я надеюсь, что что-то немного проще.

Если бы я получил PID или даже дескриптор окна для проблемного клиента, выяснить основную причину было бы проще (например, https://unix.stackexchange.com/q/5478). И мне не нужно было бы убивать процессы с хорошим поведением в качестве побочного эффекта.

1 Ответ

0 голосов
/ 06 сентября 2018

Вот сценарий, чтобы выяснить, является ли проблема одним из клиентов (хотя и не помогла с моей проблемой): 

#!/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 целевому процессу, который нельзя игнорировать, и не дает целевому процессу получать процессорное время, поэтому он также не может отправлять какие-либо события в Xorg. Обратите внимание, что если вы убьете этот скрипт посередине, вы можете получить один из ваших процессов в состоянии STOPPED. Отправьте SIGCONT, чтобы решить проблему. Если вы дождетесь завершения сценария, все должно быть в порядке. (Смотрите также: https://unix.stackexchange.com/a/298650)

В моем случае Xorg продолжал работать медленно, независимо от того, какой клиент был остановлен, поэтому я предполагаю, что проблема, которую я вижу, связана с внутренней проблемой Xorg, и мне нужно было бы использовать FlameGraphs (http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html), чтобы выяснить реальную причину проблемы.

...