Как добиться максимальной скорости работы с HDD?

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

Здесь не будут рассматриваться особенности SCSI-винчестеров или RAID. Либо пойдет речь о повышении быстродействия вообще, либо о повышении скорости работы с IDE-дисками. Разгон компьютера тоже не будет рассматриваться, т. к. это скорее способ повышения нестабильности системы, и годится разве что для игроманов.

Отступление по SCSI: проблемой для SCSI винчестеров и IB является неверное поведение SCSI-драйвера в Windows NT. Заключается оно в том, что когда NT производит операцию FLUSH (выгрузка кэша на диск), к SCSI-винчестеру не может производиться других обращений. Выглядит это так – при работе с IB компьютер периодически "замирает" – индикатор обращений к HDD мигает, хотя загрузка процессора практически на нуле. Продолжаться это может от от 1 до 20 минут (максимально зарегистрированное время). Исправить проблему можно только уменьшением размера кэша IB – параметр DATABASE_CACHE_PAGES в файле IBCONFIG. На других операционных системах подобная проблема, похоже, не возникает.

Второе отступление по SCSI: при наличии на одной шине SCSI быстрых и медленных устройств, совокупная производительность будет равна производительности самого медленного устройства. Поэтому следует избегать подключения к шине, на которой находится RAID, CD-ROM-ов и ленточных устройств. Для этих целей вам лучше приобрести отдельный SCSI-контроллер.

Отступление на тему разгона: действительно, разгон процессора может привести к периодическому появлению "синего экрана" под Windows NT, или к падению 95/98, что еще хуже. Даже если разогнать процессор на 20%, то для РСУБД это вряд ли будет иметь смысл – большинство операций РСУБД производит с диском. А дисковая подсистема работает намного медленнее, чем процессор и память. В итоге разгон компьютера даст общее повышение производительности системы на 1-2%. В то же время, любой из приведенных далее пунктов может дать как минимум 1.5-2 кратное повышение скорости работы системы в целом.

Начнем с операционной системы. Windows95/98 – наихудший выбор в качестве сервера для IB, поскольку эти операционные системы очень плохо работают с виртуальной памятью и многозадачными приложениями. Для IB нет разницы между Windows NT Server и Workstation, поэтому если компьютер не слишком мощный, лучше поставить Windows NT Workstation. Unix – тоже неплохой выбор.

Скорость работы IDE винчестеров можно существенно повысить (в 1.5-3 раза) путем установки драйвера BusMaster. Однако делать это рекомендуется только в случае, когда материнская плата содержит чипсет, поддерживающий работу в режиме BusMaster. Без драйвера же увеличения скорости работы с винчестером не будет, даже если купить винчестер споддержкой UltraATA/66. Для Windows98 устанавливать драйвер не нужно, т. к. он уже встроен в систему – достаточно выставить в свойствах контроллера HDD чекбокс "use DMA".

Подробнее по BusMaster см. http://www.ixbt.ru, FAQ по BusMaster.

По субъективным ощущениям, размещение файла виртуальной памяти на отдельном HDD существенно повышает скорость работы компьютера. Можно взять любой (даже старый) IDE винчестер размером 500-1000 мегабайт (если найдете такой), который работает минимум в PIO MODE 3, создать на нем файловую систему, и разместить на нем виртуальную память.

Замечу также, что для Windows NT наилучшие результаты дает размер виртуальной памяти в 2.5-3 раза больше, чем размер физической памяти. Например, на вашем компьютере – 512Мб RAM. Следовательно имеет смысл создать файл виртуальной памяти размером 1.5 гигабайта. В этом случае сообщение "out of virual memory" вряд ли возникнет.

• При создании (или активации) индексов по заполненным значениями столбцам.

• При выполнении запросов с ORDER BY, когда невозможно использовать индекс.

По умолчанию IB создает временные файлы там, куда указывает системная переменная TEMP. Как правило, под Windows NT эта переменная указывает на каталог на диске, где расположена операционная система. Обычно на этом диске немного свободного места (особенно, если по умолчанию на этом же диске расположен файл виртуальной памяти), и часто возникает ошибка "error writing to file xxxxx".

Поменять TEMP на другой диск можно через MyComputer/Properties/Environment, но лучше этого не делать. Здесь же можно объявить переменную INTERBASE_TMP, которая имеет более высокий приоритет по отношению к переменной TMP.

Лучше всего явно указать расположение временных файлов в файле конфигурации IBCONFIG. Это возможно сделать только для IB 5.x, причем можно указать несколько каталогов или дисков для расположения временных файлов. Например,

Для любой файловой системы лучше выбирать размер страницы базы данных 4К или 8К. По умолчанию InterBase создает БД с размером страницы 1К, что весьма мало, и при больших объемах данных будут проблемы не только со скоростью считывания и обновления, но и с глубиной индексов.

На NTFS лучше всего выбрать размер страницы 4К, предварительно отформатировав логический диск с размером блока также 4К. Не рекомендуется хранить на этом же логическом диске другие файлы, кроме базы данных.

Для FAT имеет смысл сделать размер страницы сразу 8К.

Тут, наверное, комментарии не требуются. Backup также рекомендуется выполнять на отдельный HDD, тем более если Backup выполняется во время работы пользователей с базой данных. По размеру диск должен быть достаточно большим, чтобы поместился backup. К сожалению, IB под Windows NT до сих пор не поддерживает создание многофайлового backup. Поэтому создайте один раздел NTFS, и выполняйте backup на него.

Разумеется, если вы хотите выполнить backup максимально быстро даже в обычной конфигурации, то не забывайте указать gbak.exe опцию -g, которая отключит сборку мусора при backup. Это существенно ускорит процесс backup.

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

• Автоматическая сборка мусора. Так называемый sweep. Происходит тогда, когда разница между текущей транзакцией и oldest transaction (см. gstat -h) достигнет значения sweep interval (по умолчанию 20000). Старт sweep может проявляться как внезапное замедление работы в течение дня или через несколько дней после restore. Когда подобные "замедления" неприемлемы, имеет смысл отключить автоматическую сборку мусора утилитой gfix (-housekeeping 0), и делать sweep вручную (тем же gfix) или при backup (без ключа -g).
• Кооперативная сборка мусора. Она происходит в том случае, если транзакция, читающая данные, обнаруживает никому не нужные версии записей. Обнаружить сборку ненужных версий можно только в динамической статистике (page writes, isc_database_info) при выполнении запросов SELECT. Тем не менее, эту сборку мусора можно тоже полностью отключить, если работать с компонентами прямого доступа, и для компонента Database указать параметр no_garbage_collect (см. документацию на IB API). При этом сборка мусора будет запрещена, но база данных будет "расти" из-за накопления мусора.

Надеюсь вы посчитали, сколько винчестеров вам понадобится? TEMP и виртуальную память можно разместить и на одном, значит минимум – 2. Т. е. на одном – база данных, а на другом – виртуальная память и TEMP. Файл базы данных можно разместить на HDD, где расположена система, но обязательно на отдельном логическом диске. И желательно на этом диске никаких других файлов, кроме базы данных, не размещать.

Ну, а начать "ускорение" желательно не с добавления новых HDD, а с установки драйвера BusMaster.