Re: NGX_POOL_ALIGNMENT
Hello! On Tue, Sep 26, 2017 at 11:33:50AM +0300, Oleg wrote: > On Mon, Sep 25, 2017 at 02:44:47PM +0300, Maxim Dounin wrote: > > > > Абсолютно. Ну то есть это, безусловно, зависит от многих > > факторов, но на Линуксе со штатным аллокатором на 64-битных > > платформах - будет 16: > > > > https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html > > > > : The address of a block returned by malloc or realloc in GNU > > : systems is always a multiple of eight (or sixteen on 64-bit > > : systems). > > Спасибо за ссылку. Похоже man для memalign забыли поправить для > 64-битных процессоров. > Для общего понимания, если отвлечься от конкретно ngx_pool, > выравнивания в 8 байт для целых типов(кроме float, double и прочих > SSE/AVX) достаточно для быстрого доступа? > Например, мы выделяем большой кусок памяти и в нём уже выделяем куски > поменьше под всякие char* и выравниваем их на границы 8 байт. Для переменных простых типов - выравнивания на 8 байт AFAIK достаточно, чтобы процессор работал быстро (если не брать в расчёт SIMD-инструкции). Дальше могут начинаться всякие нюансы, например, с cacheline size: e.g., если мы работаем со структурой в 64 байта размером, и cacheline size у нас 64, то выравнивать лучше на те же 64 - тогда вся структура будет загружаться в кеш процессора сразу. Если же выравнивать на 8, то одна структура с высокой вероятностью разъедется по двум строкам кеша, и соответственно работать это будет медленнее, чем могло бы. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Очень медленный ответ после нескольких быстрых ответов
Hello! On Tue, Sep 26, 2017 at 04:07:34AM -0400, EugeneNF wrote: > Тут-то и возникает противоречие - как приложению узнать, что второй запрос > блокирован поскольку nginx ждёт окончания первого запроса? Тут у вас фактическая ошибка на входе, на которой вы строите свои рассуждения, и получаете мусор на выходе. Нет никакого "второй запрос блокирован поскольку nginx ждёт окончания первого запроса". С точки зрения nginx'а - запросы независимы, и nginx просто передаёт их туда, куда указывает конфигурация. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: NGX_POOL_ALIGNMENT
On Mon, Sep 25, 2017 at 02:44:47PM +0300, Maxim Dounin wrote: > > Абсолютно. Ну то есть это, безусловно, зависит от многих > факторов, но на Линуксе со штатным аллокатором на 64-битных > платформах - будет 16: > > https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html > > : The address of a block returned by malloc or realloc in GNU > : systems is always a multiple of eight (or sixteen on 64-bit > : systems). Спасибо за ссылку. Похоже man для memalign забыли поправить для 64-битных процессоров. Для общего понимания, если отвлечься от конкретно ngx_pool, выравнивания в 8 байт для целых типов(кроме float, double и прочих SSE/AVX) достаточно для быстрого доступа? Например, мы выделяем большой кусок памяти и в нём уже выделяем куски поменьше под всякие char* и выравниваем их на границы 8 байт. -- Олег Неманов (Oleg Nemanov) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Очень медленный ответ после нескольких быстрых ответов
On Tue, Sep 26, 2017 at 04:07:34AM -0400, EugeneNF wrote: > Тут-то и возникает противоречие - как приложению узнать, что второй запрос > блокирован поскольку nginx ждёт окончания первого запроса? Решение видится > в два этапа - первое nginx просто обрывает первый запрос. Каким образом? Вместо абстрактных фантазий лучше напишите конкретно что значит "обрывает запрос" -- какие системные вызовы используются, что отправляется клиенту, что серверу приложений? Почему вы думаете, что сервер приложений чего-то ждёт от апстрима, чтобы срочно прервать свою работу? А если не ждёт, то как он узнает, что запрос нужно прекратить обрабатывать? > А приложение уже решает, что же делать при потере связи с клиентом, Как оно узнает о потере связи? Конкретный механизм, pls. Какие вызовы, какие пакеты пересылаются, какие сигналы/ошибки/etc получает процесс. > т.е. заканчивает работу > с закрытием всего открытого - файлов, баз данных и т.д. А если базе отправлен запрос, который она будет молотить долгое время, как его прервать? Это точно такая же проблема, которая возникает при взаимодействии сервера приложений и nginx, между которыми нет никакой асинхронной коммуникации. -- Eugene Berdnikov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Очень медленный ответ после нескольких быстрых ответов
Тут-то и возникает противоречие - как приложению узнать, что второй запрос блокирован поскольку nginx ждёт окончания первого запроса? Решение видится в два этапа - первое nginx просто обрывает первый запрос. А приложение уже решает, что же делать при потере связи с клиентом, т.е. заканчивает работу с закрытием всего открытого - файлов, баз данных и т.д. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,276486,276538#msg-276538 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
