systemd-journald жрёт 80% цпу

А то, что у тебя рядом три сислога которые жрут почти в два раза больше это типа нормально?

Удваиваю вопрос про три сислога. Журналд форвардит во все их, потому и жрёт.

Так что в самих логах то?

[systemd]

[ubuntu]

/0

[/thread]

P.S. Три rsyslog это сила. У них там стопудово битва дисками между друг другом, пока Трон спит. Но в первую очередь все катают бочку именно на systemd, ага.

Но в первую очередь все катают бочку именно на systemd, ага.

А что делать, если у systemd репутация как у автоваза.

Это не три рсислога, это дебильный хтоп, который по умолчанию треды показывает как процессы

Он один, man htop

Если бы у потоков были разные PID, то все PID заняли бы раньше, чем запустился бы Firefox.

Если бы у потоков были разные PID, то все PID заняли бы раньше, чем запустился бы Firefox.

Ты не поверишь, но у потоков действительно разные PID :)

вобще как-то совсем не нормально. при поточной записи у тебя диск должен тупить в крайнем случае, но уж точно не процессор. а что в логах? много их?

в официальной редхатовской документации делают морду тяпкой и без объяснения причин сообщают, что теперь есть два разных средства логирования, с разным набором функций и как они друг-друга дополняют, и как их теперь дружить. читал и плакал.

Ты не поверишь, но у потоков действительно разные PID :)

В LinuxThreads так было, да.

а что в логах?

Там много всего... В общем, думаю, что это связано с выборочным откключением/включением плагинов компиза накануне... После довольно долгой перезагрузки всё вернулось в норму.

я имел ввиду, сколько мегобайт в минуту...

Если мне память не изменяет, у PID и TID пространство значений общее.

Если мне память не изменяет, у PID и TID пространство значений общее.

Это было давно. Попробуй ps -eLf.

А как это можно было бы посмотреть?

Я имею в виду, что если мы возьмем pid/tid пробежавшись по /proc/[pid]/tasks/[tid] мы найдем только одно совпадение pid и tid (для каждого процесса pid в его tasks есть такой же tid). PID для всех задач в tasks действительно общий.

Короче, вот:

/**
 * sys_getpid - return the thread group id of the current process
 *
 * Note, despite the name, this returns the tgid not the pid.  The tgid and
 * the pid are identical unless CLONE_THREAD was specified on clone() in
 * which case the tgid is the same in all threads of the same group.
 *
 * This is SMP safe as current->tgid does not change.
 */
SYSCALL_DEFINE0(getpid)
{
	return task_tgid_vnr(current);
}

/* Thread ID - the internal kernel "pid" */
SYSCALL_DEFINE0(gettid)
{
	return task_pid_vnr(current);
}

очень просто. пример:

grep "Feb  1 17:28" /var/log/messages > /tmp/1min.log;
du -sh /tmp/1min.log;