Добрый день!
У меня ряд серверов раздают большие фильмы и диски изрядно и постоянно
нагружены. Решил воспользоваться двумя советами, чтобы облегчить им жизнь.
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 читать поумнее? или
дело вообще в чем-то другом?
--
Best regards,
Anton Kuznetsov.
Hello,
nginx-0.5.35.
Пользую FCGI::ProcManager. Обнаружил, что CGI.pm работает неправильно, привязал CGI::Fast.
Переменные из GET берёт хорошо, а из POST --- нет.
Порылся в исходниках FCGI, и понял, что POST обрабатывается в CGI.pm.
Собственно проблема с nginx в том, что я ему пишу в конфиге
===
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
===
а переменные в FCGI::ProcManager попадают в %ENV:
===
HTTP_CONTENT_TYPE
HTTP_CONTENT_LENGTH
===
остальные прописанные в конфиге --- идут как есть. И действительно, вот я вставляю в мой FCGI::Spawn:
===
map { $ENV{ $_ } = $ENV{ "HTTP_$_" } } qw/CONTENT_LENGTH CONTENT_TYPE/
if $ENV{ 'REQUEST_METHOD' } eq 'POST';
===
перед "new CGI::Fast" --- и переменные им берутся как надо.
Вопрос в чём: я всё оставляю как сейчас, или это бага nginx? а то мы спецификаций да сишных исходников не читатели, только почитатели-причитатели :)
73! Peter
--
http://vereshagin.org
Hi, all!
Есть проблемы с использованием weight в upstream в целях распределения
нагрузки.
Если вес выставлен одинаковый, то нагрузка распределяется равномерно.
Пример:
upstream test_backend {
server localhost:59040 weight=10000;
server other_server:59040 weight=10000;
}
Если же выставить разный вес, то нагрузка распределяется неравномерно по
времени, каждые десять минут меняется сервер и все. Сужу об этом по графикам
загрузки серверов. 10 минут все запросы идут на один сервер, затем 10 мин. на
другой.
Пример:
upstream test_backend {
server localhost:59040 weight=10000;
server other_server:59040 weight=5000;
}
location / {
expires epoch;
fastcgi_pass test_backend;
fastcgi_upstream_max_fails 0;
fastcgi_next_upstream error timeout invalid_header http_500;
include fastcgi_param.conf;
}
Но обнаружил, что если цель треть нагрузки отправлять на другой сервер, то
такое помогает:
upstream test_backend {
server localhost:59040 weight=10000;
server localhost:59040 weight=10000;
server other_server:59040 weight=10000;
}
# nginx -v
nginx version: nginx/0.3.60
# uname -a
Linux tapo.net 2.6.8-2-386 #1 Tue Aug 16 12:46:35 UTC 2005 i686 GNU/Linux
К примеру, есть есть PHP скрипт такого содержания:
<?php
for ($i = 0; $i < 30; $i++)
{
echo 'xxxxxxxxxxxxxxxx<br>';
ob_flush();
flush();
sleep(1);
};
?>
Он досылает на клиент новые данные в течении 30 сек с интервалом в 1 сек.
Когда PHP работает как mod_apache, то именно так и происходит. Но в связке
nginx+FastCGI (менеджером FastCGI служит php-fpm) получается так: 30
секунд ни какого ответа, а потом бааах и уже готова страница.
Вот не знаю в какую сторону копать.
Здравствуйте.
Много думал о реализации эффективного кэширования статики. Исходил я
из желания максимально утилизировать ресурсы железа, чтобы процессор,
память и диск были максимально загружены и при этом работающие
процессы не мешали друг-другу, конкурируя за какой-то ресурс. И кроме
всего прочего пришёл к мысле, что было бы удобно управлять содержимым
файлового кэша OS. Т.е. тем, что может попадать в файловый кэш
операционки, а что нет.
Было бы например удобно принудить nginx всё отдавать с диска, а память
не трогать и не конкурировать с другими процессами за её
использование. Ибо другие процессы возможно тоже захотят закэшировать
в кэше файлухи свои файлы и, получив больше свободной памяти, будут
работать пошустрее. Или же второй вариант: мы точно знаем, что спайдер
поисковика забьёт нам кэш файлухи тем, что никто никогда не запросит.
Или же нет смысла класть в кэш большие файлы, лучше положить много
мелких. Или мы знаем, что в этой директории горячий контент, а во всех
остальных редко запрашиваемый... Короче куча случаев, когда опция
запрета помещения отданного файла в файловый кэш может быть эффективно
использована.
--
С уважением,
Михаил Монашёв, SoftSearch.ru
mailto:postmaster@softsearch.ru
ICQ# 166233339
http://michael.mindmix.ru/
Без бэкапа по жизни.
> iscsi - это один логический диск
> и неважно, сколько там внутри других носителей
> "контроллер" iscsi не будет обслуживать запросы в несколько потоков по
> типу "10 физических томов == 10 вокеров нгинх"
Планируется что один сервер будет раздавать с двух или более iscsi
массивов, поэтому 1 воркер не самое лучшее решение. Но получить гарантию,
что воркеры сами разбегутся по разным массивам и не полезут все к одному
массиву как я понимаю нет. А скорость при этом падает процентов на 30 по
сравнению с ситуацией 1 воркер 1 массив.
--
С уважением,
Волков Олег
> В сообщении от 28 ноября 2008 17:02 Volkov Oleg написал(a):
>> В сообщении от Friday 28 November 2008 11:59:47 Igor Sysoev написал(а):
>> > On Fri, Nov 28, 2008 at 11:41:05AM +0300, Volkov Oleg wrote:
>> > > Задача заключается в раздаче по http больших файлов. Запросы к
>> файлам
>> > > по 1 мегабайту (сами файлы порядка гигабайта).
>> > > Можно ли заставить nginx читать с диска весь запрос целиком (1 Мб),
>> > > кэшировать в оперативке а потом раздавать? При стандартных
>> параметрах
>> > > скорость (по сравнению с линейным чтением) резко падает уже при 20
>> > > коннектах.
>> > >
>> > > Все это планируется крутить на ОС Linux. Пробовал включать/выключать
>> > > sendfile, на скорость не влияло.
>> >
>> > Можно
>> >
>> > sendfile off;
>> > output_buffers 1 1m;
>> >
>> > только память быстро кончится - и у процессов, и в ядре на буферы
>> > сокетов.
>>
>> Это не помогает. output_buffers пробовал делать больше - все равно.
>> Сейчас работаю с одним массивом iscsi - при 2 и более воркерах скорость
>> меньше, чем при 1 воркере. Ядер на машине 8 штук.
>
> iscsi с gfs ?
xfs
>>
>> Пробовал крутить некоторые параметры ядра
>> http://www.ibm.com/developerworks/ru/library/l-hisock/index.html
>> пока резуоттата не добился. Максимум получается 20 Мегабайт в секунду.
>> Это
>> при большом количестве одновременных потоков. Если качать в один поток -
>> скорость в 2-3 раза больше.
>>
>> Пробую все это на Centos 5
>
> --
> С уважением,
> Вячеслав Кузнецов
> ООО "АВТО.РУ"
> тел. 8(499)730-8-730 (доб. 112)
>
Подскажите пожалуйста, где лучше всего организовать передачу данных в
fast-cgi приложение.
Мне нужно следующее.
Провести анализ заголовков, которые пришли от пользователя, и на
основе них передать информацию(сформировав свой заголовок), в fast-cgi
приложение.
Самым простым решением является патч для вышеназванного модуля
и добавление заголовка в r->headers_in.headers в
ngx_http_fastcgi_create_request.
Но хочется это сделать с помощью отдельного модуля.
Возможно ли это?
Подскажите, как сделать фильтр(?), который срабатывал бы до
ngx_http_fastcgi_module.
Спасибо.
Добрый день.
Потребовалось мне посмотреть на hadoop (требуется решение создания
хранилища данных с реплицированием, масштабированностью и тд).
Сразу понятно, что данные определенных видов туда можно складывать и
иметь к ним оперативный доступ (в том числе и на замену медленным
реляцонным базам данных).
Но вот вопрос - а стоит ли туда складывать картинки? Кажется, что
связка nginx + filesystem должны работать на порядок быстрее.... Ведь
доступ к данным в hdfs идет только через собственный api, а доступа
как к файловой системе я чего-то не нашел..
Николай