Профилирование доступа к диску

Question

В настоящее время я работаю над приложением MFC, которое читает и записывает на диск. Иногда это приложение работает удивительно быстро, а иногда оно чертовски медленно. Я предполагаю, что это из-за доступа к диску, поэтому я хочу профилировать его. Вот некоторые вопросы на этот счет:

(1). В настоящее время я использую профилировщик AQTime для профилирования приложения. Кто-нибудь пробовал профилировать доступ к диску с помощью этого? или есть другой инструмент, который я могу использовать?

(2). Каковы наиболее важные параметры диска, на которые я должен обратить внимание?

(3). Если у меня несколько потоков, пытающихся читать и записывать данные с диска, это влияет на производительность? то есть мне лучше иметь однопоточный доступ к диску?

Answer 1

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

Наиболее важными параметрами являются время обслуживания диска и длина очереди. Время обслуживания диска - это сколько времени фактически потребовалось диску для обслуживания запроса. Длина очереди указывает, резервируется ли ваш дисковый запрос за другими запросами.

Для многих потоков с чтением и записью - многие диски имеют низкую производительность при чтении с фоновой записью. Если у вас есть разные потоки, которые выполняют много операций ввода-вывода с диска в случайных местах на диске, вы можете потерять некоторые запросы.

Answer 2

Чтобы помочь вам с (2):

1. Попытайтесь объединить ваши записи на диск, чтобы избежать множества небольших вызовов для записи. Когда вы закончите очищать свой буфер, вызовите commit. commit (он же fsync) - дорогостоящая операция, поэтому она становится еще более важной, когда много мелких записей.
2. На дескрипторах файлов Windows вы можете поэкспериментировать с FILE FLAG WRITE THROUGH для увеличения скорости записи. Предположительно, не нужно вызывать commit с дескрипторами, использующими этот флаг.
3. Если данные, которые вы записываете на диск, также будут доступны при чтении, сначала рассмотрите возможность записи в структуру памяти, чтобы другой поток считал из структуры для записи на диск. Это поможет избежать вызовов для чтения данных с диска, который вы только что написали.

Надеюсь, это поможет ....

Answer 3

Что бы я сделал, если вы не можете приостановить все потоки одновременно и проверить их состояние, сфокусируйтесь на одном из них и сделайте паузу, пока он «чертовски медленный». Это малоизвестная, но эффективная техника.

Поскольку он очень медленный по сравнению с тем, что может быть, то, что он ждет, он ждет, вероятно, 99% времени, поэтому, когда вы остановите его, вы увидите это. Это правда, будь то одно большое ожидание или миллион маленьких. Посмотрите на весь стек вызовов. Виновник может быть где-то посередине стека.

Если вы не уверены, сделайте паузу два или три раза. Преступник будет на всех выборках стека.