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

Question

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

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

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

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

---

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

Answer 4

На самом деле FileMon является более прямым инструментом, чем ProcMon. В общем, при анализе производительности дискового ввода / вывода учитывайте следующие два:

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

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

Answer 5

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

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

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

РЕДАКТИРОВАТЬ : Я полагаю, что получил отрицательное голосование, потому что мой ответ не соответствует точному заданному вопросу. Однако по традиции StackOverflow помогает людям решать свои настоящие проблемы, а не просто устранять симптомы. Я не из тех людей, для которых ответ на каждый вопрос "использовать Linux". В этом случае, однако, у меня очень реальный, измеренный прирост производительности именно в той ситуации, о которой спрашивает ОП, поэтому я подумал, что стоит поделиться своим опытом.