Как я могу профилировать файловый ввод-вывод?

Наша сборка раздражающе медленная. Это система Java, созданная с помощью Ant, и я запускаю свою на Windows XP. В зависимости от аппаратного обеспечения это может занять от 5 до 15 минут.

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

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

Какие есть инструменты профилирования, которые сообщат мне, что данный процесс делает с какими файлами? Бесплатно это хорошо, но не обязательно.


Используя Process Monitor, предложенный Джоном Скитом, я смог подтвердить мое подозрение: почти вся активность диска заключалась в чтении и повторном чтении библиотек, причем копии JDK "rt.jar" и других библиотек находились вверху списка. Я не могу сделать RAM-диск достаточно большим, чтобы вместить все библиотеки, которые я использовал, но установка «горячих» библиотек на RAM-диск сократила время сборки примерно на 40%; ясно, что кэширование файловой системы Windows недостаточно хорошо справляется со своей задачей, даже несмотря на то, что я сказал Windows оптимизировать для этого.

Одна интересная вещь, которую я заметил, заключается в том, что типичная операция «чтения» в JAR файл всего несколько десятков байт; обычно их два или три, за которыми следует пропуск на несколько килобайт дальше в файле. Оказалось, что он не подходит для массового чтения.

Я собираюсь провести дополнительное тестирование всех моих сторонних библиотек на флэш-накопителе и посмотреть, как это повлияет.


person erickson    schedule 29.01.2009    source источник
comment
Один быстрый вопрос, Эриксон, как вы выяснили, сколько байт считывается с помощью ProcessMonitor? У меня та же проблема, когда я пытаюсь профилировать наши сборки с помощью Windows XP.   -  person Alex. S.    schedule 24.10.2012
comment
Только сейчас разобрался, например, в столбце Detail для операций ReadFile написано Offset: N bytes, Length: M bytes и так далее.   -  person Alex. S.    schedule 24.10.2012


Ответы (5)


Если вам только это нужно для Windows, SysInternals монитор процессов должен показать вам все, что вам нужно знать. Вы можете выбрать процесс, а затем просмотреть каждую операцию по мере ее выполнения, а также получить сводку по операции с файлом.

person Jon Skeet    schedule 29.01.2009
comment
Спасибо, Джон. Я использовал Process Explorer в прошлом. Это преемник того продукта или что-то совершенно отдельное? - person erickson; 29.01.2009
comment
Process Explorer — своего рода альтернатива диспетчеру задач. Process Monitor показывает вам каждую операцию ввода-вывода, такую ​​как открытие файла, запись в реестр и т. д. - person lacop; 29.01.2009

Старое, но полезное: создайте RAM-диск и скомпилируйте файлы оттуда.

person Jeffrey Fredrick    schedule 30.01.2009
comment
Моя цель при профилировании ввода-вывода — выяснить, что больше всего выиграет от размещения на RAM-диске. - person erickson; 31.01.2009

Раньше, когда я все еще использовал Windows, я получал хорошие результаты, ускоряя сборку, записывая все выходные данные сборки в отдельный раздел размером, возможно, 3 ГБ, и периодически форматируя его ночью раз в неделю с помощью запланированного задания. Это просто вывод сборки, поэтому не имеет значения, если он время от времени сглаживается в одностороннем порядке.

Но, честно говоря, с тех пор, как я перешел на Linux, я больше не беспокоюсь о фрагментации диска.

Еще одна причина попробовать вашу сборку на Linux хотя бы один раз, чтобы вы могли запустить strace. (собраны для вызовов open), чтобы увидеть, какие файлы затрагивает ваша сборка.

person Ben Hardy    schedule 30.01.2009
comment
Procmon/Filemon предоставляют похожую (фактически) информацию для strace. Я мог видеть каждую операцию открытия, запроса метаданных, чтения и записи. - person erickson; 31.01.2009

Раньше я создавал массивное веб-приложение Java (интерфейс JSP) с помощью Ant в Windows, и это занимало более 3 минут. Я очистил свой компьютер и установил Linux, и внезапно сборка заняла 18 секунд. Это реальные цифры, хотя им около 3 лет. Я могу только предположить, что Java предпочитает модели управления памятью и потоковой передачи Linux эквивалентам Windows, поскольку, по моему опыту, все Java-программы работают лучше под Linux (особенно Eclipse). Linux кажется намного лучше в предотвращении дополнительных чтений с диска, когда вы много читаете файлы, которые не изменились (например, исполняемые файлы и библиотеки). Это может быть свойство дискового кеша или файловой системы, я не уверен.

Одна из замечательных особенностей Java заключается в том, что она является кросс-платформенной, поэтому настройка сервера сборки на базе Linux на самом деле является вариантом для вас. Будучи кем-то вроде евангелиста Linux, я, конечно, предпочел бы, чтобы вы переключили свою среду разработки на Linux, но я знаю, что многие люди не хотят этого делать (или не могут по практическим причинам).

Если вы не хотите даже настраивать сервер сборки Linux, чтобы посмотреть, будет ли он работать быстрее, вы можете хотя бы попробовать дефрагментировать жесткий диск вашего компьютера с Windows. Это имеет огромное значение для сборок C++ на моем рабочем компьютере. Попробуйте JkDefrag, который кажется намного лучше дефрагментатора, поставляемого с Windows.

EDIT: я предполагаю, что получил отрицательный голос, потому что мой ответ не касается точно заданного вопроса. Однако традиция StackOverflow заключается в том, чтобы помогать людям решать их настоящие проблемы, а не просто лечить симптомы. Я не из тех людей, для которых ответом на любой вопрос будет «использовать линукс». Однако в этом случае у меня есть очень реальный, измеренный прирост производительности именно в той ситуации, о которой спрашивает ОП, поэтому я подумал, что стоит поделиться своим опытом.

person rmeador    schedule 29.01.2009
comment
хотя я не сомневаюсь, что переход на Linux улучшит производительность, вряд ли это ответ на вопрос о профилировании ввода-вывода в Windows. - person sgibbons; 30.01.2009
comment
Спасибо rmador. Многие наши разработчики используют Linux, и это действительно помогает. Кэш файловой системы кажется намного лучше, чем у Windows. Также есть некоторые подозрения, что Microsoft намеренно ограничивает производительность вызовов ядра кодом, отличным от M$. ;) Однако даже сборки Linux слишком медленные. - person erickson; 30.01.2009

Фактически FileMon является более прямым инструментом, чем ProcMon. Как правило, при анализе производительности дискового ввода-вывода учитывайте два следующих фактора:

  • Пропускная способность (скорость чтения/записи байт в секунду)
  • Задержка (сколько стоит в очереди на чтение/запись)

Как только вы оцените производительность вашей системы с точки зрения вышеизложенного, вы легко определите узкое место и предпримете корректирующие действия: приобретите более быстрые диски или измените свой код (в зависимости от того, что окажется дешевле).

person Sesh    schedule 30.01.2009
comment
На самом деле FileMon был устаревшей версией ProcMon к тому времени, когда вы ответили. -1. - person 0xC0000022L; 10.03.2013