ПРОЕКТЫ 


  АРХИВ 


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: Еще раз о дисковой подси стеме



On Thu, Aug 18, 2011 at 05:48:38PM +0400, Илья Винокуров wrote:
> 18 августа 2011, 13:00 от Igor Sysoev <igor@xxxxxxxxx>:
> > On Thu, Aug 18, 2011 at 12:49:23PM +0400, Илья Винокуров wrote:
> > > А у меня другое мнение.
> > > Для раздачи long статики (фильмы длинные) RAID 10 будет эффективнее, чем 
> > > независимые винты:
> > >
> > > 1) При раздаче одного файла участвуют все диски (у независимых винтов 
> > > только один)
> > 
> > Именно. То есть, весь рэйд при этом работает со скоростью одного диска.
> 
> Для одного потока да - RAID10 может работать со скоростью одного винта, но Вы 
> рекомендуете запускать
> столько процессов nginx, сколько ядер в системе... А в системе сейчас от 2-х 
> ядер.
> Так вот, при параллельной работе нескольких потоков запросы к массиву будут 
> параллелиться между дисками.

Для одного потока RAID10 будет работать со скоростью всех дисков:
1) процесс читает 1М,
2) с каждого диска ядро читает по 128К,
3) диски подвели головки к нужному трэку,
4) и прочитали в свой кэш целый трэк - 1-2М,
5) в ядро уходит блоки по 128К,
6) ядро читает следующие 128К,
7) они уже не читаются с диска, а берутся из кэша диска,
8) goto 4, до тех пор пока кэш не будет исчерпан.

В случае нескольких потоков пункты 1-5 те же самые, а на пункте 6 данные,
как правило, вытеснены другими потоками. То есть, мы заставляем диски
двигать головы на каждое чтение, что практически аналогично времени
случайного доступа к одному диску.

Что касается числа процессов nginx, то данная рекомендация относится
только, если nginx упирается в процессор. Если же узкое место диски,
то процессов нужно много - 10-30 и их число никак не связано с числов
процессоров.

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

С RAID10 ничего не измениться. Только задыхаться будет весь RAID.

> > Для современного диска нет ощутимой разницы в чтении 1К или 1М. Поэтому
> > читать с нескольких дисков блоки по 128К, чтобы набрать 1М - бессмысленно.
> 
> Поэтому я и предложил увеличить размер блока данных.
> 
> > > PS: При монтировании RAID10 для длинных файлов следует увеличить величину 
> > > блока
> > > до 1..2 мегабайт. 
> 
> > И многие рэйд позволяют подобное увеличение ?
> 
> Конечно же, речь идет о софтовом решении. По моему мнению будущее за 
> софтовыми RAID массивами,
> а точнее за RAIDовыми FS.

Замечательно, какие софтовые рэйды позволяют увеличить страйп до 1М ?

> > И всё равно он не полностью решает проблему - при попадании на границу
> > будут задействованы два диска вместо одного ?
> 
> Если рассматривать работу в системе кучки процессов, насилующих RAID массив, 
> то факт попадания одного
> файла на границу не играет никакой роли. Главное, чтобы план чтения блоков с 
> конкретного диска был
> оптимальным. Посему рекомендации сводятся к использованию SAS дисков.

См. выше.


-- 
Игорь Сысоев
http://sysoev.ru

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.