Почему "strace" не показывает, что этот процесс чего-то ждет?


11

Могучий 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


Хм ... так как ваша программа "foo" - это не просто однопоточный, однопоточный процесс, вам будет лучше, если вы попросите strace следовать и присоединяться к вилкам. '-ff' твой друг! :) Затем вы также захотите использовать «-o / dev / shm / strace-foo», чтобы собрать все выходные файлы процесса strafe в одном месте. Просто предложение.
Джесси Адельман

@JesseAdelman Я думаю, что journalctlзапускает только один процесс. У меня есть ощущение, journalctlчто по какой-то причине используется один дополнительный поток - в iirc был один вызов clone (). Я думаю, что это означает, что вы технически правы, но это также технически не имеет отношения к вопросу. timeсмотрит на процесс в целом и показывает, что процесс в целом довольно сонный (блокирование чего-либо). straceне показал достаточно спит. Не имеет значения, если второй поток спит, основной поток также должен быть очень сонным, чтобы объяснить timeрезультат.
sourcejedi

Ответы:


18

Обычная причина для решения этой проблемы, заключается в том, что процесс блокирует ошибки страницы. Это чтение или, возможно, запись в файлы, выполняемые через отображение памяти mmap(). Возможно, вы заметили некоторые mmap()из следов системных вызовов.

Если бы вы использовали /usr/bin/timeпрограмму вместо timeвстроенной оболочки, вы могли бы также заметить:

0.04user 0.10system 0:02.29elapsed 6%CPU (0avgtext+0avgdata 40464maxresident)k
73632inputs+0outputs (376major+1081minor)pagefaults 0swaps

majorpagefaults - это те, которые требуют ввода-вывода файловой системы. minorсбои страниц гораздо менее значительны (вероятно, только «промах TLB»).

Я подозреваю inputs, что общее количество прочитанных страниц. В настоящее время я думаю, что отображаемые на файл страницы всегда имеют одинаковый размер. 4096 байт в большинстве случаев, но вы можете проверить getconf PAGESIZE.

Таким образом, это составляет ~ 290 мегабайт, считывание со скоростью более 100 мегабайт в секунду, стандартная скорость для жесткого диска, подобного моему. Тайна разгадана!


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

straceтолько показывает, когда процесс входит (и затем покидает) ядро ​​из-за системного вызова. Или когда сигнал unix доставлен. Однако существуют другие типы прерываний, которые straceвообще не отображаются. Так что они включают

  • Ошибки страницы.
  • Таймер прерывания. Это используется для переключения на другой процесс, когда текущий исчерпал свой выделенный временной интервал на ЦП.

1
Хороший ответ, поздравляю! Действительно важно понимать ограничения инструментов, которые вы используете. +1; Мне также нравится эта тема: unix.stackexchange.com/questions/418354/… и unix.stackexchange.com/questions/419697/…
Руи Ф. Рибейро,
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.