Зачем нам SCSI?

Предисловие

Эта статья описывает какую пользу может принести пользователю использование
SCSI-дисков, в том числе на рабочей станции.

Чем SCSI отличается от IDE

Во-первых SCSI-диски дороже. В несколько раз.

Во-вторых максимальными размерами — SATA и IDE диски размером в 250Gb
встречаются весьма часто, и стоят вполне разумных денег. Стоимость SCSI-дисков
размером в 140G превышает тысячу долларов (1k$)!

Уже пугает? Зря.

SCSI-диски продаются со скоростью вращения шпинделя в 10'000 и 15'000 оборотов
в минуту. Против 7'200 максимальной скорости у IDE/SATA дисков (за исключением
одного единственного HDD от Western Digital, который и стоит как SCSI, и объём
имеет небольшой). Это первое преимущество. Собственно высокая цена и маленькие
объёмы диктуются, видимо, в первую очередь этим.

У SCSI есть ещё одно преимущество, выглядещее очень скромно, но делающее SCSI
дисков единственным выбором в большинстве многопользовательских решений и
серверов с большой нагрузкой — очередь запросов.

SCSI-диск может получить несколько запросов, после чего выполнить их и передать
результат хост-контроллеру в произвольном порядке. Что это означает на практике?

100 пользователей работают с базой данных. Каждый пользователь пытается считать
свои данные. Данные пользователей, разумеется, разбросаны по поверхности дисков.
Для современных дисков самое большое время — это время позиционирования головки,
и для считывания 100 блоков данных в разных местах диска головка 100 раз будет
перемещена в произвольное место диска. Именно когда несколько процессов одновременно
работают с диском пользователь и слышит характерное «шуршание» диска, обычно
сопровождающее ощутимые замедления работы компьютера при перегрузке диска
операциями.

SCSI-диск поступит умнее — он отсортирует эти 100 запросов в том порядке,
в котором _ему_ их удобнее обрабатывать (с учётом того, какие данные или часть
их уже есть в кэше и где в настоящий момент находится головка диска) и сделает
один проход по поверхности диска, вместо псевдослучайных «дёрганий»
считывающей головкой у IDE-диска. Результат — при параллельном доступе к
диску множеством процессов увеличение проихводительности в разы, а иногда на
порядки.

Применение на серверах

В low-end серверах (к коим и относится подавляющее большинство серверов в
xUSSR) на SCSI-дисках часто пытаются сэкономить. А зря. В большинстве задач,
выполняемых этими самыми low-end серверами, ключевыми для производительности
являются оперативная память (её количество) и дисковая подсистема, а процессор
является предпоследним (перед видеокартой, разумеется).

Например для корпоративного почтового сервера и intranet/internet сайта
(а это одни из самых частых задач для low-end UNIX-серверов) обычно достаточно
процессора Pentium III, но 512Mb-1Gb памяти и маленький (9–18Gb) «старенький»
SCSI HDD может дать заметный прирост в производительности (на почтовом сервере
провайдера или крупной компании это будет видно лучше всего).

Применение на рабочих станциях

В многопользовательских системах, я надеюсь, преимущества SCSI уже очевидны.
Теперь о персональных рабочих станциях.

Писать буду о том, что знаю я — о деятельности разработчика.

Факт 1: параллельная сборка (make -j<n>) даже на однопроцессорных машинах даёт
преимущество перед последовательной (это связано с тем, что пока один процесс
читает данные с диска, другой может выполнять собственно обработку, то есть
идёт равномерная загрузка и процессора и дисковой подсистемы). Оптимальное
значение n, подобраное эмпирически, является <количество процессорв> * 4.

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

Факт 2: cvs update на большом дереве исходников процесс весьма долгий.
На девелоперском сервере, которым я пользуюсь для разработки, установлен
LSI-контроллер с 64Mb кэша (с батарейкой) и RAID5 массив из 15krpm 36Gb SCSI
дисков. По сравнению с моей рабочей машиной cvs работает более чем на порядок
быстрее. При том что линейная скорость чтения с дисков у моей рабочей машины
выше (!).

Факт 3: у меня есть текущие данные, которые не удобно класть в cvs (постоянно
перемещаются между каталогами, часто создаются новые и удаляются, и т.д).
Например такими данными является почта.

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

Ежеминутный поиск всех изменившихся файлов в / ощутимо тормозит систему,
если домашний каталог находится на IDE-диске. На SCSI-дисках это абсолютно
незаметно. Копирование выполняется на SATA-диск размером 250G (он большой
и относильно SCSI-дисков недорогой), а сам домашний каталог размещается,
естественно, на SCSI-дисках.

Оптимальная конфигурация для рабочей станции на сегодняшний день — маленький
SCSI-диск (или RAID-массив, смотря по финансовым способностям) для основных
рабочих документов и данных и один SATA-диск для мультимедиа-данных и прочих
данных большого размера с преимущественно последовательным доступом.

Мечты

Я долго мечтал о низкооборотных HDD со SCSI-интерфейсом, и моя мечта почти
сбылась. TCQ (Tagged Command Queue) является одной из возможностей протокола
Serial-ATA, которую на текующий момент поддерживают только SATA-диски от
Hitachi, и которая не поддерживается Linux в настоящий момент. Будем ждать.

Выводы

Вывод 1: SCSI полезно и на серверах, и на рабочих станциях.

Вывод 2: линейная скорость чтения далеко не самое важное, производительность
дисковой подсистемы надо мерять специализироваными синтетическими тестами,
такими как bonnie, или на реальных задачах.