LINUX.ORG.RU

Странное поведение ядра 5.10

 , , ,


1

5

Итак, имеется компьютер с 8 гигами памяти и обычным тошибовским хардом на 7200 оборотов, объем 1 терабайт. Наблюдаются серьезные проблемы с отзывчивостью системы при высокой дисковой нагрузке: копирование фильмов с переносного харда, использование rsync для восстановления данных из бекапа или установка пакетов с помощью пакмана. Даже относительно небольшая фоновая нагрузка на диск вызывает лаги интерфейса. Когда я попробовал одновременно скопировать с диска фильм и развернуть виртуалку с федорой, система повисла наглухо. Даже при переключении на другую виртуальную консоль был заметный лаг (наверно, секунл 10). Система отвисла только после того, как закончилось копирование. И это при использовании bfq, который, по идее, должен спасать от таких бед. C mq-deadline было то же самое (были заметные подлагивания интерфейса при использовании rsync). Я не помню таких тормозов с ядром 5.4.

Проблема решилась установкой ядра 4.19 (собрал из исходников). Правда, это не совсем чистый эксперимент, потому что я использовал realtime-патч. Тем не мение, сейчас все работает нормально. Кто сталкивался с такими проблемами при использовании ядра 5.10? Это особенно интересно в свете того, что 5.10 – последнее lts ядро.

★☆

Последнее исправление: hateWin (всего исправлений: 1)

Блин не заметил, что ТС правильный тег поставил.

AlexVR ★★★★★
()

Если по делу, то посмотри top, может какой негодяй файловую систему индексирует. У меня из-за этого в последний раз ОН был.

AlexVR ★★★★★
()

так .
уточни
проблема не с ОЗУ?
проблема только при высоком io?

лучше бы конечно черкануть багрепорт в ядро, и испросить, что они там сломали с 4.19
но я не силён в формулировках

darkenshvein ★★★★★
()
Ответ на: комментарий от darkenshvein

Вот вспомнить не могу, но пару лет назад столкнулся с тормозами. dmesg пустой. А потом нашёл какой-то предустановленный демон для FastSearch, он всё колом ставил. Поэтому и предлагаю вначале поискать кто может хулиганить. Его снёс и два года полёт нормальный.

AlexVR ★★★★★
()
Ответ на: комментарий от darkenshvein

проблема только при высоком io?

Да. Любая более-менее серъзная фоновая нагрузка приводит к лагам.

hateWin ★☆
() автор топика
Ответ на: комментарий от hateWin

Начни с:

systemctl --type=service --state=running

Проблема может быть не только в ядре, но и в том кто и как это ядро использует.

AlexVR ★★★★★
()
Ответ на: комментарий от AlexVR
accounts-daemon.service   loaded active running Accounts Service                                  
  colord.service            loaded active running Manage, Install and Generate Color Profiles       
  dbus.service              loaded active running D-Bus System Message Bus                          
  gdm.service               loaded active running GNOME Display Manager                             
  NetworkManager.service    loaded active running Network Manager                                   
  polkit.service            loaded active running Authorization Manager                             
  rtkit-daemon.service      loaded active running RealtimeKit Scheduling Policy Service             
  systemd-journald.service  loaded active running Journal Service                                   
  systemd-logind.service    loaded active running User Login Management                             
  systemd-machined.service  loaded active running Virtual Machine and Container Registration Service
  systemd-resolved.service  loaded active running Network Name Resolution                           
  systemd-timesyncd.service loaded active running Network Time Synchronization                      
  systemd-udevd.service     loaded active running Rule-based Manager for Device Events and Files    
  udisks2.service           loaded active running Disk Manager                                      
  upower.service            loaded active running Daemon for power management                       
  user@1000.service         loaded active running User Manager for UID 1000                         
  wpa_supplicant.service    loaded active running WPA supplicant  
hateWin ★☆
() автор топика

Вот прямо сейчас копирую на внешний диск фильмы и запускаю виртуалку с федорой, сразу после запуска копирования открыл еще и либру. Ничего не зависает. Пользоватся компом комфортно. Музыка с ютуба не запинается. Ядро 4.19.

hateWin ★☆
() автор топика
Ответ на: комментарий от fernandos

Своп есть? И какое ядро 5.10 вы поставили?

Своп есть. Дисковый + zswap. Ядро 5.10.16. Но, судя по выхлопу top, памяти было достаточно.

hateWin ★☆
() автор топика
Ответ на: комментарий от hateWin

Эти значения высчитываются исходя из объёма ОЗУ. Уже не упомню точно но вроде как то что у меня было под 8Гб. Это всё равно не спасает полностью но ситуацию при интенсивном дисковом обмене улучшало. Проверь диск/и, глянь SMART Current pending и Relocated event cont ну и Relocated sector count хотя-бы если в лом весь винт на чтение прогнать..

VKraft ★★
()
Ответ на: комментарий от AlexVR

лол, как году в 2010 (что ли?) правил статью, так всё и осталось, даже мои собственные косяки и фейспалмы.

darkenshvein ★★★★★
()
Ответ на: комментарий от hateWin

Поставил стоковое 5.10, нет подобной проблемы. Забил память — всё прекрасно работает. А попробуйте процесс, который грузит диск, через ionice с 7.

fernandos ★★★
()
Ответ на: комментарий от post-factum

vm.overcommit_memory=2 запрещает оверкоммит. Теоретически, процесс, запрашивающий больше значения, определяемого overcommit_ratio, должен быть убит ядром. Я так понимаю.

vm.vfs_cache_pressure=20

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

hateWin ★☆
() автор топика
Ответ на: комментарий от hateWin

vm.overcommit_memory=2 запрещает оверкоммит. Теоретически, процесс, запрашивающий больше значения, определяемого overcommit_ratio, должен быть убит ядром. Я так понимаю.

Всё так:

overcommit_memory
=================

This value contains a flag that enables memory overcommitment.

When this flag is 2, the kernel uses a "never overcommit" policy that attempts to prevent any overcommit of memory.

overcommit_kbytes
=================

When overcommit_memory is set to 2, the committed address space is not permitted to exceed swap plus this amount of physical RAM.

overcommit_ratio
================

When overcommit_memory is set to 2, the committed address space is not permitted to exceed swap plus this percentage of physical RAM.

Но на вопрос «зачем» это не отвечает. Равно как и на вопрос, чем тебе неугоден оверкоммит.

vm.vfs_cache_pressure=20

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

На всякий случай, здесь идёт речь не о page cache, а о dentry/inode cache:

vfs_cache_pressure
==================

This percentage value controls the tendency of the kernel to reclaim the memory which is used for caching of directory and inode objects.

At the default value of vfs_cache_pressure=100 the kernel will attempt to reclaim dentries and inodes at a "fair" rate with respect to pagecache and swapcache reclaim.  Decreasing vfs_cache_pressure causes the kernel to prefer to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will never reclaim dentries and inodes due to memory pressure and this can easily lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim dentries and inodes.

И это опять же не отвечает на вопрос, зачем ты менял значение.

post-factum ★★★★★
()
Последнее исправление: post-factum (всего исправлений: 1)
Ответ на: комментарий от post-factum

должен быть убит ядром. Я так понимаю.

Всё так:

Не убит, а сам упадет ошибкой Page allocation failure (если не обработает исключение).

hakavlad ★★★
()
Ответ на: комментарий от hateWin

zram/zswap, резервирование файловых страниц (через сторонние патчи), ранний OOM в юзерспейсе (systemd-oomd, earlyoom, nohang, хз чё там ещё есть), uksmd (тоже через сторонние патчи).

post-factum ★★★★★
()
Ответ на: комментарий от post-factum

Хорошо, буду использовать изерспейсный oom-киллер. А чем тебе не понравилось уменьшение cache_pressure?

hateWin ★☆
() автор топика
Ответ на: комментарий от hateWin

Только что протестировал. earlyoom очень долго думал, перед тем, как убить tail /dev/zero. При этом гном завис и упал. Пришлось заново входить в систему. С memory_overcommit=2 tail /dev/zero достаточно быстро упал. При этом, зависания не произошло.

hateWin ★☆
() автор топика
Ответ на: комментарий от hateWin

Память тратится впустую, если у тебя не что-то такое, для чего большой dentry/inode кеш нужен (например, сервер почты).

post-factum ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.