Как я могу профилировать файл ввода / вывода?
Наша сборка раздражающе медленная. Это система Java, созданная с помощью Ant, и я работаю на Windows XP. В зависимости от оборудования это может занять от 5 до 15 минут.
Наблюдение за общими показателями производительности на компьютере, а также корреляция различий в оборудовании с временем сборки указывает на то, что процесс связан с вводом / выводом. Это также показывает, что процесс делает намного больше чтения, чем письма.
Однако я не нашел хорошего способа определить, какие файлы читаются или записываются, и сколько раз. Я подозреваю, что с нашими многочисленными подпроектами и последующими вызовами компилятора сборка много раз перечитывает одни и те же часто используемые библиотеки.
Какие инструменты профилирования скажут мне, с какими файлами делает данный процесс? Бесплатно это приятно, но не обязательно.
Используя Process Monitor, как предложил Jon Skeet, я смог подтвердить свое подозрение: почти вся активность на диске заключалась в чтении и повторном чтении библиотек, с копиями JDK "rt.jar" и других библиотек в верхней части список. Я не могу сделать RAM-диск достаточно большим, чтобы вместить все библиотеки, которые я использовал, но монтирование "самых горячих" библиотек на RAM-диске сократило время сборки примерно на 40%; очевидно, что кеширование файловой системы Windows не дает достаточно хороших результатов, хотя я сказал Windows оптимизировать для этого.
Одна интересная вещь, которую я заметил, заключается в том, что типичная операция чтения файла JAR занимает всего несколько десятков байт; обычно их два или три, после чего в файле пропускается еще несколько килобайт. Он оказался неподходящим для массового чтения.
Я собираюсь провести дополнительное тестирование со всеми своими сторонними библиотеками на флэш-накопителе и посмотреть, какой эффект это даст.
5 ответов
Если вам это нужно только для Windows, SysInternals Process Monitor должен показать вам все, что вам нужно знать. Вы можете выбрать процесс, затем просмотреть каждую операцию и получить сводную информацию о файловой операции.
Старый, но хороший: создайте RAM-диск и откомпилируйте ваши файлы оттуда.
В те времена, когда я все еще использовал Windows, я получал хорошие результаты, ускоряя сборку, записывая весь вывод сборки в отдельный раздел, возможно, размером 3 ГБ, и периодически форматируя его ночью один раз в неделю с помощью запланированной задачи. Это просто сборка вывода, поэтому не имеет значения, будет ли он иногда односторонне сглаживаться.
Но, честно говоря, после перехода на Linux фрагментация диска - это то, о чем я больше не беспокоюсь.
Еще одна причина попробовать свою сборку в Linux, по крайней мере, один раз, - чтобы вы могли запустить strace (grep для вызовов open), чтобы увидеть, какие файлы затрагивает ваша сборка.
На самом деле FileMon является более прямым инструментом, чем ProcMon. В общем, при анализе производительности дискового ввода / вывода учитывайте следующие два:
- Пропускная способность (скорость чтения / записи байтов в секунду)
- Задержка (сколько в очереди в очереди на чтение / запись)
После того, как вы оцените производительность вашей системы с точки зрения вышеизложенного, легко определить узкое место и предпринять корректирующие действия: получить более быстрые диски или изменить код (в зависимости от того, что получится дешевле).
Я использовал для создания массивного веб-приложения Java (интерфейс JSP) с использованием Ant в Windows, и это занимало более 3 минут. Я вытер компьютер и установил Linux, и вдруг сборка заняла 18 секунд. Это реальные цифры, хотя и около 3 лет. Я могу только предположить, что Java предпочитает модели управления памятью и потоковой обработки Linux аналогам Windows, поскольку, как мне кажется, все программы Java работают лучше под Linux (особенно Eclipse). Похоже, Linux лучше предотвращает дополнительные операции чтения с диска, когда вы много читаете файлов, которые не изменились (например, исполняемые файлы и библиотеки). Это может быть свойство дискового кэша или файловой системы, я не уверен, какой.
Одна из замечательных особенностей Java заключается в том, что она кроссплатформенная, поэтому настройка сервера сборки на основе Linux на самом деле вам подходит. Будучи чем-то вроде евангелиста Linux, я, конечно, предпочел бы, чтобы вы переключили свою среду разработки на Linux, но я знаю, что многие люди не хотят этого делать (или не могут по практическим причинам).
Если вы даже не хотите настраивать сервер сборки Linux, чтобы увидеть, работает ли он быстрее, вы можете хотя бы попробовать дефрагментировать жесткий диск вашей машины с Windows. Это имеет огромное значение для сборок C++ на моем рабочем компьютере. Попробуйте JkDefrag, который выглядит намного лучше, чем дефрагментатор, который поставляется с Windows.
РЕДАКТИРОВАТЬ: я бы предположил, что я получил отрицательное голосование, потому что мой ответ не отвечает на точный вопрос задан. Однако по традиции Stackru помогает людям решать свои настоящие проблемы, а не просто лечить симптомы. Я не из тех людей, для которых ответ на каждый вопрос "использовать Linux". В этом случае, однако, у меня очень реальный, измеренный прирост производительности именно в той ситуации, о которой спрашивает ОП, поэтому я подумал, что стоит поделиться своим опытом.