Comments 28
Теперь кто-бы исследовал, почему после обновления Ubuntu с 22.04 до 24.04 она стала периодически очень сильно тормозить, как будто постоянно ждет диска. Особенно заметно сразу после старта -- в течении 10 минут прям очень сильно. Пока удалось выяснить, что причина вроде в журнале файловой системы, т.к. нагружает процесс [jbd2/sdaX] (но до конца не уверен, т.к. тормоза бывали и без этого процесса в выводе). Причем такие проблемы обсуждались где-то в 2016, но в Ubuntu 22.04 их не было, а в Ubuntu 24.04 вдруг вылезли непонятно почему.
Теперь кто-бы исследовал, почему после обновления Ubuntu с 22.04 до 24.04 она стала периодически очень сильно тормозить
Ну как же, всем ведь известно что "нейросети скоро вас всех заменят" (цитата одного менеджера), так что спрашивайте ChatGPT сразу :)
Если серьезно то изучать проблемы пользовательских сетапов на Linux — пустое, поскольку проще переустановить.
Я сталкивался с подобными проблемами на серверах хостинга с десктопными nvme-дисками. Я до конца не раздебажил эту проблему, но кое-как локализовал.
Нагрузка процесса журналирования ext4 была следствием.
А причиной было стечение обстоятельств - распаковка больших архивов с кучей мелких файлов, не оптимизированные сайты без кешей и прочих прелестей ходящие за каждым файлов в диск, высокие (для этого сервера) нагрузки на БД из-за неоптимизированного сайта и десктопные диски.
Диски не были готовы к таким объёмам таких транзакций и начинали тормозить. От этого росло LA и тормозило всё.
Так что смотрите состояние диска, смотрите нагрузку на диск до этой проблемы (можно мониторинги всякие прикрутить). Возможно обновление между убунтами это лишь совпадение.
Ну, это мой разработческий декстоп, а не сервер. Железо не менялось. Состояние диска -- SMART вроде показывает, что все в порядке, каждый раз, как пытаюсь поймать проблему всякими top, atop, iotop, ничего непонятно. Вроде бы ничего не потребляет прям слишком уж много. Вот только, как уже говорил, несколько раз замечал странные процессы [jbd2/sdaX], погуглил -- это оказались журналы. Либо настройки журналирования при апгрейде поменялись, либо это следствие чего-то, но чего, пока никак поймать не могу.
потомучто при обновлении какой-то компонент или библиотека не может стартануть, это можно увидеть в фрибсд на гноме не из портов, по core.dump в корне пользователя, тоесть если у вас какаято проблема, вам надо понять как проверять целостность самого гнома(как проверить зависимости какие библиотеки нужны в таком то компоненте)
тоесть при обновлении надо поставить медианную версию где все либы слинкованы в гном и рабочие при обращении к которым нету деприкейтед что-то такое
на самом деле вам было бы удобнее если бы вы могли на голую убунту без граффики поставить motif и там ниче не вылетит если грамотно выбрать приложения(просмотрщик файлов, видео проигрыватель, браузер и прочее)
еще по разнице с фрибсд у вас стоит снап и системд и они тоже имеют обращения к библиотекам или могут быть зарегестрированы компоненты устаревшие
ну и как вывод из такой тщательной проверки придётся разбираться как настраивать компонент(рассмотрим пример например открываем калькулятор и он тут же вылетает)
Дивный мир обновлений Ubuntu. Каждый новый релиз это лотерея, никогда не знаешь, что отвалится в этот раз
В принципе, ожидаемо от бубунты
-- А знаешь как у этих BSD-ишников называется epoll() ?
-- Как ?
-- kqueue()
-- Вот негодяи!
Технически статья интересна, как происходило решение проблемы.
Но организационные вопросы остались.
А у заказчика точно был сисадмин? У меня слова сервер, не LTS и snapd, в таком сочетании вызывают когнитивный диссонанс. Добавляем GNOME и получаем desktop.
Хотя... Пути заказчиков неисповедимы.
Близкая история: отдел безопасности решил активно тестировать сервера, не только снаружи, но из изнутри, запуская различные тесты сканером безопасности. В какой то момент времени сервера начали виснуть. Сисадмины неделю(?) не могли понять что происходит. Когда информация о таком положении вещей попала ко мне, я пошел и поставил kdump, что бы отловить что именно падает. После очередного падения, посмотрев на дамп ядра и увидев что то похожее на nfs драйвер, пошел смотреть на близкие версии ядер, и обнаружил что буквально в следующем ядре, по патчам, эту проблему решили. Предложил обновить ядро сисадминам, и жить счастливо)
Не хватает нулевого пункта в выводах: apt-get purge snapd
Какая-то проприетарная штука ломится раз в пять минут куда-то к себе... еще и проц нагружает в 100%
Ещё не хватает минус первого пункта в выводах: нечего сидеть на не-LTS.
Они уже сделали, чтобы нельзя было одной командой "это" выпилить
можно снести все снапы и отключить сервис. Утерянное дисковое пространство можно пережить
Можно, но быстрее установить ArchLinux только с теми пакетами, которые нужны для работы.
6.14 ядро и snap использует еще как минимум Majaro Linux - форк вашего любимого ArchLinux.
Так что есть все шансы налететь и там.
Да кстати, я не упоминал что проблема со 100% загрузкой вылезла не только в одном snapd и были другие приложения, которых этот баг затронул?
Не упоминал, увы.
Хороших снов, как говорится ;)
При чём тут Manjaro :) Каждый дистрибутив может пойти своим путём и не факт, что правильным. Я про ArchLinux говорю только из-за того, что там собрать можно всё быстрее и менее трудозатратнее, чем из тех же Gentoo и LFS. А использовать можно хоть debootsptrap. Просто snap обычно используют те, кому не хватает пакетной базы из дистрибутива. В AUR как раз много пакетов и можно найти почти всё, что необходимо. В Fedora тоже много пакетов, но там flatpak :)
Да, на сервере только арча мне и не хватало.
Тогда вы лишаетесь Livepatch в убунтах.
Неужели заказчику нужен был на его сервере snapd и неужели сервер не настраивался от лишней активности администратором. Я даже на домашнем десктопе этот снэп сношу сразу...
О да, проблема прикладного сервиса уперлась в ядро - классика. У меня так было с багом в сетевом драйвере, который вешал сервер под высокой нагрузкой. Тоже пришлось копать до самого низа. Сочувствую и жму руку
Этот потоп заказухи на тему "линуксу -- всё" по странному стечению обстоятельств совпал со временем, когда разработчики ядра послали российских коллег на три весёлые буквы. Это совпадение, конечно же, случайно, и новые звёздочки на погоны никому не светят, да ?
snapd, 100% загрузка cpu и баг ядра