Re: Senfile + Threads + mincore in Linux?
Объясню насчет когда нужно )) Часть файлов отдавать так наверняка нерационально. Если они мелкие, то это многих fopen/mmap, что нехорошо Но если нужно отдать большой файл (например, вынести большие файлы в отдельную локацию и там включать/выключать настройкой такую фичу), да еще и дескриптор в кэше держать, а не открывать каждый раз, то кол-во mmap будет не столь значительно, мне кажется? 29 июня 2015 г., 17:05 пользователь Gelun, Artem a...@gelun.ru написал: Ну у вас ведь файл открывется не при каждом запросе? Вы откываете файл и сохраняете дескриптор в структуре (не помню какой ))) ) что мешает в этой же структуре сохранять указатель на mmap? и unmap делать вместе с закрытием файла (если ранее указатель был проинициализирован, а mmap делать только когда нужно)? 29 июня 2015 г., 16:40 пользователь Валентин Бартенев vb...@nginx.com написал: On Monday 29 June 2015 20:28:08 Igor M Podlesny wrote: 2015-06-29 20:18 GMT+07:00 Валентин Бартенев vb...@nginx.com: Varnish не веб-сервер, а кэш, причем кэш там организован через mmap(). Новости! ;-) Постоянные mmap() + mincore() + unmap() - получится недешево. Ну так можно ж не постоянно. Зачем постоянно-то? Замэпить и сёрвить. У вас же не один файл, так? Пулы потоков и нужны там, где файлов много больше, чем оперативной памяти. Нужно будет mmap() делать минимум на каждый запрос, тысячи mmap()/munmap()-ов в секунду - это большая нагрузка на подсистему памяти. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Senfile + Threads + mincore in Linux?
On Monday 29 June 2015 20:28:08 Igor M Podlesny wrote: 2015-06-29 20:18 GMT+07:00 Валентин Бартенев vb...@nginx.com: Varnish не веб-сервер, а кэш, причем кэш там организован через mmap(). Новости! ;-) Постоянные mmap() + mincore() + unmap() - получится недешево. Ну так можно ж не постоянно. Зачем постоянно-то? Замэпить и сёрвить. У вас же не один файл, так? Пулы потоков и нужны там, где файлов много больше, чем оперативной памяти. Нужно будет mmap() делать минимум на каждый запрос, тысячи mmap()/munmap()-ов в секунду - это большая нагрузка на подсистему памяти. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Small bug in src/stream/ngx_stream_proxy_module.c
(1066) : warning C4244: '=' : conversion from 'off_t' to 'size_t', possible
loss of data
diff line 1066:
if (size (size_t) limit) {
-size = limit;
+size = (size_t) limit;
}
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,259969,259969#msg-259969
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Re: Senfile + Threads + mincore in Linux?
Ну у вас ведь файл открывется не при каждом запросе? Вы откываете файл и сохраняете дескриптор в структуре (не помню какой ))) ) что мешает в этой же структуре сохранять указатель на mmap? и unmap делать вместе с закрытием файла (если ранее указатель был проинициализирован, а mmap делать только когда нужно)? 29 июня 2015 г., 16:40 пользователь Валентин Бартенев vb...@nginx.com написал: On Monday 29 June 2015 20:28:08 Igor M Podlesny wrote: 2015-06-29 20:18 GMT+07:00 Валентин Бартенев vb...@nginx.com: Varnish не веб-сервер, а кэш, причем кэш там организован через mmap(). Новости! ;-) Постоянные mmap() + mincore() + unmap() - получится недешево. Ну так можно ж не постоянно. Зачем постоянно-то? Замэпить и сёрвить. У вас же не один файл, так? Пулы потоков и нужны там, где файлов много больше, чем оперативной памяти. Нужно будет mmap() делать минимум на каждый запрос, тысячи mmap()/munmap()-ов в секунду - это большая нагрузка на подсистему памяти. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Senfile + Threads + mincore in Linux?
On Monday 29 June 2015 16:50:42 Igor M Podlesny wrote: 2015-06-29 15:37 GMT+07:00 Andrey Istochkin alstpost...@gmail.com: Насколько я понимаю, mincore оперирует адресами из виртуального адресного пространства процесса, а не файловыми дескрипторами. Таким образом, чтобы как-то применить его к файлу, нужно через mmap отображать файл в то самое адресное пространство, что, видимо, не является приемлемым решением. Ну почему же не является(?). Я так понимаю, что Varnish, например, во все поля этим занимается: https://www.varnish-cache.org/trac/wiki/ArchitectNotes Varnish не веб-сервер, а кэш, причем кэш там организован через mmap(). Постоянные mmap() + mincore() + unmap() - получится недешево. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Senfile + Threads + mincore in Linux?
On Monday 29 June 2015 17:08:49 Gelun, Artem wrote: Объясню насчет когда нужно )) Часть файлов отдавать так наверняка нерационально. Если они мелкие, то это многих fopen/mmap, что нехорошо Но если нужно отдать большой файл (например, вынести большие файлы в отдельную локацию и там включать/выключать настройкой такую фичу), да еще и дескриптор в кэше держать, а не открывать каждый раз, то кол-во mmap будет не столь значительно, мне кажется? Файл открывается при каждом запросе, если только не настроен отдельно open_file_cache с которым есть свои проблемы. Добавление туда ещё mmap() принесет приличное количество новой логики в разных местах, при этом далекой от совершенства по двум причинам: 1. mincore() будет пессимизировать наиболее распространенный случай, когда данные все же есть в памяти, поэтому включать его и пулы потоков глобально в большинстве случаев всё равно будет невыгодно. При этом потребуется включать еще и open_file_cache, так что правильная настройка всего этого вместе становится совсем сложной. В итоге таким решением будет пользоваться с умом человек десять. 2. У вас остается race condition между вызовом mincore() и read()/sendfile(). Лучше пинайте разработчиков ядра, чтобы наконец замерджили RWF_NONBLOCK или fincore() патчи. Последний хоть и не лишен второго недостатка, но по крайней мере потребует на порядок меньше нового кода. -- Валентин Бартенев 29 июня 2015 г., 17:05 пользователь Gelun, Artem a...@gelun.ru написал: Ну у вас ведь файл открывется не при каждом запросе? Вы откываете файл и сохраняете дескриптор в структуре (не помню какой ))) ) что мешает в этой же структуре сохранять указатель на mmap? и unmap делать вместе с закрытием файла (если ранее указатель был проинициализирован, а mmap делать только когда нужно)? 29 июня 2015 г., 16:40 пользователь Валентин Бартенев vb...@nginx.com написал: On Monday 29 June 2015 20:28:08 Igor M Podlesny wrote: 2015-06-29 20:18 GMT+07:00 Валентин Бартенев vb...@nginx.com: Varnish не веб-сервер, а кэш, причем кэш там организован через mmap(). Новости! ;-) Постоянные mmap() + mincore() + unmap() - получится недешево. Ну так можно ж не постоянно. Зачем постоянно-то? Замэпить и сёрвить. У вас же не один файл, так? Пулы потоков и нужны там, где файлов много больше, чем оперативной памяти. Нужно будет mmap() делать минимум на каждый запрос, тысячи mmap()/munmap()-ов в секунду - это большая нагрузка на подсистему памяти. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Senfile + Threads + mincore in Linux?
On 6/29/15 5:43 PM, Валентин Бартенев wrote: [...] 2. У вас остается race condition между вызовом mincore() и read()/sendfile(). Вот эта часть важная -- на практике под высокой нагрузкой между этими двумя вызовами данные из кэша VM вымываются и читающий сисколл блокируется. Чтобы закрыть это окно вам нужен mlock(), но не простой, а неблокирующийся. И мы это направление довольно подробно на FreeBSD исследовали. Настолько, что получилось вот это: https://www.freebsd.org/cgi/man.cgi?query=aio_mlock Этот системный вызов в теории позволяет вам самостоятельно управлять механизмом кэширования в памяти, не полагаясь на эвристику ОС. Но натурные испытания показали, что идея не самая удачная. По крайней мере на FreeBSD в конфигурации, когда активный dataset на два и более порядков (XX TB vs XX GB) превосходит размер доступной оперативной памяти, огромное количество mmap/munmap давало столь большой оверхед, что выигрыш от хитрого кэширования с предчтением и удержанием в памяти был неизмеримо мал. Фактически, пришли к выводу, который был более или менее очевиден с самого начала, что кэширование при таком профиле нагрузки не поможет. -- Maxim Konovalov http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Senfile + Threads + mincore in Linux?
2015-06-29 20:40 GMT+07:00 Валентин Бартенев vb...@nginx.com: У вас же не один файл, так? Пулы потоков и нужны там, где файлов много больше, чем оперативной памяти. Нужно будет mmap() делать минимум на каждый запрос, тысячи mmap()/munmap()-ов в секунду - это большая нагрузка на подсистему памяти. Ну не, я не такой шаблон себе представлял, в связи с этим, а, скорее, что-то вроде: ... A minute after the start the special “cache loader” process is activated. It loads information about previously cached data stored on file system into a cache zone. The loading is done in iterations. During one iteration no more than loader_files items are loaded (by default, 100). Besides, the duration of one iteration is limited by the loader_threshold parameter (by default, 200 milliseconds). Between iterations, a pause configured by the loader_sleep parameter (by default, 50 milliseconds) is made. ... -- http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_path -- ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Senfile + Threads + mincore in Linux?
2015-06-29 15:37 GMT+07:00 Andrey Istochkin alstpost...@gmail.com: Насколько я понимаю, mincore оперирует адресами из виртуального адресного пространства процесса, а не файловыми дескрипторами. Таким образом, чтобы как-то применить его к файлу, нужно через mmap отображать файл в то самое адресное пространство, что, видимо, не является приемлемым решением. Ну почему же не является(?). Я так понимаю, что Varnish, например, во все поля этим занимается: https://www.varnish-cache.org/trac/wiki/ArchitectNotes -- ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
[PATCH] Add support for tcp_user_timeout in http listen directive
# HG changeset patch
# User Andy Isaacson a...@orionlabs.co
# Date 1435618451 25200
# Mon Jun 29 15:54:11 2015 -0700
# Node ID c11304760218324ea55de7250a613af8f13e431b
# Parent b95e70ae6bcdbae99a967df01e1011839f19ee0e
Add support for tcp_user_timeout in http listen directive
This commit adds support for a new tcp_user_timeout=timeout_sec
parameter to the listen directive. When enabled and set to a value
greater than zero, the TCP_USER_TIMEOUT sockopt is set. From tcp(7):
This specifies the maximum amount of time in milliseconds
that transmitted data may remain unacknowledged before TCP
will forcibly close the corresponding connection and return
ETIMEDOUT to the application.
Without this capability, a HTTP longpoll connection can remain active
for up to 950 seconds after the last ACK from the client.
Note that the tcp_user_timeout value is specified in (integer) seconds,
but the setsockopt API is specified in milliseconds.
This capability is similar to the systemwide configuration
net.ipv4.tcp_retries2 on Linux, but more flexible and per-socket.
diff -r b95e70ae6bcd -r c11304760218 auto/unix
--- a/auto/unix Thu Sep 05 16:53:02 2013 +0400
+++ b/auto/unix Mon Jun 29 15:54:11 2015 -0700
@@ -330,6 +330,18 @@
. auto/feature
+ngx_feature=TCP_USER_TIMEOUT
+ngx_feature_name=NGX_HAVE_TCP_USER_TIMEOUT
+ngx_feature_run=no
+ngx_feature_incs=#include sys/socket.h
+ #include netinet/in.h
+ #include netinet/tcp.h
+ngx_feature_path=
+ngx_feature_libs=
+ngx_feature_test=setsockopt(0, IPPROTO_TCP, TCP_USER_TIMEOUT, NULL, 0)
+. auto/feature
+
+
ngx_feature=TCP_KEEPIDLE
ngx_feature_name=NGX_HAVE_KEEPALIVE_TUNABLE
ngx_feature_run=no
diff -r b95e70ae6bcd -r c11304760218 src/core/ngx_connection.h
--- a/src/core/ngx_connection.h Thu Sep 05 16:53:02 2013 +0400
+++ b/src/core/ngx_connection.h Mon Jun 29 15:54:11 2015 -0700
@@ -80,6 +80,10 @@
int setfib;
#endif
+#if (NGX_HAVE_TCP_USER_TIMEOUT)
+int tcp_user_timeout;
+#endif
+
};
diff -r b95e70ae6bcd -r c11304760218 src/event/ngx_event_accept.c
--- a/src/event/ngx_event_accept.c Thu Sep 05 16:53:02 2013 +0400
+++ b/src/event/ngx_event_accept.c Mon Jun 29 15:54:11 2015 -0700
@@ -284,6 +284,23 @@
}
}
+#if (NGX_HAVE_TCP_USER_TIMEOUT)
+#ifdef TCP_USER_TIMEOUT
+if (ls-tcp_user_timeout) {
+int value = ls-tcp_user_timeout;
+
+if (setsockopt(s, IPPROTO_TCP, TCP_USER_TIMEOUT, value,
+sizeof(int))
+== -1)
+{
+ngx_log_error(NGX_LOG_ALERT, log, ngx_socket_errno,
+ setsockopt(TCP_USER_TIMEOUT, %d) for %V failed,
+ value, c-addr_text);
+}
+}
+#endif
+#endif
+
#if (NGX_DEBUG)
{
diff -r b95e70ae6bcd -r c11304760218 src/http/ngx_http.c
--- a/src/http/ngx_http.c Thu Sep 05 16:53:02 2013 +0400
+++ b/src/http/ngx_http.c Mon Jun 29 15:54:11 2015 -0700
@@ -1800,6 +1800,10 @@
ls-deferred_accept = addr-opt.deferred_accept;
#endif
+#if (NGX_HAVE_TCP_USER_TIMEOUT defined TCP_USER_TIMEOUT)
+ls-tcp_user_timeout = addr-opt.tcp_user_timeout;
+#endif
+
#if (NGX_HAVE_INET6 defined IPV6_V6ONLY)
ls-ipv6only = addr-opt.ipv6only;
#endif
diff -r b95e70ae6bcd -r c11304760218 src/http/ngx_http_core_module.c
--- a/src/http/ngx_http_core_module.c Thu Sep 05 16:53:02 2013 +0400
+++ b/src/http/ngx_http_core_module.c Mon Jun 29 15:54:11 2015 -0700
@@ -4085,6 +4085,31 @@
continue;
}
+if (ngx_strncmp(value[n].data, tcp_user_timeout=, 17) == 0) {
+#if (NGX_HAVE_TCP_USER_TIMEOUT defined TCP_USER_TIMEOUT)
+int timeout_sec = ngx_atoi(value[n].data + 17, value[n].len - 17);
+
+/*
+ * convert from seconds (in config file) to milliseconds (for
+ * setsockopt)
+ */
+lsopt.tcp_user_timeout = timeout_sec * 1000;
+
+if (lsopt.tcp_user_timeout 0) {
+ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
+ Invalid tcp_user_timeout \%V\,
+ value[n]);
+return NGX_CONF_ERROR;
+}
+#else
+ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
+ tcp_user_timeout \%V\ is not supported on
+ this platform, ignored,
+ value[n]);
+#endif
+continue;
+}
+
if (ngx_strcmp(value[n].data, deferred) == 0) {
#if (NGX_HAVE_DEFERRED_ACCEPT defined TCP_DEFER_ACCEPT)
lsopt.deferred_accept = 1;
diff -r b95e70ae6bcd -r c11304760218 src/http/ngx_http_core_module.h
--- a/src/http/ngx_http_core_module.h Thu Sep 05 16:53:02 2013 +0400
+++ b/src/http/ngx_http_core_module.h Mon Jun 29 15:54:11 2015 -0700
@@ -102,6 +102,10 @@
ngx_uint_t
Re: Re[2]: проблема с rewrite
Дело в том, что 'destination' передается в заголовках запроса, для правки
которых встроенных средств, наверное, нет. Можно попробовать посмотреть в
сторону http://wiki.nginx.org/HttpHeadersMoreModule или как-то поизголяться
с проксированием на самого себя и выставлением в проксированном запросе
нужного заголовка. Но как-то это костыльно все очень.
29 июня 2015 г., 11:51 пользователь Иван Мишин simplebo...@gmail.com
написал:
Не ужели нет никаких вариантов дописать слеш в конец того каталога в
который перемещается другой каталог?
25 июня 2015 г., 14:54 пользователь Иван Мишин simplebo...@gmail.com
написал:
Андрей, спасибо, помогло. Добавил break и каталоги удаляются без проблем.
Но есть еще один вопрос, касающийся метода MOVE, то есть перемещение
каталогов.
К письму прикрепляю логи.
Проблема конкретно тут:
2015/07/26 14:48:08 [error] 6735#0: *61 both URI /Family/Новая папка/
and Destination URI
http://192.168.200.92/Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0%20%282%29/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0;
should be either collections or non-collections, client: 192.168.200.81,
server: 192.168.200.92, request: MOVE
/Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0
HTTP/1.1, host: 192.168.200.92
Винда не понимает сама где каталоги, а где просто файлы.
То есть в случае метода MOVE я с помощью rewrite дописываю в конце слеш,
а вот как дописать слеш к тому каталогу в который я перемещаю первый
каталог не понятно. Если к методу PROPFIND дописать
if (-d $webdav_root/$uri) {
rewrite ^(.*[^/])$ $1/ break;
}
то в логах просто все зацикливается и все. Может у вас есть какие-то
мысля по этому поводу?
25 июня 2015 г., 11:49 пользователь Andrey Istochkin
alstpost...@gmail.com написал:
Попробуйте в @delete_handler в rewrite добавить 'break'. Так как в
access_логе фигурирует 598, то похоже на то, что @delete_handler
отрабатывает, отрабатывает rewrite, после чего запрос уходит снова в
'location ^~ /Family', опять отрабатывает 'return 598', но так как
recursive_error_pages по-умолчанию выключена, error_page на этот раз не
срабатывает, и клиент получает 598.
25 июня 2015 г., 9:28 пользователь Иван Мишин simplebo...@gmail.com
написал:
в этом случае до винды этот код дойти не должен. если доходит - вы
плохо настроили error
Ну судя по tcpdump на стороне винды, 598 код все же доходит до нее.
про какой? про переход в именованный локейшн? или про то, что код,
который для этого используется, наружу отдаваться не должен?
И про то и про другое, если не затруднит.
ВО-первых, PROPFIND метод работает, при том что он организован в моем
конфиге тем же способом что и метод DELETE с той лишь разницей что PROPFIND
через 599 код работает, а DELETE через 598. Но я так понимаю что-это
различие не на что не влияет ибо пробовал менять коды местами и...вот
цитата моих слов по этому поводу:
599 отрабатывает точно правильно потому что метод PROPFIND работает
без вопросов. В качестве экспиремента поменял местами 599 и 598 в
итоге PROPFIND как работал так и работает а DELETE каталогов как не
работал
так и не работает.
ВО-вторых, мне казалось что если с клиента ( в данном случае с винды)
ушел запрос DELETE на nginx и nginx то nginx его должен отработать и
каталог удалить, и не важно что он ответит клиент, потому что для клиента
этот ответ будет чисто информационным т.е. не будет влиять на результат
выполнения первого запроса (запроса на DELETE).
24 июня 2015 г., 18:55 пользователь Daniel Podolsky onoko...@gmail.com
написал:
Даниель, можно подробнее пожалуйста про этот момент
про какой? про переход в именованный локейшн? или про то, что код,
который для этого используется, наружу отдаваться не должен?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Malware in /tmp/nginx_client
Yes, I think I will do that. So they are indeed cached requests? Posted at Nginx Forum: http://forum.nginx.org/read.php?2,259948,259960#msg-259960 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Re[2]: проблема с rewrite
Не ужели нет никаких вариантов дописать слеш в конец того каталога в
который перемещается другой каталог?
25 июня 2015 г., 14:54 пользователь Иван Мишин simplebo...@gmail.com
написал:
Андрей, спасибо, помогло. Добавил break и каталоги удаляются без проблем.
Но есть еще один вопрос, касающийся метода MOVE, то есть перемещение
каталогов.
К письму прикрепляю логи.
Проблема конкретно тут:
2015/07/26 14:48:08 [error] 6735#0: *61 both URI /Family/Новая папка/
and Destination URI
http://192.168.200.92/Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0%20%282%29/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0;
should be either collections or non-collections, client: 192.168.200.81,
server: 192.168.200.92, request: MOVE
/Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0
HTTP/1.1, host: 192.168.200.92
Винда не понимает сама где каталоги, а где просто файлы.
То есть в случае метода MOVE я с помощью rewrite дописываю в конце слеш, а
вот как дописать слеш к тому каталогу в который я перемещаю первый каталог
не понятно. Если к методу PROPFIND дописать
if (-d $webdav_root/$uri) {
rewrite ^(.*[^/])$ $1/ break;
}
то в логах просто все зацикливается и все. Может у вас есть какие-то мысля
по этому поводу?
25 июня 2015 г., 11:49 пользователь Andrey Istochkin
alstpost...@gmail.com написал:
Попробуйте в @delete_handler в rewrite добавить 'break'. Так как в
access_логе фигурирует 598, то похоже на то, что @delete_handler
отрабатывает, отрабатывает rewrite, после чего запрос уходит снова в
'location ^~ /Family', опять отрабатывает 'return 598', но так как
recursive_error_pages по-умолчанию выключена, error_page на этот раз не
срабатывает, и клиент получает 598.
25 июня 2015 г., 9:28 пользователь Иван Мишин simplebo...@gmail.com
написал:
в этом случае до винды этот код дойти не должен. если доходит - вы
плохо настроили error
Ну судя по tcpdump на стороне винды, 598 код все же доходит до нее.
про какой? про переход в именованный локейшн? или про то, что код,
который для этого используется, наружу отдаваться не должен?
И про то и про другое, если не затруднит.
ВО-первых, PROPFIND метод работает, при том что он организован в моем
конфиге тем же способом что и метод DELETE с той лишь разницей что PROPFIND
через 599 код работает, а DELETE через 598. Но я так понимаю что-это
различие не на что не влияет ибо пробовал менять коды местами и...вот
цитата моих слов по этому поводу:
599 отрабатывает точно правильно потому что метод PROPFIND работает без
вопросов. В качестве экспиремента поменял местами 599 и 598 в
итоге PROPFIND как работал так и работает а DELETE каталогов как не работал
так и не работает.
ВО-вторых, мне казалось что если с клиента ( в данном случае с винды)
ушел запрос DELETE на nginx и nginx то nginx его должен отработать и
каталог удалить, и не важно что он ответит клиент, потому что для клиента
этот ответ будет чисто информационным т.е. не будет влиять на результат
выполнения первого запроса (запроса на DELETE).
24 июня 2015 г., 18:55 пользователь Daniel Podolsky onoko...@gmail.com
написал:
Даниель, можно подробнее пожалуйста про этот момент
про какой? про переход в именованный локейшн? или про то, что код,
который для этого используется, наружу отдаваться не должен?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Senfile + Threads + mincore in Linux?
Насколько я понимаю, mincore оперирует адресами из виртуального адресного пространства процесса, а не файловыми дескрипторами. Таким образом, чтобы как-то применить его к файлу, нужно через mmap отображать файл в то самое адресное пространство, что, видимо, не является приемлемым решением. В http://habrahabr.ru/post/260669/ указано, что были попытки по созданию системного вызова fincore(https://lwn.net/Articles/371538/), который работал бы как раз с файловыми дескрипторами, но как-то не срослось. 28 июня 2015 г., 22:10 пользователь Gelun, Artem a...@gelun.ru написал: Добрый день всем. Возможно, идея/вопрос не новы, но: Сейчас (с версии 1.7.11, если не ошибаюсь) sendfile может быть как блокирующим, так и неблокирующим *основной поток*, вызываясь в отдельном треде. При этом пул тредов фиксирован и если, например, я выделил 10 тредов, которые заняты чтением с диска (заблокированы), то другие читатели будут ожидать их даже если данные уже находятся в page cache, что не рационально, имхо. Т.е. мы можем иметь нагрузку, при которой 90% трафика будет отдаваться из PageCache, 10% с диска и эти 10% могут заблокировать кэшированные, популярные ответы. Вопрос: можно ли добавить в эту логику вызов mincore (в linux) для того, чтобы определить сколько данных есть в page cache, отправке этого объема данных и, если они отправились (возврат == NGX_OK) вызывать остаток sendfile в треде? Есть ли какие-то потенциальные проблемы за пределами ngx_linux_sendfile_chain.c строк 182-203 внутри #if (NGX_THREADS) ? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Nginx-1.9.2 fatal code 2 !!
Hi, We've just compiled latest nginx-1.9.2 on Debian wheezy 7 in order to utilize aio threads directive for our storage but nginx started to crash since we enabled aio threads on it. Following is the compiled options and log about the crash : root@archive3:/usr/local/nginx/conf/vhosts# nginx -V nginx version: nginx/1.9.2 built by gcc 4.7.2 (Debian 4.7.2-5) configure arguments: --sbin-path=/usr/local/sbin/nginx --with-http_flv_module --with-http_mp4_module --with-threads --with-stream --with-debug error_log : 2015/06/30 04:14:07 [alert] 32076#32076: worker process 11097 exited with fatal code 2 and cannot be respawned 2015/06/30 04:14:03 [alert] 32079#32079: pthread_create() failed (11: Resource temporarily unavailable) 2015/06/30 04:14:07 [alert] 32076#32076: worker process 17232 exited with fatal code 2 and cannot be respawned 2015/06/30 04:14:07 [alert] 32076#32076: worker process 18584 exited with fatal code 2 and cannot be respawned 2015/06/30 04:14:07 [alert] 32076#32076: worker process 595 exited with fatal code 2 and cannot be respawned 2015/06/30 04:14:07 [alert] 32076#32076: worker process 32121 exited with fatal code 2 and cannot be respawned 2015/06/30 04:14:07 [alert] 32076#32076: worker process 7557 exited with fatal code 2 and cannot be respawned 2015/06/30 04:14:07 [alert] 32076#32076: worker process 16852 exited with fatal code 2 and cannot be respawned 2015/06/30 04:14:07 [alert] 32076#32076: worker process 32083 exited with fatal code 2 and cannot be respawned 2015/06/30 04:14:07 [alert] 32076#32076: worker process 5933 exited with fatal code 2 and cannot be respawned 2015/06/30 04:14:07 [alert] 32076#32076: worker process 32079 exited with fatal code 2 and cannot be respawned 2015/06/30 04:14:03 [alert] 25360#25360: pthread_create() failed (11: Resource temporarily unavailable) 2015/06/30 04:14:03 [alert] 18540#18540: pthread_create() failed (11: Resource temporarily unavailable) 2015/06/30 04:14:03 [alert] 11093#11093: pthread_create() failed (11: Resource temporarily unavailable) 2015/06/30 04:14:03 [alert] 23953#23953: pthread_create() failed (11: Resource temporarily unavailable) Thanks in advance. Regards. Shahzaib ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Serving from cache even when the origin server goes down
Is it possible to configure Nginx to serve from cache even when the origin server is not accessible? I am trying to figure out if I can use a replicated Nginx instance that has cache files rsynced (lsyncd http://t.sidekickopen03.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XYg1qwrMlW63Bdqv8rBw8YW4XXPpC56dBXDf1zVF0j02?t=https%3A%2F%2Fcode.google.com%2Fp%2Flsyncd%2Fsi=6435350837723136pi=2518a249-a8f4-4dd6-9e96-783723ac8e1a) from the primary instance and serve from the replicated instance (DNS switch) if the primary goes down. - Cherian ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Serving from cache even when the origin server goes down
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_use_stale You can use multiple values e.g. the below is probably a good start: proxy_cache_use_stale error timeout invalid_header updating; Cherian Thomas mailto:cherian...@gmail.com 30 Jun 2015 03:27 Is it possible to configure Nginx to serve from cache even when the origin server is not accessible? I am trying to figure out if I can use a replicated Nginx instance that has cache files rsynced (lsyncd http://t.sidekickopen03.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XYg1qwrMlW63Bdqv8rBw8YW4XXPpC56dBXDf1zVF0j02?t=https%3A%2F%2Fcode.google.com%2Fp%2Flsyncd%2Fsi=6435350837723136pi=2518a249-a8f4-4dd6-9e96-783723ac8e1a) from the primary instance and serve from the replicated instance (DNS switch) if the primary goes down. - Cherian ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
