Подвисает Arch

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
появились короткосрочные подвисания примерно каждые 10-15 секунд система подвисает на 1 сек или меньше. Проявляется без нагрузки(после вкл. и без запуска программ) на рабочем столе подвисает курсор(при быстром перемещении), при просмотре видео все намного четче)))
Интересны на вскидку три момента, которые легко проверить:
- наблюдается ли подвисание, если загрузиться только в текстовую консоль, без загрузки X?
- нет ли чего нехорошего в выводе journalctl | grep -i MCE.
- увеличить логирование (сначала можно и без увеличения), запустить journalctl -f и смотреть есть ли сообщения в моменты подвисаний.
И, конечно, нужен мониторинг разными утилитами, вплоть до нестандартных - раз подвисает с такой периодичностью даже в простое, значит какие то процессы что то да делают. Нужно хоть что то да узнать, а так одно гадание.
Ошибки не исчезают с опытом - они просто умнеют
Попробуй убрать discard из /etc/fstab. Иногда это приводит к тормозам.
sudo systemctl enable fstrim
Это использовать попробуй- служба трима 1 раз в неделю.
Не верно
Надо запускать не сервис, а таймер. А уж он будет периодически запускать сам сервис.
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
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
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 в момент подвисаний ничего не выводит
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
Собственно сервис небыл запущен,
Он и не должен быть запущен постоянно, его запускает таймер раз в неделю.
А вот таймер как раз должен быть запущен.
Можно конечно периодически ручками в терминале
sudo fstrim /
но таймер как-то надёжнее
Gnome 2 >> Unity >> KDE 4 >> Openbox >> Awesome >> Xmonad
GitHub , BitBuket
Haron_Prime
al.ks
Собственно сервис небыл запущен,
Он и не должен быть запущен постоянно, его запускает таймер раз в неделю.
А вот таймер как раз должен быть запущен.
Можно конечно периодически ручками в терминале
sudo fstrim /
но таймер как-то надёжнее
ну я так и сделал стартанул его 1 раз и потом в сервисы добавил
 
Зарегистрироваться или войдите чтобы оставить сообщение.