Picon
Favicon

Re: скрытые tcp настройки

Arkadiy Kulev wrote:
> Hello nginx-ru,
>
>   вопрос.
>   есть ли в nginx какие-либо скрытые настройки TCP/IP,
которые как-то
>   влияют на размеры пакетов в freebsd?
>
>   пытаюсь решить вот эту проблему:
>   http://www.bsdforums.org/forums/showthread.php?p=282410#post282410 

Я не силен в чтении вывода tcpdump "с листа", но на первый взгляд,
никаких критичных различий не видно. То, что вывод у
них чуть разный под
линуксом и под фрей - оно и не удивительно.

А вот реплика про использование pf в контексте
изменения "на лету" tcp
настроек - не лишена оснований. Правда, для этого надо,
как минимум,
включить scrub all в /etc/pf.conf.


-- 
Best regards, Andrey
St.Petersburg

postmaster | 2 Jan 11:35
Picon
Favicon
Gravatar

gzip_static и mtime

Здравствуйте, Igor.

Зачем в при включённом gzip_static желательно чтобы mtime у
файла и
его сжатого варианта сопадали?

--

-- 
С уважением,
 Монашёв Михаил                        mailto:postmaster@...

Maxim Dounin | 2 Jan 12:18
Picon

Re: gzip_static и mtime

Hello!

On Wed, Jan 02, 2008 at 01:35:00PM +0300, postmaster@... wrote:

>Зачем в при включённом gzip_static желательно чтобы mtime у
файла и
>его сжатого варианта сопадали?

Чтобы If-Modified-Since работал.

Maxim Dounin

postmaster | 2 Jan 12:31
Picon
Favicon
Gravatar

Re[2]: gzip_static и mtime

Здравствуйте, Maxim.

>>Зачем в при включённом gzip_static желательно чтобы mtime у
файла и
>>его сжатого варианта сопадали?

> Чтобы If-Modified-Since работал.

А разве один и тот же браузер может запрашивать то
сжатый, то не
сжатый контент? Или ты о чём-то другом? Почему
If-Modified-Since не
сработает или некорректно сработает?

--

-- 
С уважением,
 postmaster                          mailto:postmaster@...

Valery Kholodkov | 2 Jan 17:43
Picon
Favicon

Re: Re[2]: gzip=?utf-8?Q?=5Fstatic_=D0=B8_mtime?=


Потому что время модификации относится
к ресурсу,
а не к его представлению. gzip -- это сжатое
представление ресурса.

>>>Зачем в при включённом gzip_static
>>> желательно чтобы mtime у файла и
>>>его сжатого варианта сопадали?
>
>> Чтобы If-Modified-Since работал.
>
> А разве один и тот же браузер может
> запрашивать то сжатый, то не
> сжатый контент? Или ты о чём-то другом?
> Почему If-Modified-Since не
> сработает или некорректно сработает?

--

-- 
Best regards,
Valery Kholodkov

Maxim Dounin | 2 Jan 23:47
Picon

Re: gzip_static и mtime

Hello!

On Wed, Jan 02, 2008 at 02:31:17PM +0300, postmaster@... wrote:

>>>Зачем в при включённом gzip_static желательно чтобы mtime у
файла и
>>>его сжатого варианта сопадали?
>
>> Чтобы If-Modified-Since работал.
>
>А разве один и тот же браузер может запрашивать то
сжатый, то не
>сжатый контент? Или ты о чём-то другом? Почему
If-Modified-Since не
>сработает или некорректно сработает?

Теоретически - это ни коим образом не запрещено
стандартом, и 
должно быть обработано корректно. Не говоря уже про
чисто 
теологические соображения.

С практической точки зрения такое может
происходить, например, в 
случае если у IE не стоит галка "использовать HTTP/1.1
через 
прокси", и у пользователя иногда есть прокси, а иногда -
нет (e.g.  
ноутбук, таскаемый между домом и работой). 

(Continue reading)

Siava | 3 Jan 00:03
Picon
Favicon

Re: nginx+apache2+mod_rpaf

После четырехлетнего периода вышла очередная версия mod_rpaf, Apache модуля предназначенного для подмены REMOTE_ADDR на бэкенд-сервере на значение переданное с фронтэнда.

В версии 0.6 сделаны следующие изменения:

  • Добавлена новая конфигурационная директива RPAFheader для указания заголовка в котором передается ip адрес клиента с бэкенда. В частности, теперь можно использовать X-Real-Ip вместо X-Forwarded-For.
  • Исправлена ошибка с keep-alive соединениями. Неправильное использование r->pool для выделения памяти под ip. Сейчас используется r->connection->pool.
  • Обработчик `change_remote_ip' перенесен с APR_HOOK_MIDDLE на APR_HOOK_FIRST. Что позволило решить проблемы с очередностью запуска при работе с модулями типа mod_geoip, а также проблемы при работе с дисковым кэшем в Apache 2.2.x.
http://www.opennet.ru/opennews/art.shtml?num=13510
Хорошая новость.
-- Siava
Nick S. Knutov | 3 Jan 14:35
Favicon

съедание проца

Hello ,

Наблюдается странная картина. VE на базе OpenVZ, отдает ~2х-метровые
файлики. Часто - небыстрым клиентам. Раз в некоторое
время по крону
там пересобираются конфиги. После этого посылается
сигнал на
перечитывание конфигов. После - все воркеры, которые
старые, начинают
есть проц. Пример ниже. Последний воркер - самый
свежий, три
предыдущих аналогично - последовательно наблюдал
их появление и
изменение состояний, которое ровно совпадало с
перечитыванием конфигов
по крону.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
13384 nobody    15   0 17164 5516  716 R   29  0.3   0:13.87 nginx: worker process is shutting down
 7560 nobody    15   0 16660 5016  720 R   20  0.2   1:23.08 nginx: worker process is shutting down
28637 nobody    15   0 17808 6076  708 R   15  0.3   2:10.46 nginx: worker process is shutting down
22115 nobody    16   0 15328 3604  708 R    4  0.2   0:00.81 nginx: worker process

Что с этим делать?

ядро - 2.6.18-8.1.8.el5.028stab039.1

/usr/local/nginx/nginx -v
nginx version: nginx/0.5.33

./configure \
--sbin-path=/usr/local/nginx/nginx \
--conf-path=/etc/nginx.conf \
--pid-path=/var/run/nginx.pid \
--with-select_module \
--with-cc-opt="-D FD_SETSIZE=2048" \
--with-poll_module \
--with-http_stub_status_module \
--with-http_flv_module \
--with-pcre=../pcre-7.2 \
--with-zlib=../zlib-1.2.3  \
--with-md5=../md5 \
--with-sha1=../sha 

Куски из конфига:

worker_processes  1;
events {
        worker_connections  2048;
        use epoll; # use [ kqueue | rtsig | epoll | /dev/poll | select | poll ];
}

http {
        client_header_timeout  3m;
        client_body_timeout    3m;
        send_timeout           3m;

        client_header_buffer_size    1k;
        large_client_header_buffers  4 4k;

        gzip             on;
        gzip_min_length  500;
        gzip_proxied     expired no-cache no-store private auth;
        gzip_types       text/plain text/html text/css application/x-javascript text/xml application/xml
application/xml+rss text/javascript;
        gzip_comp_level 5;

        output_buffers   8 32k;
        postpone_output  1460;

        sendfile        on;
        tcp_nopush      on;
        tcp_nodelay     on; 

Трафика всё это делает от 2х до 18 мегабит волнами.

--

-- 
Best regards,
 Nick Knutov                     mailto:mail@...

Alex Vorona | 3 Jan 15:05
Gravatar

Re: съедание проца

Nick S. Knutov пишет:
> Hello ,
>
> Наблюдается странная картина. VE на базе OpenVZ, отдает ~2х-метровые
> файлики. Часто - небыстрым клиентам. Раз в некоторое
время по крону
> там пересобираются конфиги. После этого посылается
сигнал на
> перечитывание конфигов. После - все воркеры, которые
старые, начинают
> есть проц. Пример ниже. Последний воркер - самый
свежий, три
> предыдущих аналогично - последовательно наблюдал
их появление и
> изменение состояний, которое ровно совпадало с
перечитыванием конфигов
> по крону.
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 13384 nobody    15   0 17164 5516  716 R   29  0.3   0:13.87 nginx: worker process is shutting down
>  7560 nobody    15   0 16660 5016  720 R   20  0.2   1:23.08 nginx: worker process is shutting down
> 28637 nobody    15   0 17808 6076  708 R   15  0.3   2:10.46 nginx: worker process is shutting down
> 22115 nobody    16   0 15328 3604  708 R    4  0.2   0:00.81 nginx: worker process
>
>
> Что с этим делать?
>   
попробуйте натравить strace на выключающийся воркер, например
strace -p 7560 

Nick S. Knutov | 3 Jan 15:08
Favicon

Re: съедание проца



Еще уточнение - nginx как правило отдает те файлы, которые ему отдает апач, которые ему отдают вручную скрипты. Изменить это поведение нельзя. Но, похоже, не только в этой ситуации воркеры едят проц, а вообще сразу после перечитывания конфигов.


Проблема 100% повторяема ручками - проверил на нескольких серверах. Проблема повторяется на нескольких последних версиях nginx.





Thursday, January 3, 2008, 6:35:34 PM, you wrote:


> Hello ,


> Наблюдается странная картина. VE на базе OpenVZ, отдает ~2х-метровые

> файлики. Часто - небыстрым клиентам. Раз в некоторое время по крону

> там пересобираются конфиги. После этого посылается сигнал на

> перечитывание конфигов. После - все воркеры, которые старые, начинают

> есть проц. Пример ниже. Последний воркер - самый свежий, три

> предыдущих аналогично - последовательно наблюдал их появление и

> изменение состояний, которое ровно совпадало с перечитыванием конфигов

> по крону.


>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

> 13384 nobody    15   0 17164 5516  716 R   29  0.3   0:13.87 nginx: worker process is shutting down

>  7560 nobody    15   0 16660 5016  720 R   20  0.2   1:23.08 nginx: worker process is shutting down

> 28637 nobody    15   0 17808 6076  708 R   15  0.3   2:10.46 nginx: worker process is shutting down

> 22115 nobody    16   0 15328 3604  708 R    4  0.2   0:00.81 nginx: worker process


-- 

Best regards,

 Nick                            mailto:mail-wOnFu4v91cPQT0dZR+AlfA@public.gmane.org


Gmane