У меня есть сторонний объектно-ориентированный сервер базы данных, работающий на машине Windows Server 2003 x64 с 24 ГБ ОЗУ. За исключением некоторых системных процессов и инструментов мониторинга, сервер базы данных - единственное, что работает на этом компьютере. У меня открыто десять файлов базы данных размером ~ 130 ГБ и один файл базы данных размером ~ 5 ГБ, последний из которых используется чаще всего и вызывает у меня проблемы.
Всякий раз, когда сервер базы данных сбрасывает этот файл базы данных, кажется, что это занимает целую вечность. Поскольку СУБД сбросит свой журнал транзакций после записи данных на диск, она должна дождаться завершения сброса.
Я просмотрел файл IO в Монитор процесса и увидел, что во время нормальной работы перед сбросом происходит много буферизованных записей (обычно 128 байт, иногда немного больше) с произвольными смещениями в файле. Этого и следовало ожидать, поскольку небольшие фрагменты данных добавляются и обновляются в базе данных непредсказуемым образом.
Когда журнал транзакций заполнен и происходит сброс, было произведено около 8000 записей, кратных 4 КБ (размер страницы на рассматриваемой машине), всего около 35 МБ в одном проанализированном мной экземпляре. Для завершения очистки потребовалось около 12 секунд, в течение которых сервер базы данных зависает. Наши специалисты по хранению данных говорят мне, что 1,5 мс на запись (12 секунд, разделенные на 8000 операций записи) повторяют нормальную производительность SAN, и они ничего не могут сделать, чтобы это ускорить.
Я прочитал, как работает кеширование файлов в Внутреннее устройство Windows 4, и в нем упоминается, что диспетчер кеша будет пытаться записывать грязные страницы на диск через равные промежутки времени в фоновом потоке, даже если приложение не запрашивает сброс (ленивая запись). Есть ли способ заставить его быстрее записывать страницы на диск, чтобы при вызове приложения FlushFileBuffers, осталось всего несколько грязных страниц, которые приложению придется ждать записи на диск?
В книге также упоминается, что в диспетчере кеша есть только одна копия любого файла. Означает ли это, что я могу запустить сброс, открыв тот же файл в отдельном процессе и регулярно вызывая FlushFileBuffers на нем, чтобы снова было меньше сбрасывать, когда сервер базы данных запрашивает очистку?
Есть ли другие параметры операционной или файловой системы, на которые мне следует обратить внимание?
Одна из рекомендаций, которую я услышал, заключалась в том, чтобы увеличить размер страницы в файловой системе, так как это повысит пропускную способность за счет увеличения количества байтов, записываемых в SAN за один ввод-вывод. Поскольку страницы, сохраненные во время сброса, не являются последовательными и находятся далеко друг от друга, я сомневаюсь, что это что-то сделает, верно?