ПРОЕКТЫ 


  АРХИВ 


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: Тюнинг отдачи мелких картинок



Здравствуйте, Игорь.

>> FreeBSD 7.0-PRERELEASE
>>  
>> имеется следующая картина:
>> 
>> last pid: 20046;  load averages:  0.19,  0.20,  0.09 up 4+14:11:50  16:04:21
>> 32 processes:  1 running, 31 sleeping
>> CPU states:  0.5% user,  0.0% nice,  1.0% system,  2.3% interrupt, 96.2% idle
>> Mem: 135M Active, 2936M Inact, 652M Wired, 184M Cache, 214M Buf, 9980K Free
>> Swap: 4096M Total, 3764K Used, 4092M Free
>> 
>>   PID   THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
>> 15901     1  -8    0 45312K 38912K biord  0   2:44  0.00% nginx
>> 15900     1  -8    0 45312K 39024K biord  0   2:43  0.00% nginx
>> 15903     1  -8    0 45312K 38956K biord  1   2:43  0.00% nginx
>> 15898     1  -8    0 45312K 38864K biord  0   2:41  0.00% nginx
>> 15902     1  -8    0 45312K 38736K biord  0   2:41  0.00% nginx
>> 15899     1  -8    0 45312K 38860K biord  1   2:40  0.00% nginx
>> 
>> gstat показывает:
>> 
>>  L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
>>     0      8      7    116   21.1      0     26    0.6   10.1| ad4
>>     2     42     41    799   19.1      0      0   10.5   48.6| ad6
>>     3     33     33    504   18.4      0      0    0.1   35.2| ad8
>>     0     33     33    514   21.9      0      0    9.8   35.3| ad10
>>     1     38     38    560   18.9      0      0    0.1   41.3| ad12
>>     0     27     26    450   27.5      0      0    0.1   33.3| ad14
>> 
>> Раздаётся очень много мелких картинок.
>> 
>> Диски хоть и недогружены, но nginx-ы все в ожидании ввода-вывода.

> А если увеличить число воркеров ?

Стало вот так:

last pid: 20316;  load averages:  0.13,  0.08,  0.08 up 4+14:54:42  16:47:13
58 processes:  1 running, 57 sleeping
CPU states:  0.0% user,  0.0% nice,  0.4% system,  3.2% interrupt, 96.4% idle
Mem: 251M Active, 2814M Inact, 661M Wired, 178M Cache, 214M Buf, 9864K Free
Swap: 4096M Total, 68K Used, 4096M Free

  PID   THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
20262     1   4    0 32000K 25308K kqread 0   0:00  0.00% nginx
20269     1   4    0 32000K 25264K kqread 0   0:00  0.00% nginx
20275     1   4    0 32000K 25256K kqread 0   0:00  0.00% nginx
20264     1  -8    0 32000K 25316K biord  1   0:00  0.00% nginx
20265     1   4    0 32000K 25276K kqread 1   0:00  0.00% nginx
20267     1  -8    0 32000K 25268K biord  1   0:00  0.00% nginx
20261     1   4    0 32000K 25264K kqread 0   0:00  0.00% nginx
20263     1   4    0 32000K 25244K kqread 1   0:00  0.00% nginx
20268     1   4    0 32000K 25288K kqread 1   0:00  0.00% nginx
20271     1  -8    0 32000K 25248K biord  0   0:00  0.00% nginx
20274     1  -8    0 32000K 25260K biord  0   0:00  0.00% nginx
20270     1  -8    0 32000K 25236K biord  1   0:00  0.00% nginx
20272     1  -8    0 32000K 25256K biord  0   0:00  0.00% nginx
20266     1  -8    0 32000K 25232K biord  0   0:00  0.00% nginx
20283     1   4    0 32000K 25260K kqread 1   0:00  0.00% nginx
20273     1  -8    0 32000K 25240K biord  0   0:00  0.00% nginx
20281     1   4    0 32000K 25172K kqread 1   0:00  0.00% nginx
20277     1  -8    0 32000K 25228K biord  0   0:00  0.00% nginx
20284     1   4    0 32000K 25264K kqread 0   0:00  0.00% nginx
20276     1   4    0 32000K 25244K kqread 0   0:00  0.00% nginx
20286     1  -8    0 32000K 25248K biord  0   0:00  0.00% nginx
20280     1   4    0 32000K 25180K kqread 1   0:00  0.00% nginx
20285     1   4    0 32000K 25200K kqread 1   0:00  0.00% nginx
20279     1   4    0 32000K 25184K kqread 0   0:00  0.00% nginx
20289     1   4    0 32000K 25180K kqread 0   0:00  0.00% nginx
20287     1   4    0 32000K 25184K kqread 0   0:00  0.00% nginx
20278     1   4    0 32000K 25148K kqread 0   0:00  0.00% nginx
20288     1   4    0 32000K 25136K kqread 0   0:00  0.00% nginx
20290     1   4    0 32000K 25128K kqread 0   0:00  0.00% nginx
20282     1   4    0 32000K 25100K kqread 0   0:00  0.00% nginx

 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
    0     42     41    666   33.0      1     35   22.4   49.8| ad4
    1     29     29    401   37.4      0      0    0.1   38.2| ad6
    0     44     44    633   28.9      0      0    0.1   50.2| ad8
    5     38     38    669   29.9      0      0   22.9   41.0| ad10
    0     45     45    626   32.7      0      0   21.3   52.7| ad12
    0     33     32    496   28.7      0      0    3.4   37.6| ad14


>> Я знаю, какие картинки запрашивают часто и хотел бы их положить в
>> свободную память. Файлуха сама почему-то заняла только 214 метров
>> (214M Buf в top-е). Как можно увеличить размер этого буфера?
>> Простаивает 3 Гига памяти ( 2936M Inact в top-е) :-(

> 2936M Inact + 184M Cache - это и есть файлы.
> 214M Buf - это просто mapping. Жрёт ценную KVA, которую лучше отдать
> mbuf clusters/etc. Я последнее время уменьшаю его до 64M:

> /boot/loader.conf:
> kern.maxbcache=64M

> Ухудшения не заметил.

ясно.  В  тюнинге KVA я совсем не разбираюсь. Обычно тюнинг приводил к
тому, что сервер зависал, ибо делался он вслепую :-)

>> Или  куда  эффективнее  класть/обновлять/удалять картинки самому: в
>> мемкашед или в файловую систему в памяти?

Я  смотрю  аксес-логи  и  понимаю, что могу положить кучу очень мелких
картинок  (например аватарок) в память, потратить на это гиг-полтора и
это наверное будет эффективнее кэша операционки.

Но  только  эти  картинки  могут  удаляться/меняться,  закачиваясь  по
веб-даву. И придётся тогда tail-ить аксес-лог и делать соответствующие
изменения  и  в  кэше.  Кроме того, сам кэш может переполниться и надо
удалять  из  него  что-то.  В этом плане мемкашед больше подходит, чем
файлуха в памяти.

P.S.
ZFS оказался полным Г. Тормозил безбожно. От него пришлось отказаться.
Сейчас  собраны зеркала из двух дисков, поверх них страйпы, поверх них
конкат и далее журнал. Работает в разы быстрее. Хотя RAIDZ некорректно
сравнивать  с текущей конфигурацией, но всёравно ZFS не рекомендую. Он
вещь в себе, которая непонятно что делает, сильно загружая диски.

-- 
С уважением,
Монашёв Михаил, SoftSearch.ru
mailto:postmaster@xxxxxxxxxxxxx
ICQ# 166233339
http://softsearch.ru/
Без бэкапа по жизни.




 




Copyright © Lexa Software, 1996-2009.