Вопрос или проблема
В моей системе Ubuntu 20 Desktop каждую минуту генерируется 360 МБ данных журнала, и мой процессор загружен на 100%, выполняя systemd-journal.
Каждую минуту в папке /var/log/journal/42b76941196c44ebabf29f6efc5047c7/ сохраняются 128 Мб * 3 файла.
Я очищаю журнал этой командой вручную.
sudo journalctl --vacuum-size=50M
Удален архивированный журнал /var/log/journal/42b76941196c44ebabf29f6efc5047c7/system@00000000000000000000000000000000-00000000015de62d-0005a8bd92211c3a.journal (128.0M).
Удален архивированный журнал /var/log/journal/42b76941196c44ebabf29f6efc5047c7/system@00000000000000000000000000000000-000000000160c6b7-0005a8bd93351c1b.journal (128.0M).
Удален архивированный журнал /var/log/journal/42b76941196c44ebabf29f6efc5047c7/system@00000000000000000000000000000000-000000000163a7b1-0005a8bd945c0bf2.journal (128.0M).
Очистка завершена, освобождено 3.8G архивированных журналов из /var/log/journal/42b76941196c44ebabf29f6efc5047c7.
Очистка завершена, освобождено 0B архивированных журналов из /run/log/journal.
За несколько минут создано 3.8 ГБ данных, и файлы журнала продолжают создаваться, а мой процессор всегда загружен на 100%.
В настоящее время я изменил следующие настройки:
Используя sudo nano /etc/systemd/journald.conf, я изменил эти настройки:
SystemMaxUse=50M
Software=none -- После добавления этой строки создание файлов прекратилось, но процесс systemd-journal использует 100% ЦП.
MaxLevelStore=err
MaxLevelSyslog=warning
MaxLevelKMsg=warning
MaxLevelConsole=err
> top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >
328 root 19 -1 468040 265696 263872 R 100.0 1.6 31:13.14 systemd-journal
/var/log/journal/42b76941196c44ebabf29f6efc5047c7 ls -lhsa
total 3.5G
12K drwxr-sr-x+ 2 root systemd-journal 12K Jun 23 11:01 .
4.0K drwxr-sr-x+ 3 root systemd-journal 4.0K Jun 15 02:45 ..
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:53 system@00000000000000000000000000000000-0000000000b928b7-0005a8bd50cff991.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:53 system@00000000000000000000000000000000-0000000000bc0a5c-0005a8bd51dfebc1.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:53 system@00000000000000000000000000000000-0000000000beeae8-0005a8bd5327bbb9.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:54 system@00000000000000000000000000000000-0000000000c1cf12-0005a8bd5491ec30.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:54 system@00000000000000000000000000000000-0000000000c4b0ab-0005a8bd55a40899.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:54 system@00000000000000000000000000000000-0000000000c7947b-0005a8bd56bf31e1.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:54 system@00000000000000000000000000000000-0000000000ca7b31-0005a8bd57e08298.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:55 system@00000000000000000000000000000000-0000000000cd5d82-0005a8bd58f27c6f.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:55 system@00000000000000000000000000000000-0000000000d0421e-0005a8bd5a0eb633.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:55 system@00000000000000000000000000000000-0000000000d324e0-0005a8bd5b414cea.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:56 system@00000000000000000000000000000000-0000000000d60651-0005a8bd5c5b194e.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:56 system@00000000000000000000000000000000-0000000000d8eb81-0005a8bd5d7f5e1d.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:56 system@00000000000000000000000000000000-0000000000dbd098-0005a8bd5e9a9369.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:57 system@00000000000000000000000000000000-0000000000deb64b-0005a8bd5fbe668e.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:57 system@00000000000000000000000000000000-0000000000e19c03-0005a8bd60d8c9fe.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:57 system@00000000000000000000000000000000-0000000000e4814d-0005a8bd61ee85f3.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:58 system@00000000000000000000000000000000-0000000000e766ad-0005a8bd63092fa2.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:58 system@00000000000000000000000000000000-0000000000ea47e6-0005a8bd6420b7d5.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:58 system@00000000000000000000000000000000-0000000000ed2b78-0005a8bd6592ecbf.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:59 system@00000000000000000000000000000000-0000000000f011ae-0005a8bd66fd52a8.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:59 system@00000000000000000000000000000000-0000000000f2f60c-0005a8bd68164432.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 10:59 system@00000000000000000000000000000000-0000000000f5d72f-0005a8bd69297455.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 11:00 system@00000000000000000000000000000000-0000000000f8bb3a-0005a8bd6a453704.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 11:00 system@00000000000000000000000000000000-0000000000fb9c70-0005a8bd6b770daa.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 11:00 system@00000000000000000000000000000000-0000000000fe8190-0005a8bd6c92d47f.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 11:01 system@00000000000000000000000000000000-00000000010166e5-0005a8bd6dac401f.journal
129M -rw-r-----+ 1 root systemd-journal 128M Jun 23 11:01 system@00000000000000000000000000000000-0000000001044c9e-0005a8bd6ecfe4c3.journal
24M -rw-r-----+ 1 root systemd-journal 24M Jun 23 11:01 system.journal
8.0M -rw-r-----+ 1 root systemd-journal 8.0M Jun 23 11:01 user-1000.journal
Сведения о системе :
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
Как остановить systemd-journal, чтобы он не использовал 100% ресурсов ЦП?
Вот несколько шагов, которые я предпринял после изучения журналов.
В моей папке /var/log эти два файла также занимали по 71 ГБ.
cd /var/log
ls -lsha
71G -rw-r----- 1 syslog adm 71G Jun 24 15:51 kern.log
71G -rw-r----- 1 syslog adm 71G Jun 24 15:52 syslog
Я просмотрел эти файлы
sudo tail -n 10 /var/log/syslog
Jun 24 15:52:17 crusader update-notifier.desktop[3393]: Невозможно получить статистику файла /proc/3137/fd/10: Доступ запрещен
Jun 24 15:52:17 crusader update-notifier.desktop[3393]: Невозможно получить статистику файла /proc/3137/fd/11: Доступ запрещен
Jun 24 15:52:17 crusader update-notifier.desktop[3393]: Невозможно получить статистику файла /proc/3137/fd/16: Доступ запрещен
Jun 24 15:52:17 crusader update-notifier.desktop[3393]: Невозможно получить статистику файла /proc/3137/fd/17: Доступ запрещен
Jun 24 15:52:48 crusader gnome-shell[1903]: Некоторый код получил доступ к свойству 'discreteGpuAvailable' в модуле 'appDisplay'. Это свойство было определено с помощью 'let' или 'const' внутри модуля. Это было ранее поддержано, но не является правильным согласно стандарту ES6. Любые символы, которые должны быть экспортированы из модуля, должны быть определены с помощью 'var'. Получение доступа к свойству будет работать как и раньше, но, пожалуйста, исправьте ваш код в любом случае.
Jun 24 15:52:48 crusader gnome-shell[1903]: ../clutter/clutter/clutter-actor.c:10556: Функцию clutter_actor_set_allocation() можно вызывать только из реализации виртуальной функции ClutterActor::allocate().
sudo tail -n 10 /var/log/kern.log
ieport 0000:00:1c.5: AER: Ошибка шины PCIe: severity=Исправлена, type=Физический уровень, (Идентификатор принимающего) Jun 2 pcieport 0000:00:1c.5: AER: устройство [8086:9d15] статус/маска ошибки=00000001/00002000 kernel: [ 178.057760] pcieport 0000:00:1c.5: AER: [ 0] RxErr
Я открыл файл grub и изменил эту строку…
sudo nano /etc/default/grub
#GRUB_CMDLINE_LINUX_DEFAULT='quiet splash'
на строку ниже:
GRUB_CMDLINE_LINUX_DEFAULT='quiet splash pci=noaer'
ctrl o
enter
ctrl x
перезагрузка
Перезагрузил систему, и когда я запустил команду top, теперь использование моего ЦП вернулось к прежнему. То есть процесс systemd-journal не работает и не использует 100% моего ЦП.
На данный момент система работает нормально.
Я также запустил несколько команд перед выполнением вышеуказанных команд.
sudo apt-get update
sudo apt-get dist-upgrade
Ответ или решение
Для решения проблемы с тем, что systemd-journal занимает 100% ресурсов процессора и создает 360 МБ журналов каждую минуту на системе Ubuntu 20.04 LTS, вам необходимо выполнить несколько шагов для диагностики и устранения проблемы.
1. Анализ и диагностика
Сначала вам нужно выяснить, какие именно службы или процессы создают такое количество записей в журнале. По вашему описанию видно, что в /var/log/syslog и /var/log/kern.log содержится много записей, и, возможно, это связано с проблемами, которые возникают в системе. Выполнение команды:
sudo tail -n 50 /var/log/syslog
sudo tail -n 50 /var/log/kern.logможет помочь вам определить, какие ошибки генерируются. Элементы, связанные с PCI, такие как в вашем случае:
AER: PCIe Bus Error: severity=Corrected, type=Physical Layerпоказывают, что ваш процессор активно регистрирует ошибки аппаратного обеспечения.
2. Изменение настроек journald
Изменение файла конфигурации journald — это один из первых шагов для предотвращения роста журналов. Вы уже внесли изменения в /etc/systemd/journald.conf, что является правильным шагом. Убедитесь, что параметры указаны следующим образом:
[Journal]
SystemMaxUse=50M
SystemMaxFileSize=16M
MaxLevelStore=err
MaxLevelSyslog=warning
MaxLevelKMsg=warning
MaxLevelConsole=err3. Устранение проблем с аппаратным обеспечением
Ваша запись Cannot stat file /proc/...: Permission denied и другие подобные ошибки говорят о том, что ваш код или приложения пытаются получить доступ к недоступным ресурсам. Убедитесь, что все драйверы и обновления для вашего оборудования установлены и настроены правильно.
4. Настройка GRUB
Вы внесли изменения в конфигурацию загрузчика GRUB, добавив параметр pci=noaer, чтобы отключить регистрации об ошибках PCI. Это может помочь уменьшить нагрузку на systemd-journal, так как это предотвратит обработку ошибок, которые приводят к записям в журналы.
Убедитесь, что вы выполните команду:
sudo update-grubчтобы изменения вступили в силу.
5. Очистка и контроль за журналами
Поскольку журналов создается слишком много, вы можете вручную производить очистку, когда это необходимо. Используйте команду:
sudo journalctl --vacuum-size=50MОднако, чтобы избежать их стремительного роста, следите за системными процессами и логами, которые создают эти записи. Возможно, вам потребуется периодически проверять логи и удалять ненужные записи.
6. Регулярное обновление
Убедитесь, что ваша система обновлена. Регулярное выполнение команды:
sudo apt-get update
sudo apt-get upgradeпоможет вам исправить некоторые ошибки в системных пакетах и драйверах.
Итог
В целом, для решения проблемы с высоким потреблением CPU процессом systemd-journal вам нужно провести диагностику, выявить и устранить причины интенсивного логирования, оптимизировать настройки журналирования и следить за состоянием аппаратного обеспечения. Если после всех предложенных действий проблема будет сохраняться, может потребоваться более глубокий анализ с использованием специализированных инструментов для диагностики системы.