j

[Andrey]

В Сбт, 07/10/2006 в 13:41 +0400, Anton Yuzhaninov пишет:

> Hello Andrey,
> 
> You wrote on Saturday, October 7, 2006, 1:26:33 PM:
> 
> A>  Хорошо бы иметь возможность кешировать статику не только в
> A> мемкеше, но и на диске. У меня проблема с дисками. 
> A>  Есть решение(встретил такую схему в статье расказывающей об одной
> A> из известных хостинговых компаний, к сожалению не помню ссылку..).:
> A>  1) подключить SCSI raid(0|1) гигов на 15-30.
> A>  
> A>  2) поставить апач2 и использовать mod_cache указав ему сохранять
> A> кеш на быстрых дисках. Таким образом, при отдаче видео файлов можно
> A> было бы существенно сократить количество обращений к основному
> A> дисковому массиву, тем самым разгрузив его. 
> A>
> 
> Большого выигрыша от такой схемы не будет. Скорость раздачи больших
> файлов со SCSI нисколько не выше, чем с SATA, а стоимость выше на
> порядок.
> 
> Лучше просто иметь один большой массив с RAID1 из SATA дисков.
> 
> Преимущества SCSI проявляются когда идет очень много мелких (по
> объему) запросов к разным областям диска - нагрузка характерная
> для СУБД.
> 


Раид 1 вряд ли возможен, так как теряется половина места. Т.е. если у
меня сейчас 1.4 ТВ(raid50), то при использовании raid1 это будет только
0.8 TB. Не думаю, что такая схема приемлема.

Нашёл статью. http://apachedev.ru/2006/05/15/nastroyka-apache-ot-heanet/
Там говорится о 36Гб (два диска по 18) скази. 36 Гб не сильно дорго.
Авторы утверждают, что им удалось значительно ускорить хранилище с
помощью этой схемы. 
Нужно так же учесть, что, напрмер в моём случае, присутствует постоянное
обращение к дискам с запросоми на запись новых файлов. Перенося
многократные запросы на чтение с основного дискового массива на
дополнительный, данная схема позволит заметно разгрузить основное
хранилище, что будет несомненно более дешёвым решением, чем покупка
нового сервера или raid1 (причём я  сомневаюсь, что raid1 будет работать
так же хорошо как raid50 + SCSI cache, зато выйдет дороже).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20061007/8e4a3d79/attachment.html>