Re: Дотюнился... Странности в iostat

[ArjLover]

О! Ты-то мне и был нужен, кажется начитавшись твоих сообщений я начал диски
форматировать. :)
sendfile отключить не могу - смерти подобно, точнее не подобно, а сразу. Я
так жил на апаче до 200 мегабит, а сейчас 400 - спасибо nginx+sendfile.
Поэтому этот вариант отпадает, хотя скажу честно - я его еще раз попробовал
прежде чем все диски откатывать обратно, еле остановить успел - сервер
закачался. Но без sendfile читает конечно умнее, если говорить только о
дисках. Но давайте вернемся к нашим баранам, у нас есть матрица 2х2 - с
патчем ядра от Сысоева и без и диски отформатированные вот так:
#newfs -O 2 -U -a 2 -b 65536 -d 65536 -e 65536 -f 8192 -g 16384 -h 64
или вот так:
newfs -O 2 -U -a 8 -b 16384 -d 16384 -e 2048 -f 2048 -g 16384 -h 64

Второй вариант дефолтно-изначальный. Я накатил патчик ядра и sendfile сразу
стал читать 512 или 1024 килов за одну операцию чтения - где сколько памяти
можно было на серверах отдать под MAXPHYS - его тоже сразу потюнил. Но мне
этого показалось мало и я решил диски переформатировать. И тут все стало
хуже чем было, до патча и форматирования читалось до 128 (дефолтный
MAXPHYS), а теперь читается только по 64, несмотря на патч и увеличенный
MAXPHYS! Кто-то может обьяснить почему? И что вообще тогда дает этот блок на
диске по 64к?

А.

25 ноября 2008 г. 16:14 пользователь MZ <zuborg at advancedhosters.com>написал:

> В пн, 24/11/2008 в 18:52 +0100, ArjLover пишет:
> > Добрый день!
> >
> > У меня ряд серверов раздают большие фильмы и диски изрядно и постоянно
> > нагружены. Решил воспользоваться двумя советами, чтобы облегчить им
> > жизнь.
> > Freebsd 6.3 nginx/0.7.21 sendfile on;
> >
> > для начала пересобрал ядро с MAXPHYS=1024*1024 и поднял
> > kern.ipc.sfreadahead - заметно полегчало.
> > параллельно на другом сервере отформатировал винчестеры с блоком 64kb
> > - тоже появился прирост на 30%, но там не nginx.
> > Воодушевленный решил скрестить оба метода.
> >
> > Отформатировал все винчестеры с блоком 64kb и тут случилась засада.
> > nginx в жестком biord! все тормозит, скорость упала в два раза.
> > смотрю iostat:
> >
> >       tty             ad4              ad6              da0
> > cpu
> >  tin tout  KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s  us ni sy
> > in id
> >    0  233 64.00  90  5.62  64.00  54  3.37  280.25   8  2.19   4  0 11
> > 15 70
> >    0   78 64.00  91  5.68  64.00  53  3.31  218.12  16  3.40   3  0  8
> > 20 70
> >    0   78 64.00  85  5.31  64.00  67  4.18  288.00   14  3.25   1  0
> > 13 17 69
> >    0   78 64.00  90  5.62  64.00  62  3.87  189.29  17  3.14   2  0 12
> > 17 68
> >    0   78 64.00  91  5.68  64.00  56  3.50  151.58  33  4.88   2  0  9
> > 18 70
> >    0   78 64.00  82  5.12  64.00  54  3.37  139.28  36  4.89   2  0 11
> > 18 68
> >    0   78 64.00  89  5.56  64.00  60  3.75  245.82  22  5.28   2  0  8
> > 16 73
> >
> > Первые два - SATA, третий - системный скази, раздают все. Системный
> > конечно переформатированию не подвергался.
> > Вопрос - почему у всех винтов отформатированных с блоком 64kb, KB/t
> > стабильно  - 64.00 и плавают только tps? А у системного KB/t - заметно
> > поприличнее!
> >
> > Но это когда работает только nginx, запускаю mc и копирую файл с диска
> > на диск, несмотря на то что gstat говорит 90% занятости, файл
> > копируется легко в 20+мег в секунду, а iostat показывает следующее:
> >   0  358 512.00 108 53.95   0.00   0  0.00  512.00 108 53.95   4  0 11
> > 2 83
> >    0  331 512.00 105 52.45   0.00   0  0.00  512.00 105 52.45   2  0
> > 11  1 86
> >    0  491 512.00 108 53.95   0.00   0  0.00  512.00 108 53.95   4  0
> > 12  1 83
> >    0  361 512.00 109 54.45   0.00   0  0.00  512.00 109 54.45   3  0
> > 12  2 83
> >
> >
> > Заветные 512, как завещал sfreadahead! И колечество операций tps даже
> > практически не выросло! Ничего не понимаю! Можно как-то, без
> > переформатирования всех дисков обратно, заставить nginx читать
> > поумнее? или дело вообще в чем-то другом?
>
> sendfile off;
> и будет читаться поумнее
>
> > --
> > Best regards,
> > Anton Kuznetsov.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20081125/362a0682/attachment.html>