Ubuntu продолжает зависать

У моего ноутбука есть SSD и 16 ГБ ОЗУ, поэтому я знаю, что проблема не в характеристиках.

Этот ноутбук раньше работал на Windows, и у меня никогда не было проблем с производительностью, но это изменилось с тех пор, как я перешел на Ubuntu.

Я сделал это, потому что работаю с Docker, а он работает быстрее на Linux.

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

У кого-нибудь есть идеи, что может вызывать это? Это происходит как минимум 3 раза в день, и я в ярости.

Я обычно использую Docker, Firefox, Discord и VSCode одновременно. Я использовал все это на Windows и никогда не имел проблем (за исключением того, что Docker работает гораздо лучше на Linux).

Есть какие-либо мысли?

Я сообщаю, что наблюдаю такую же проблему на более старом ноутбуке с SSD и всего 3 ГБ ОЗУ. Я следил за использованием ОЗУ и свопа, и временно увеличивал ОЗУ, но это не повлияло на проблему. У меня работал Docker с Portainer, но ничего не делал. Зависание происходило очень быстро в любой сессии Firefox или Vivaldi, но не в сессии Dillo. Зависание также происходило в Thunderbird в тот момент, когда Thunderbird, возможно, пытался выйти в интернет.

Когда начинается зависание, браузер и большинство операций на рабочем столе становятся неотзывчивыми, но мышь все еще перемещает указатель. Клавиатура со временем окончательно становится неактивной. Например, индикатор Caps Lock работает до какого-то момента. Время от времени возникают краткие моменты жизни, пока не произойдет еще одно зависание, как неотзывчивое всплывающее сообщение. Если я достаточно быстр и подготовлен, я могу переключиться в режим TTY и завершить браузер в HTOP. Жизнь восстанавливается после этого. Если я ничего не делаю, вся система в конечном итоге становится неотзывчивой. Неважно, используем ли мы рабочий стол Ubuntu или Kubuntu. Я сейчас использую Kubuntu 22 с “nomodeset” и без Docker. Это более старый ноутбук. “Nomodeset” принес другие улучшения. Пока зависаний не было без запущенного Docker (я бы никогда не смог бы опубликовать это сообщение), но я пока его не запускал. Я хотел бы больше информации для устранения неполадок и также больше времени без зависаний в текущем состоянии, прежде чем снова начать работать с Docker. Во всех моих тестах я запускал только браузер и уделял внимание использованию ОЗУ. Я также увеличил доступное пространство для свопа, но это тоже не помогло.

Я смотрел разные журналы, но не заметил ничего. Во-первых, я не уверен, что смогу что-то заметить, и, во-вторых, мне интересно, препятствует ли зависание ведению журнала. Я много раз пытался подключиться к ноутбуку через SSH, когда он зависает. Всегда нет улик о том, что ноутбук подключен к LAN.

Не помню, было ли избыточное тепло или работали ли вентиляторы, или даже ощущение тепла после того, как оставлял ноутбук в покое. Я бы сказал, что он, скорее всего, был холодным.

У меня есть такая же модель, переработанный ноутбук, работающий на Ubuntu 20.4 в режиме постоянной работы над задачами Docker. Я никогда не видел этой проблемы с ним. Единственное физическое различие между ними, кроме ОЗУ, заключается в том, что в этом, у которого есть проблемы, нет аккумулятора. Я не помню, тестировал ли я его с батареей другого ноутбука.

Я вижу много случаев этой проблемы, т.е. зависание в браузере или почтовом приложении, которые сообщаются в интернете. Некоторые из них уходят далеко в прошлое. Я никогда не вижу никаких определенных объяснений того, что происходит или что именно диагностически проверить. Я думаю, что мой пост может быть полезным. Мой личный опыт с этой проблемой, должно быть, поможет. Это противоречит тому, что Ask Ubuntu говорит о том, что должно быть в “ответе”. Думаю, мне стоит извиниться за такое мнение.

Это довольно неясно, но в случае, если это связано с чрезмерным использованием ОЗУ, вы можете ограничить размер сегмента данных процессов по вашему выбору. Один из простых способов сделать это — открыть окно терминала bash, ввести, скажем, ulimit -d 4194304 (размер сегмента данных ограничен до 4 ГБ). Все, что запускается из этого окна (не из меню менеджера сессий или другого окна терминала), будет иметь ограниченный размер сегмента данных, а значит, и использование ОЗУ. Если запросы на выделение памяти выйдут из-под контроля по какой-то причине, запросы brk() в какой-то момент будут отклонены, что может либо заставить процесс адаптироваться к этой ограниченной среде, либо (более вероятно) завершиться с ошибкой.

Я систематически использую это для своих сессий Firefox с тех пор, как у меня был плохой опыт, посещая сомнительный сайт, из-за которого вся моя система замерзла несколько лет назад. Я настроил эквивалентный скрипт на Windows, используя Job Objects.