ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Отдача больших файло в



Shvayakov Alexander wrote:
MZ wrote:

Отсутствие положительного опыта использования SATA устройств у Вас лично ещё не означает что SATA отстой. На самом деле при одинаковой механике и настройках довольно проблематично добиться условий чтобы скорость различалась хотя бы в два раза (при том что скорость cdrom меньше на порядки чем sata/scsi дисков).
SATA , как интерфейс, не отстой, просто для него свое место. Скорость линейного чтения у SATA может быть заметно выше, но увы... Скорость линейного чтения и способность осблуживать множество интенсивных потоков фрагментированных данных - это разные параметры. И основная разница не в механике диска, а в свойствах контроллеров.

Да, scsi-винт может принять на обслуживаение несколько запросов одновременно, но выполнять их придется поочередно - по другому механика не позволит. sata-винты с ncq делают в точности то же самое, только длина очереди там ограничена 32-мя запросами, а не 32к.

Вы не задумывались почему sata контроллер стоит 3$, а приличный SCSI - 150-2000$ ?

1. маркетинг
2. востребованные рынком и в силу этого популярные решения имеют меньшую себестоимость

Поинтересуйтесь ценами на диски, и спросите в любом сервисе какой у них процент отказов по SATA и SCSI дискам.

Летят диски все, без исключения. И процент надежности у scsi-дисков далеко не на порядок лучше чем у sata (а для некоторых моделей и вовсе хуже). Так что без raid1 не обойтись в любом случае, если нужна отказоустойчивость.

Раз уж мы с Вами не имеем точной информации о конструкции дисков, то предлагаю предположить на основании разницы в цене и надежности, что разница в механике и прочих технических мелочах все же есть. Объяснить все это только понятиями желтая-белая-черная сборка не получится. Все это железо делают одни и те же японские роботы что в китае, что в мексике или венгрии.

Раз уж не имеем, то давайте не фантазировать а опираться на проверенные данные. Заявление "scsi - рулез, а sata - отстой" я считаю голословным и не опирающимся на реальные факты. Разница между scsi и sata, безусловно, присутствует, но не позволяет выкинуть на помойку или клеймить "отстоем" одну из этих технологий.

Больше еффекта от аппаратного кеша контроллера ? Каким, позвольте поинтересоваться, образом ?
Существенная разница в том, что аппаратный кэш работает на уровне объектов головка-дорожка-сектор, а кэш операционной системы на уровне файлов.

Верно, как и то, что оба кеша работают на уровне блоков данных. Только аппаратные кеш дороже, а софтовым ОС может гибко управлять - кешировать в зависимости от статистики использования, освобождать области с уже ненужными или неизмененными данными..

 >> Сколько мегабайт кеша контроллера еквивалентно одному гигабайту RAM ?
Размер объектов подлежащих кэшированию и алгоритмы работы с ними очень разные. Сопоставьте размер сектора диска и размер кина на вашем диске, которое вы хотите кэшировать.
вычислите эквивалент.

Размер сектора - 512байт, размер кина - 1400М - какой отсюда вычисляется еквивалент ?

Однако все сложнее гораздо. Важен процент попадания в кэш, а он будет низким и почти всегда. Какова вероятность того, что в один момент несколько клиентов тянут один и тот же файл?

Какое это имеет отношение к вопросу SCSI vs SATA и аппаратный vs RAM кеш?

Даже в домашних сетях dvd не раздают на 100м интерфейсах, а уж для коммерческого проекта думаю предусмотрено минимум одна 1Г сетевуха.
Если это сетвуха за 4$, то не ожидайте от нее чудес. Серверные сетевые карты предназначенные для обслуживания интесивных потоков имеют ряд особых свойств и стоят заметных денюжков. Не забудьте посмеятся над людьми которые их покупают, они же глупые... :)

По умолчанию, без средств управления трафиком, при раздаче трафика используются очереди пакетов типа fifo. Это работает по принципу "первым пришел, первым ушел" (First In, First Out). Потому один клиент может захватить канал и пока он не закончит тянуть свой файл, все остальные ждут. Есть множество оговорок благодаря которым канал все же немного распределяется - учитывается значение поля пакета TOS (Type of Service), в канале есть приоритеные полосы и т.д. Однако общий эффект грустный. Эти заморочки особенно заметны при работе с интернет. При работе с относительно мелкими файлами кажется все нормально распределяется, а в случае если кто зацепил тянуть видео с рапиды, все нервно курят и ждут пока он докачает свою порнуху.

Не путайте перегруз офисного интернет линка пакетами от рапиды, которые не имеют выбора кроме как быть пущеными в канал или дропнутыми, с отдачей контента на сервере - ОС дает всем соединениям одинаковый приоритет (я рассматриваю соединения к веб-серверу) и по мере увеличения уровня потерь пакетов и задержек поддверждений уменьшает sending rate, поддерживая загрузку канала на высоком уровне и уменьшая необходимость перепосылать пакеты в случае их потери.



 




Copyright © Lexa Software, 1996-2009.