Вход:  Пароль:  
FreeSource: ЗачемНамSCSI ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |

Зачем нам 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, или на реальных задачах.


Страницы, ссылающиеся на данную: HCL/ХранениеДанных
Статьи


 
Файлов нет. [Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]