Подвисает Arch

al.ks	# 4 года, 10 месяцев назад
Темы: 1 Сообщения: 16 Участник с: 25 октября 2017	killer1804 У тебя ssd ? если да, то может дело в этом: https://wiki.archlinux.org/index.php/Solid_State_Drives_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) раздел 2.2 (trim) Да ssd, по статье подрубил трим с изменениями в fstab, но ничего не изменилось ... как было так и осталось...

al.ks	# 4 года, 10 месяцев назад
Темы: 1 Сообщения: 16 Участник с: 25 октября 2017	На днях наткнулся на похожую статью, к сожелению не могу найти её, там говорилось о том что система пытается определить видеоадаптары или еще что-то читал с телефона мельком....

vasek	# 4 года, 10 месяцев назад
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	al.ks появились короткосрочные подвисания примерно каждые 10-15 секунд система подвисает на 1 сек или меньше. Проявляется без нагрузки(после вкл. и без запуска программ) на рабочем столе подвисает курсор(при быстром перемещении), при просмотре видео все намного четче))) Интересны на вскидку три момента, которые легко проверить: - наблюдается ли подвисание, если загрузиться только в текстовую консоль, без загрузки X? - нет ли чего нехорошего в выводе journalctl \| grep -i MCE. - увеличить логирование (сначала можно и без увеличения), запустить journalctl -f и смотреть есть ли сообщения в моменты подвисаний. И, конечно, нужен мониторинг разными утилитами, вплоть до нестандартных - раз подвисает с такой периодичностью даже в простое, значит какие то процессы что то да делают. Нужно хоть что то да узнать, а так одно гадание. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 4 года, 10 месяцев назад

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

al.ks
появились короткосрочные подвисания примерно каждые 10-15 секунд система подвисает на 1 сек или меньше. Проявляется без нагрузки(после вкл. и без запуска программ) на рабочем столе подвисает курсор(при быстром перемещении), при просмотре видео все намного четче)))

Интересны на вскидку три момента, которые легко проверить:
- наблюдается ли подвисание, если загрузиться только в текстовую консоль, без загрузки X?
- нет ли чего нехорошего в выводе journalctl | grep -i MCE.
- увеличить логирование (сначала можно и без увеличения), запустить journalctl -f и смотреть есть ли сообщения в моменты подвисаний.
И, конечно, нужен мониторинг разными утилитами, вплоть до нестандартных - раз подвисает с такой периодичностью даже в простое, значит какие то процессы что то да делают. Нужно хоть что то да узнать, а так одно гадание.

Ошибки не исчезают с опытом - они просто умнеют

Morisson	# 4 года, 10 месяцев назад (отредактировано 4 года, 10 месяцев назад)
Темы: 18 Сообщения: 1408 Участник с: 11 января 2017	Попробуй убрать discard из /etc/fstab. Иногда это приводит к тормозам. `sudo systemctl enable fstrim` Это использовать попробуй- служба трима 1 раз в неделю.

Haron_Prime	# 4 года, 10 месяцев назад (отредактировано 4 года, 10 месяцев назад)
Темы: 28 Сообщения: 2109 Участник с: 08 июня 2014	Не верно Надо запускать не сервис, а таймер. А уж он будет периодически запускать сам сервис. Cначала проверить, запущен ли таймер `sudo systemctl status fstrim.timer` Выхлоп должен быть примерно таким `● fstrim.timer - Discard unused blocks once a week Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled) Active: active (waiting) since Sat 2017-10-28 11:36:13 EEST; 5h 1min ago Trigger: Mon 2017-10-30 00:00:00 EET; 1 day 8h left Docs: man:fstrim Окт 28 11:36:13 arch systemd[1]: Started Discard unused blocks once a week` Если же таймер почему-то не запущен , то запустить `sudo systemctl start fstrim.timer sudo systemctl enable fstrim.timer` Таймер сам будет запускать сервис раз в неделю Gnome 2 >> Unity >> KDE 4 >> Openbox >> Awesome >> Xmonad GitHub , BitBuket

Haron_Prime

# 4 года, 10 месяцев назад (отредактировано 4 года, 10 месяцев назад)

Темы: 28

Сообщения: 2109

Участник с: 08 июня 2014

Не верно
Надо запускать не сервис, а таймер. А уж он будет периодически запускать сам сервис.
Cначала проверить, запущен ли таймер

sudo systemctl status fstrim.timer

Выхлоп должен быть примерно таким

● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled)
   Active: active (waiting) since Sat 2017-10-28 11:36:13 EEST; 5h 1min ago
  Trigger: Mon 2017-10-30 00:00:00 EET; 1 day 8h left
     Docs: man:fstrim

Окт 28 11:36:13 arch systemd[1]: Started Discard unused blocks once a week

Если же таймер почему-то не запущен , то запустить

sudo systemctl start fstrim.timer
sudo systemctl enable fstrim.timer

Таймер сам будет запускать сервис раз в неделю

Gnome 2 >> Unity >> KDE 4 >> Openbox >> Awesome >> Xmonad
GitHub , BitBuket

vasek	# 4 года, 10 месяцев назад (отредактировано 4 года, 10 месяцев назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	al.ks, можно попробовать отследить с помощью супер-комбайна sysdig - позволяет записывать практически все системные события, грубо говоря позволяет сделать временной снимок системы. Можно это провернуть, например, так 1) произвести запись системных событий секунд за 40 в лог # sysdig -w ~/sysdig.log подождать 40с и завершить в ручную Ctrl+c Появится файл ~/sysdig.log объемом около 10-20M. Размер зависит от нагрузки системы - лучше делать в покое, лишь бы за это время были подвисания. Смотреть его бесполезно, но если просто взглянуть и немного полистать, то только так - sysdig -r sysdig.log \| less Анализировать его лучше используя встроенную систему, так называемых, чизелов, например, - операции ввода-вывода, выполнение которых происходит с задержкой более 1мс # sysdig -r ~/sysdig.log -c fileslower 1 - процессы, время выполнения которых более 1мс # sysdig -r ~/sysdig.log -c proc_exec_time 1 - системные вызовы, выполнение которых происходит с задержкой более 1000мс # sysdig -r ~/sysdig.log -c scallslower 1000 - top файлов, на которые было затрачено больше всего времени: # sudo sysdig -r ~/sysdig.log -c topfiles_time Наверное, и достаточное - ошибки ввода-вывода и открытия файлов/процессов можно не анализировать. UPD .... время поставил от фонаря, обычно приходится менять в режиме анализа. 2) Можно в лог не писать, а смотреть прямо в терминале, в режиме on-line (или этот вывод записать в файл) Вообщем почти те же самые команды/чизелы, описанные выше, с небольшим изменением ........ не забываем завершить в ручную Ctrl+c - операции ввода-вывода, выполнение которых происходит с задержкой более 1мс # sysdig -c fileslower 1 - время выполнения процессов # sysdig -c proc_exec_time и т.д и т.п. При желании, если освоишь, можно пробовать и другие конкретные запросы, но для этого нужно ориентироваться, что ты хочешь получить в итоге. EDIT 1 - иногда помогает посмотреть большие разрывы во времени между строками в логе ~/sysdig.log - так как объем большой около 100 000 строк, то нужно писать скрипт. Безусловно, сначала нужно применить стандартный, простой анализ. А если уж не получится, то остается только сложный путь. С непривычки, конечно, все это выглядит страшно, но если хочется узнать, другого пути не вижу ..... есть, конечно, но еще более сложные. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 4 года, 10 месяцев назад (отредактировано 4 года, 10 месяцев назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

al.ks, можно попробовать отследить с помощью супер-комбайна sysdig - позволяет записывать практически все системные события, грубо говоря позволяет сделать временной снимок системы. Можно это провернуть, например, так
1) произвести запись системных событий секунд за 40 в лог
# sysdig -w ~/sysdig.log
подождать 40с и завершить в ручную Ctrl+c
Появится файл ~/sysdig.log объемом около 10-20M. Размер зависит от нагрузки системы - лучше делать в покое, лишь бы за это время были подвисания. Смотреть его бесполезно, но если просто взглянуть и немного полистать, то только так - sysdig -r sysdig.log | less
Анализировать его лучше используя встроенную систему, так называемых, чизелов, например,
- операции ввода-вывода, выполнение которых происходит с задержкой более 1мс
# sysdig -r ~/sysdig.log -c fileslower 1
- процессы, время выполнения которых более 1мс
# sysdig -r ~/sysdig.log -c proc_exec_time 1
- системные вызовы, выполнение которых происходит с задержкой более 1000мс
# sysdig -r ~/sysdig.log -c scallslower 1000
- top файлов, на которые было затрачено больше всего времени:
# sudo sysdig -r ~/sysdig.log -c topfiles_time
Наверное, и достаточное - ошибки ввода-вывода и открытия файлов/процессов можно не анализировать.
UPD .... время поставил от фонаря, обычно приходится менять в режиме анализа.

2) Можно в лог не писать, а смотреть прямо в терминале, в режиме on-line (или этот вывод записать в файл)
Вообщем почти те же самые команды/чизелы, описанные выше, с небольшим изменением ........ не забываем завершить в ручную Ctrl+c
- операции ввода-вывода, выполнение которых происходит с задержкой более 1мс
# sysdig -c fileslower 1
- время выполнения процессов
# sysdig -c proc_exec_time
и т.д и т.п.
При желании, если освоишь, можно пробовать и другие конкретные запросы, но для этого нужно ориентироваться, что ты хочешь получить в итоге.

EDIT 1 - иногда помогает посмотреть большие разрывы во времени между строками в логе ~/sysdig.log - так как объем большой около 100 000 строк, то нужно писать скрипт.
Безусловно, сначала нужно применить стандартный, простой анализ. А если уж не получится, то остается только сложный путь. С непривычки, конечно, все это выглядит страшно, но если хочется узнать, другого пути не вижу ..... есть, конечно, но еще более сложные.

Ошибки не исчезают с опытом - они просто умнеют

al.ks	# 4 года, 10 месяцев назад
Темы: 1 Сообщения: 16 Участник с: 25 октября 2017	vasek al.ks появились короткосрочные подвисания примерно каждые 10-15 секунд система подвисает на 1 сек или меньше. Проявляется без нагрузки(после вкл. и без запуска программ) на рабочем столе подвисает курсор(при быстром перемещении), при просмотре видео все намного четче))) Интересны на вскидку три момента, которые легко проверить: - наблюдается ли подвисание, если загрузиться только в текстовую консоль, без загрузки X? - нет ли чего нехорошего в выводе journalctl \| grep -i MCE. - увеличить логирование (сначала можно и без увеличения), запустить journalctl -f и смотреть есть ли сообщения в моменты подвисаний. И, конечно, нужен мониторинг разными утилитами, вплоть до нестандартных - раз подвисает с такой периодичностью даже в простое, значит какие то процессы что то да делают. Нужно хоть что то да узнать, а так одно гадание. 1. Без иксов зависаний не заметил... 2. journalectl \| grep mce Выводит "окт 28 23:18:18 arch kernel: mce: CPU supports 9 MCE bank" больше ничего... 3. journalectl -f в момент подвисаний ничего не выводит

al.ks

# 4 года, 10 месяцев назад

Темы: 1

Сообщения: 16

Участник с: 25 октября 2017

vasek
al.ks
появились короткосрочные подвисания примерно каждые 10-15 секунд система подвисает на 1 сек или меньше. Проявляется без нагрузки(после вкл. и без запуска программ) на рабочем столе подвисает курсор(при быстром перемещении), при просмотре видео все намного четче)))
Интересны на вскидку три момента, которые легко проверить:
- наблюдается ли подвисание, если загрузиться только в текстовую консоль, без загрузки X?
- нет ли чего нехорошего в выводе journalctl | grep -i MCE.
- увеличить логирование (сначала можно и без увеличения), запустить journalctl -f и смотреть есть ли сообщения в моменты подвисаний.
И, конечно, нужен мониторинг разными утилитами, вплоть до нестандартных - раз подвисает с такой периодичностью даже в простое, значит какие то процессы что то да делают. Нужно хоть что то да узнать, а так одно гадание.

1. Без иксов зависаний не заметил...
2. journalectl | grep mce Выводит "окт 28 23:18:18 arch kernel: mce: CPU supports 9 MCE bank" больше ничего...
3. journalectl -f в момент подвисаний ничего не выводит

al.ks	# 4 года, 10 месяцев назад (отредактировано 4 года, 10 месяцев назад)
Темы: 1 Сообщения: 16 Участник с: 25 октября 2017	Haron_Prime Не верно Надо запускать не сервис, а таймер. А уж он будет периодически запускать сам сервис. Cначала проверить, запущен ли таймер `sudo systemctl status fstrim.timer` Выхлоп должен быть примерно таким `● fstrim.timer - Discard unused blocks once a week Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled) Active: active (waiting) since Sat 2017-10-28 11:36:13 EEST; 5h 1min ago Trigger: Mon 2017-10-30 00:00:00 EET; 1 day 8h left Docs: man:fstrim Окт 28 11:36:13 arch systemd[1]: Started Discard unused blocks once a week` Если же таймер почему-то не запущен , то запустить `sudo systemctl start fstrim.timer sudo systemctl enable fstrim.timer` Таймер сам будет запускать сервис раз в неделю Собственно сервис небыл запущен, запустил по вашему описанию таймер, выхлоп статуса соответствует. К сожелению не помогло.(На всякий случай перезагружался)

al.ks

# 4 года, 10 месяцев назад (отредактировано 4 года, 10 месяцев назад)

Темы: 1

Сообщения: 16

Участник с: 25 октября 2017

Haron_Prime
Не верно
Надо запускать не сервис, а таймер. А уж он будет периодически запускать сам сервис.
Cначала проверить, запущен ли таймер
sudo systemctl status fstrim.timer
Выхлоп должен быть примерно таким
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled)
   Active: active (waiting) since Sat 2017-10-28 11:36:13 EEST; 5h 1min ago
  Trigger: Mon 2017-10-30 00:00:00 EET; 1 day 8h left
     Docs: man:fstrim

Окт 28 11:36:13 arch systemd[1]: Started Discard unused blocks once a week
Если же таймер почему-то не запущен , то запустить
sudo systemctl start fstrim.timer
sudo systemctl enable fstrim.timer
Таймер сам будет запускать сервис раз в неделю

Собственно сервис небыл запущен, запустил по вашему описанию таймер, выхлоп статуса соответствует.
К сожелению не помогло.(На всякий случай перезагружался)

Haron_Prime	# 4 года, 10 месяцев назад
Темы: 28 Сообщения: 2109 Участник с: 08 июня 2014	al.ks Собственно сервис небыл запущен, Он и не должен быть запущен постоянно, его запускает таймер раз в неделю. А вот таймер как раз должен быть запущен. Можно конечно периодически ручками в терминале `sudo fstrim /` но таймер как-то надёжнее Gnome 2 >> Unity >> KDE 4 >> Openbox >> Awesome >> Xmonad GitHub , BitBuket

Haron_Prime

# 4 года, 10 месяцев назад

Темы: 28

Сообщения: 2109

Участник с: 08 июня 2014

al.ks
Собственно сервис небыл запущен,

Он и не должен быть запущен постоянно, его запускает таймер раз в неделю.
А вот таймер как раз должен быть запущен.
Можно конечно периодически ручками в терминале

sudo fstrim /

но таймер как-то надёжнее

Gnome 2 >> Unity >> KDE 4 >> Openbox >> Awesome >> Xmonad
GitHub , BitBuket

al.ks	# 4 года, 10 месяцев назад
Темы: 1 Сообщения: 16 Участник с: 25 октября 2017	Haron_Prime al.ks Собственно сервис небыл запущен, Он и не должен быть запущен постоянно, его запускает таймер раз в неделю. А вот таймер как раз должен быть запущен. Можно конечно периодически ручками в терминале `sudo fstrim /` но таймер как-то надёжнее ну я так и сделал стартанул его 1 раз и потом в сервисы добавил

al.ks

# 4 года, 10 месяцев назад

Темы: 1

Сообщения: 16

Участник с: 25 октября 2017

Haron_Prime
al.ks
Собственно сервис небыл запущен,
Он и не должен быть запущен постоянно, его запускает таймер раз в неделю.
А вот таймер как раз должен быть запущен.
Можно конечно периодически ручками в терминале
sudo fstrim /
но таймер как-то надёжнее

ну я так и сделал стартанул его 1 раз и потом в сервисы добавил