Могучий strace
подвел меня. Как это возможно?
time foo
показывает, что foo
для запуска требуется несколько секунд («реальный»), но используется незначительное время процессора, как в пользовательском пространстве («пользователь»), так и в ядре («sys»). Для любопытных foo
определяется ниже.
Поэтому он проводит большую часть своего времени в ожидании чего-то другого, а не выполнения инструкций процессора. Обычно я вижу, как он ожидает strace
- то есть какой системный вызов блокируется на длительный период времени. К сожалению, этот подход не сработал.
strace -ttt -T -C -w foo
показывает системные вызовы, отметку времени и сводку (реального) времени, проведенного в системных вызовах. Но этот конкретный процесс показал, как тратит незначительное общее (реальное) время внутри системных вызовов.
foo
на самом деле journalctl -b -u dev-hugepages.mount
. За исключением того, что мне пришлось каждый раз менять последний аргумент на другой системный блок, чтобы воспроизвести это. Другими словами, задержка, которую я исследую, произошла в первый раз, когда я пытаюсь получить журналы для какого-либо одного системного устройства. РЕДАКТИРОВАТЬ : после ответа на главный вопрос, я также понял причину, по которой у меня была эта проблема воспроизводить задержку .
Время, затрачиваемое на этот процесс, является специфической проблемой, по-видимому, это происходит не во всех системах. https://github.com/systemd/systemd/issues/7963
journalctl
запускает только один процесс. У меня есть ощущение, journalctl
что по какой-то причине используется один дополнительный поток - в iirc был один вызов clone (). Я думаю, что это означает, что вы технически правы, но это также технически не имеет отношения к вопросу. time
смотрит на процесс в целом и показывает, что процесс в целом довольно сонный (блокирование чего-либо). strace
не показал достаточно спит. Не имеет значения, если второй поток спит, основной поток также должен быть очень сонным, чтобы объяснить time
результат.