Тормоза при выходе из длительной блокировки экрана

swapoff -a && swapon -a

swapoff -a && swapon -a

Не помогло.

Сброс кешей echo 1 > /proc/sys/vm/drop_caches тоже не помог.

Я обратил внимание, что висящий процесс cinnamon заметно нагружает процессор:

# ps aux --sort=-pcpu
  USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
  user        1891 73.0  0.9 5693100 290656 ?      Rl   Aug02 15653:36 cinnamon --replace

Я не смог перезапустить его таким образом:

# su - user -c 'DISPLAY=:0 cinnamon --replace &'

и не смог прибить его так:

# killall cinnamon

зато получилось так:

# killall -9 cinnamon

и запустил его так:

# su - user -c 'DISPLAY=:0 cinnamon --replace &'

Это уже небольшой успех, но как обойтись без этих манипуляций при каждом возвращении за компьютер?

Попробуй sddm. В мире Х11 все DM взаимозаменяемы (кроме gdm).

Попробуй sddm.

А DM сильно влияет на мою проблему?

Я пока хочу проверить другую гипотезу. Раньше я замечал, что тормоза увеличивались с аптаймом системы. Но в прошлый раз от тормозов избавил перезапуск cinnamon. То есть роль играет аптайм cinnamon или что-то еще связанное с ним.

При аптайме 15 тыс. часов вход тормозил 20 минут. При аптайме 700 часов тормоза не выявлены. Буду наблюдать дальше.

Одно из двух, или проблема именно в ДМ, он не хочет отдавать управления экраном, или в WM, он не хочет включаться.

Что не исключает проблемы с аптаймом: вполне может быть что причина «не хочет» в утечках памяти. Что пользователем лечится только одним способом: сбойный компонент заменяется на другой, не текущий.

Кстати, раз в месяц систему можно бы и перезагрузить. Совсем другое если бы проблема появлялась бы каждую неделю.

Кстати, раз в месяц систему можно бы и перезагрузить. Совсем другое если бы проблема появлялась бы каждую неделю.

Упс. Про аптайм я сказал, не подумав:

При аптайме 15 тыс. часов вход тормозил 20 минут. При аптайме 700 часов тормоза не выявлены.

Это не часы, а минуты, и не аптайм, а время использования процессора с момента запуска. Значение взято из вывода ps. Приведу статистику на данный момент, аптайм указан приблизительно. Тормоза при входе пока не наблюдаются.

uptime   %CPU %MEM    VSZ   RSS TTY      STAT START    TIME COMMAND
 ~0h      5.0  0.5 5552884 184104 ?      Sl   17:53    0:02 cinnamon --replace
~12h     13.2  0.6 5556000 200816 ?      Sl   Aug17  229:24 cinnamon --replace
~36h     27.4  0.6 5564336 208352 ?      Sl   Aug17  717:19 cinnamon --replace
~60h     40.8  0.6 5577320 220452 ?      Sl   Aug17 1706:14 cinnamon --replace

Видно, что потребление памяти растет не сильно, но очень заметно растёт загрузка процессора.

Значит всё таки глючит в нём что то. В cinnamon, он же видимо ВМ этоко окружения. Здесь должна быть шутка про то, что даже если делать нормальный ВМ, там под капотом один хрен технологии гном3+.

Кстати, у меня тоже есть проблемы с ВМ с течением времени (это kwin_x11) и я пока что не нашёл адекватного способа автоматической перезагрузки по таймеру.

Я сравнил логи Xorg на Debian и Mint.

На Debian, где наблюдаются тормоза, много строк вида

(EE) event4  - Keyboard: client bug: event processing lagging behind by 37ms, your system is too slow
(EE) event3  - Mouse: client bug: event processing lagging behind by 13ms, your system is too slow

и несколько меньше таких:

(WW) AMDGPU(0): get vblank counter failed: Invalid argument

На Mint ничего подобного в логах не наблюдается.

Может ли это влиять на мою проблему? И как это исправить?

Кстати, раз в месяц систему можно бы и перезагрузить. Совсем другое если бы проблема появлялась бы каждую неделю.

Проявляется каждую неделю. На 4 сутки после рестарта cinnamon подтормаживание стало ощутимым и при входе составило несколько секунд. На 5 сутки задержка составила примерно 30-60 секунд.

Затем потребовалось перезагрузить компьютер по другим причинам, поэтому текущий цикл эксперимента был прерван.

Пока что можно сказать, что нагрузка от процесса cinnamon в целом растет со временем его непрерывной работы.

Самое удивительное для меня в том, что нагрузка в конце моего рабочего дня на несколько процентов меньше чем в начале. Это наблюдение совпадает с субъективными ощущениями: чем дольше рабочая сессия находилась в режиме блокировки, тем заметнее подтормаживание, но я реже с ним сталкиваюсь при более интенсивном использовании компьютера.

Чем можно объяснить такой эффект?

get vblank counter failed

Попробуй отключить вертикальную синхронизацию. Хз как на Корице.

AMDGPU(0)

Там должны быть свободная и PRO версии драйвера, надо попробовать поменять. Подробностей тоже не знаю, у меня была HD8000-серия.

Keyboard: client bug ... your system is too slow

Вот с этим хз что можно сделать, возможно если уйдёт тормоз в драйвере/ВМ то мышка с клавой не будут ругаться. А воможноих баги и есть причина тормозов. Я не знаю какие библиотеки и методы захвата устройств ввода используются, но там вроде бы была какая то революция вокруг перехода на libinput и поддержки вайланда. Стоит покопать в этом направлении, возможно там есть поддержка 2-х разных методов ввода. Но сначала попробей заменить видеодрайвер.

Кстати, есть совсем уж грязный хак: Минт и дебиан - деб-подобные, а значит через вопли dpkg и страдания можно вкорячить более свежее ядро и месу от минта в дебиан и скорее всего они будут работать. Будь эта проблема у меня - я бы попытался. Но разумеется долго и нужен опыт сборки ядра и настройки загрузчика и хорошее умение делать бэкапы, а то система пару-тройку раз точно сломается.

Попробуй отключить вертикальную синхронизацию.

Это сработало, предупреждения пропали.

Также я обнаружил косвенное подтверждение, что лаги как-то связаны с моем отсутствием за компом: журнал Xorg очень редко обновляется, пока я использую комп, но активно растет, когда я ухожу. Сообщения разных категоий: II, --, EE.

Если отключение vsync решает проблему - отметь тему как решённую. Может кто ещё будет искать, увидит и ему поможет.

Если отключение vsync решает проблему - отметь тему как решённую.

До полного решения далеко. Буду держать в курсе.

Проблема проявляется спустя несколько суток от перезапуска cinnamon. Вдобавок я запутал ситуацию, отключив вместе с vsync скринсейвер и блокировку экрана. Требовалось проверить предположение о том, что проблема нарастает во время моего отсутствия.

Что-то из этого частично помогло: Xorg не спамит в журнал, cinnamon меньше грузит процессор. Если это не флуктуация, решение близко.

Если отключение vsync решает проблему - отметь тему как решённую.

Проблема не решилась. После отключения vsync предупреждения и ошибки в Xorg.log пропали, но тормоза при выходе из блокировки остались. Они пропадают при отключении скринсейвера и блокировки экрана. Еще помогает перезагрузка cinnamon.

Что еще можно проверить?

Пока планирую отключить только блокировку, оставив скринсейвер.

Видеодрайвер/ядро/дистрибутив. Ну и сам Циннамон разумеется.

Начти с видеодрайвера, насколько я знаю он должен существовать в 2 версиях.

Да, и ещё один крамольный вариант: поробовать вайланд. Ну а вдруг там проблемы нет, а новых привнесёт меньше?

и сам Циннамон

Проверяю cinnamon. Построил график создаваемой им нагрузки. Она держится на уровне 1% при обычной работе, падает почти до нуля при включении скринсейвера, но через 30 минут резко поднимается до 10%, затем относительно плавно, ускоряясь, растет, и рывками падает на 10-15%. Момент падения нагрузки почти до нуля совпадает с моим возвращением за комп.

Сообщение в Xor.log event processing lagging behind by 13ms, your system is too slow появилось один раз - в момент моего возвращения. Именно в это время комп несколько секунд тормозил, пытаясь переключиться из скринсейвера на рабочий стол.

В других журналах я ничего подозрительного за это время не обнаружил.

График нагрузки cinnamon

А там точно нет скрытого майнера?

Вообще я не телепат и даже дебаггером не смог бы потыкать чтобы сказать что оно делает. Я могу только перебирать взаимозменяемые компоненты пока не найдётся рабочий.

Ну, допустим, пожно попробовать запустить Циннамон в консоли, может он туда навалит сообщений и станет понятней что он делает. Но вообще я не настолько фанат этой штуки чтобы не выкинуть её и не перейти на что то другое.

З.Ы. Насчёт видеодрайвера выяснил?

А там точно нет скрытого майнера?

Маловероятно. Все пакеты установлены из официального репозитория Debian. Для майнера рисунок нагрузки выглядит нетипично.

При запуске скринсейвера нагрузка от cinnamon падает с 1 до 0.1%, но через 30 минут процесс cinnamon начинает постепенно нагружать процессор. Чем дольше работает скринсейвер, тем больше нагрузка.

Когда я возвращаюсь за компьютер, после некоторого периода тормозов нагрузка падает до 1% и в среднем держится на этом уровне без значительных колебаний.

При следующем запуске скринсейвера нагрузка от cinnamon снова падает до 0.1%, но через полчаса резко поднимается до прежнего уровня, на котором я остановил скринсейвер в прошлый раз. Затем она продолжает плавно расти.

Насчёт видеодрайвера выяснил?

Пока нет. Хочу сначала довести до конца этот эксперимент, чтобы увидеть графики нагрузки. Эксперимент сейчас находится в той стадии, когда его можно закончить, но можно подождать еще одни сутки. В силу других причин решение об окончании приму через 3 часа.

Когда я возвращаюсь за компьютер, после некоторого периода тормозов нагрузка падает до 1% и в среднем держится на этом уровне без значительных колебаний. При следующем запуске скринсейвера нагрузка от cinnamon снова падает до 0.1%, но через полчаса резко поднимается до прежнего уровня

Как будто какой то виджет панели/шела что то делает, но не может этого делать пока стол заблокирован скринсейвером. Что то вроде набрасывания событий в очередь, а потом надо потормозить чтобы обработать всё что накопилось и не было отброшено. Ну, это так, теория.

Насчёт видеодрайвера выяснил?

Установлены пакеты:

• xserver-xorg-video-amdgpu
• firmware-amd-graphics

Вопросы:

• Проприетарный драйвер - это firmware-amd-graphics?
• Как понять, что система использует именно его? Где это включается и отключается?
• Если его удалить, будет использоваться открытая версия драйвера?

Вот во всех этих вопросах тебе желательно разобраться самому. У меня ноут с видеокартами radeon HD8450G+HD8750M и для него есть свободный драйвер radeon (r600)(включён в mesa, ставится пакетом xserver-xorg-video-radeon и пропиретарный catalyst (fglrx), причём какая то из версий 15.* работала хорошо, а более новые 16.* давали утечку памяти и падение в пределах 2-3 дней использования. Установка каталиста не совсем тривиальная потому что без сбоя и бубна в системе может быть только один из них. Всю эту информацию я собирал и учился довольно немало времени, а по твоей карте я просто не знаю.

https://wiki.archlinux.org/title/AMDGPU_PRO https://www.amd.com/en/resources/support-articles/release-notes/RN-PRORAD-LIN... https://help.ubuntu.ru/wiki/драйвер_видеокарт_amd

Если кратко - amdgpu-pro существует и скорее всего подходит к твоей видеокарте в какой то из версий. Если есть свободное время - стоит изучить, порыться, научиться ставить и посмотреть. Если нет времени то меняй циннамон.

firmware-amd-graphics

Предположу что подойдёт для обоих версий драйвера. Но если amdgpu-pro начнёт раскладывать свои версии, то может начать ругаться что файлы уже существуют.

Проприетарный драйвер - это firmware-amd-graphics?

Не, в случае с catalyst (fglrx) можно было взять .run пакет на сайте амд или в некоторых дистрибутивах уже лежали собранные пакеты. Но например вдебиане нет xserver-xorg-video-amdgpu-pro. А firmware это всего лишь микропрограммы, которые должны быть загружены в видеокарту чтобы она заработала.

Как понять, что система использует именно его? Где это включается и отключается?
Если его удалить, будет использоваться открытая версия драйвера?

Во первых glxinfo даёт немного инфы. Потом lsmod (от root'а) показывает список загруженных модулей ядра и там должно быть что то соответствующее. dmesg это лог ядра, там есть кое-что про оборудование и подключенные драйвера, но без гарантий и рыться там сложно. lspci должен выдавать кучу инфы по pci-устройствам, но я крайне слабо умею ей пользоваться.

Фактически важна загрузка одного или другого модуля ядра. Есть механизм добавления ненужного модуля в блэклист чтобы методом исключения загрузился нужный, но надёжней удалить ненужный. Это потому что вместе с модулем ещё идёт пакет библиотек с реализациями OpenGL/Vulcan и прочих api и есть шансы что одни файлы и ссылки на них будут конфликтовать с другими.

Хороший индикатор например для Нвидия - для неё устанавливается или xserver-xorg-video-nvidia, или xserver-xorg-video-nouveau, и они конфликтуют. Для своего радеона я вроде тоже удалял один и ставил другой. Да, это всё делалось через ядерную консоль без возможности запустить ДЕ, так что если что то шло не так... Ну, короче бэкапы обязательно!

amdgpu-pro существует и скорее всего подходит к твоей видеокарте в какой то из версий

Я попытался установить amdgpu-pro, но не осилил. Попробую позже на более свежей версии Debian.

Кроме этого я удалил пакет xserver-xorg-video-amdgpu. Но после перезагрузки я не обнаружил изменений в выводе lsmod и glxinfo. Шестерни в glxgears крутятся как и раньше с частотой 60 FPS. Cinnamon не выдал предупреждений о программном рендеринге. На мою проблему это никак не повлияло.

Получается, что удалить xserver-xorg-video-amdgpu недостаточно? Что еще нужно удалить для отключения amdgpu?

# lsmod | egrep '^(Module|amd)'
  Module                  Size  Used by
  amdgpu               6713344  19

Обнаружил, что проблему можно решить, удалив процесс csd-background. Без него тормоза пропадают. Но, возможно, я столкнусь с проблемами в будущем. Я не нашел информации об этом процессе кроме того, что это фоновый плагин демона настроек Cinnamon. Как это понимать?

Простого способа его отключения я тоже не нашел. После уничтожения процесса csd-background его перезапускает родительский cinnamon-session. Его удается удалить, несколько раз сделав killall csd-background и перезапустив cinnamon.

Вопросы:

• Как правильно отключить csd-background?
• К каким проблемам это может привести?
• Что конкретно этот процесс делает?

Как правильно отключить csd-background?

Если у него есть свой собственный пакет (как здесь, например), то можно попробовать удалить этот пакет. Если он за собой при удалении ничего лишнего не потянет, то это будет солидное решение.

Что конкретно этот процесс делает?

Судя по коду, он устанавливает/меняет обои на рабочем столе в каких-то ситуациях.

К каким проблемам это может привести?

Не будут меняться обои при выборе картинки в настройках, или если обои зависят от времени суток, то эта фишка отвалится. А может, вообще обои пропадут.

кроме того, что это фоновый плагин демона настроек Cinnamon. Как это понимать?

Короче хрень полная, особенно если при убивании ничего не отваливается.

annulen всё правильно написал, но на случай если его советы не помогут, есть жестокие, бессмысленные и беспощадные способы убивания неугодных программ.

Во первых в cron (конфиг /etc/crontab) пишется что то вроде 0,5,10,15,20,25,30,35,40,45,50,55 * * * * rrr killall csd-background - это значит убивать csd-background от пользователя rrr каждую 0-ю, 5-ю, 10-ю и т.д. минуту каждого часа каждого дня идалее по синтаксису (см справку разумеется).

Во вторых можно найти бинарник csd-background, удилить его и заменить пустым файлом (а потом отобрать право на запись) или ссылкой на /dev/null (иногда /dev/zero или какую нибудь безобидную програмку). Правда это будет давать конфликт файлов при обновлениях (можно разрулить вручную). А если всё таки обновится - бдет заменять правильным запускаемым бинарником.

Во вторых можно найти бинарник csd-background, удилить его и заменить пустым файлом (а потом отобрать право на запись)

Просто снять бит исполнения не прокатит разве? Вот только у всякой НЁХ отдельного бинарника может и не быть. Вон как в гноме всё запихнули в монолит гномощели.

можно попробовать удалить этот пакет.

В Debian 11 такого пакета нет.

Судя по коду, он устанавливает/меняет обои на рабочем столе в каких-то ситуациях.

Пройдя по ссылке на код, я узнал, что CSD это не только client side decoration, но и cinnamon settings daemon. Это знание привело меня к файлу /etc/xdg/autostart/cinnamon-settings-daemon-background.desktop, в который можно добавить параметр Hidden=true.

После перезагрузки csd-background в списке процессов не появился. Старые обои отображаются, новые установить невозможно. Результат меня удовлетворяет.

Решение, скорее всего, найдено, но для окончательных выводов требуется понаблюдать несколько дней.

В Debian 11 такого пакета нет.

Пакет по имени файла можно определить командой dpkg -S путь

После перезагрузки csd-background в списке процессов не появился. Старые обои отображаются, новые установить невозможно. Результат меня удовлетворяет.

Обои всегда можно поменять другими иксовыми способами, например, с помощью feh. У утилит из DE нет никаких привелегий, в иксах любой желающий может рисовать в корневом окне)

Пакет по имени файла можно определить командой dpkg -S путь

В Debian 11 это большой пакет cinnamon-settings-daemon, который я не планирую удалять полностью.

Решение, скорее всего, найдено, но для окончательных выводов требуется понаблюдать несколько дней.

Решение с отключением csd-background сработало, но я продолжаю поиск более чистого решения, поэтому вернул csd-background на место.

Помогло снятие всех галочек в настройках скринсейвера. Возврат галочек возвращает проблему. Осталось найти среди этих галочек злополучную.

Эксперименты замедляются тем, что проблема проявляется лишь при длительной работе скринсейвера.

Помогло снятие всех галочек в настройках скринсейвера. Возврат галочек возвращает проблему. Осталось найти среди этих галочек злополучную.

Но повторное снятие галочек не улучшило ситуацию. Не понимаю, почему это помогло с прошлый раз, и не сработало в этот.

В прошлый раз я разрешил автозапуск csd-background и перезагрузил компьютер. Затем снял все галки в настройках скринсейвера и стал наблюдать за уровнем нагрузки. Она была на минимальном уровне.

В этот раз никаких манипуляций с csd-background я не выполнял, а просто снял галки. Нагрузка во время работы скринсейвера начала расти.

Лучшее решение на данный момент заключается в отключении csd-background.

В прошлый раз я разрешил автозапуск csd-background и перезагрузил компьютер. Затем снял все галки в настройках скринсейвера и стал наблюдать за уровнем нагрузки. Она была на минимальном уровне.

Повторить этот результат мне не удалось. Я снова отключил csd-background, перезагрузил компьютер, выждал 60 часов: нагрузка не выросла. Включил csd-background, перезагрузил компьютер: нагрузка начала экспоненциально расти даже при всех отключенных галках скринсейвера.

Как теперь выяснить, почему нагрузка не росла в прошлый раз?