Мы написали приложение, которое выполняет небольшие (22 КБ) записи в несколько файлов одновременно (один поток выполняет асинхронные очереди записей в несколько мест от имени других потоков) на одном локальном томе (RAID1).
99,9% записей происходят с низкой задержкой, но иногда (возможно, каждую минуту или две) мы получаем одну или две записи с большой задержкой (я видел 10 секунд и больше) без какого-либо реального объяснения.
Платформа: Win2003 Server с NTFS.
Мониторинг: Sysinternals Process Monitor (см. ссылку ниже) и наше собственное ведение журнала приложений.
Мы испробовали множество вариантов решения этой проблемы, информация о которых была почерпнута с нескольких веб-сайтов, например:
Создание уникальной первой части имени файла для облегчения генерации имени 8.3
Запись файлов в несколько каталогов
Изменение кэширования записи на диск Intel
Общий доступ к файлам и принтерам Windows
Минимизировать использование памяти
Баланс
Увеличьте пропускную способность данных для обмена файлами
Увеличьте пропускную способность данных для сетевых приложений
Система->Дополнительно->Производительность->Дополнительно
NtfsDisableLastAccessUpdate — использование fsutil behavior set disablelastaccess 1
отключить генерацию имени 8.3 - используйте "fsutil behavior set disable8dot3 1" + перезапуск
Включить кэш файловой системы большого размера
Отключить подкачку кода ядра
Предел блокировки страницы ввода-вывода
Отключить (или включить) службу индексирования
Но, похоже, ничего не имеет особого значения. Есть целый ряд вещей, которые мы еще не пробовали, но нам интересно, сталкивался ли кто-нибудь с такой же проблемой, с причиной и решением (программным или нет)?
Мы можем воспроизвести проблему с помощью IOMeter и простой настройки:
Запустите IOMeter и удалите все рабочие потоки, кроме первого, в «Топологии» с помощью кнопки отключения.
Выберите рабочий поток и поставьте крестик в поле рядом с диском, который вы хотите использовать на вкладке «Целевые диски», а также введите «2000000» в поле «Максимальный размер диска» (ПРИМЕЧАНИЕ: должно быть не менее 1 ГБ свободного места; размер сектора составляет 512 байт).
Затем создайте новую спецификацию доступа и добавьте ее в рабочий поток:
Размер запроса на передачу = 22 КБ
100% Последовательный
Процент спецификации доступа = 100%
Процент чтения/записи = 100% записи
Измените частоту обновления отображения результатов на 5 секунд, время выполнения настройки теста на 20 секунд и оба параметра «Количество рабочих процессов для автоматического создания» на ноль.
Выберите рабочий поток на панели «Топология» и нажмите кнопку «Дублировать рабочий поток» 59 раз, чтобы создать 60 потоков с идентичными настройками.
Нажмите кнопку «Go» (зеленый флажок) и следите за вкладкой Results. «Maximum I/O Response Time (ms)» всегда достигает не менее 3500 на нашей машине. Наша машина не совсем медленная (сервер Xeon 8 core rack с 4 ГБ и встроенным RAID).
Мне было бы интересно посмотреть, что получат другие. У нас есть ощущение, что это может быть связано с файловой системой NTFS (наша сейчас на 75% заполнена фрагментированными файлами), и мы собираемся попробовать несколько вещей вокруг этого принципа. Но это также связано с производительностью диска, поскольку мы не видим этого на RAMDisk, и это не так серьезно на массиве RAID10.
Любая помощь будет высоко оценена.
Ричард
Щелкните правой кнопкой мыши и выберите «Открыть ссылку в новой вкладке»:
Результат ProcMon
решение1
Теперь у меня есть больше информации по этому вопросу.
Протестировав описанный тест IOMeter на 12 различных машинах с различным оборудованием, я сузил его до определенного набора микросхем RAID (3 разные машины с одним и тем же набором микросхем демонстрируют такое поведение при использовании RAID1 и RAID10). Все остальные машины показывают результат как минимум на порядок лучше.
Чипсет: Intel 631xESB/632xESB SATA RAID (он же ESB2)
Дополнительную информацию и, с большой долей вероятности, ответ от Intel см. в этой публикации на сайте Intel:
Intel 631xESB/632xESB SATA RAID (он же ESB2) пишет медленно
Ричард