ПРОЕКТЫ 


  АРХИВ 


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: РИТ: Высокие нагру зки vs Highload++



On Wed, Sep 17, 2008 at 11:45:58AM +0400, Dmitry Morozovsky wrote:

> On Wed, 17 Sep 2008, Igor Sysoev wrote:
> 
> IS> > IS> > а что за фс, опции newfs (прошу прощения что так все выпрашиваю до
> IS> > IS> > собственно конференции :) 
> IS> > IS> 
> IS> > IS> Ничего необычного: ufs2, bs=64k (больше, увы, нельзя).
> IS> > 
> IS> > Это нормально работает только в том случае если на эту файловую систему 
> почти 
> IS> > ничего не пишется - иначе зависания и паники по фрагментации buffer 
> cache :(
> IS> > 
> IS> > Проблема известная, но что с ней делать пока никому вроде как особенно 
> IS> > непонятно. Подробности у kib@ и pjd@
> IS> 
> IS> Там ничего не пишется. А из-за чего там фрагментация ? По идее, buffer
> IS> cache - это просто временный mapping.
> 
> Я сейчас уже точно не вспомню, но, кажется, это связано с тем, что размер 
> файлового фрагмента больше страницы памяти.  Поэтому 4k/32k еще приемлемо, а 
> 8k/64k - уже грабли.

Я нашёл вот это с объяснением:
http://freebsd.rambler.ru/bsdmail/freebsd-stable_2007/msg04741.html

Дело не во фрагментах, а именно в блоке файловой системы - в описаном
случае есть свободные блоки буферов размером 32К и 48К, а нужны именно 64К.
При том, что одиночные буфера всегда 16К, непонятно, как файловые системы
с блоком 32K ещё работают. Скорее всего, же проблема в смешении файловых
систем с разными размерами блоком - 16K, 32K и 64K. 16K - будет работать
всегда, а вот для 32K/64K уже может не хватить.


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



 




Copyright © Lexa Software, 1996-2009.