nginx Digest, Vol 113, Issue 33
村长
u_can at 163.com
Tue Mar 26 13:09:27 UTC 2019
Thanks!
I builded the nginx-1.14.2 from the source instead of apt package(Debian9), then it goes well(with the same config file).
And on FreeBSD, it has no problem with same version of nginx than Debian9.
And I migrated the path to a single directory.
潘永华
手机: 13166322138
邮箱: u_can at 163.com
网站: http://www.panswork.com
在2019年03月26 17时47分, "nginx-request"<nginx-request at nginx.org>写道:
Send nginx mailing list submissions to
nginx at nginx.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.nginx.org/mailman/listinfo/nginx
or, via email, send a message with subject or body 'help' to
nginx-request at nginx.org
You can reach the person managing the list at
nginx-owner at nginx.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of nginx digest..."
Today's Topics:
1. Re: Possible memory leak? (Maxim Dounin)
2. Re: a proxy_module question ,maybe a bug? (Maxim Dounin)
3. Re: Mapping url to physical urls using lua script or
something else. (Hemant Bist)
4. TCP connection limit on dynamic backend (R, Rajkumar (Raj))
5. Is it possible to add milliseconds in error.log and also
timestamps (sivak)
----------------------------------------------------------------------
Message: 1
Date: Mon, 25 Mar 2019 15:39:49 +0300
From: Maxim Dounin <mdounin at mdounin.ru>
To: nginx at nginx.org
Subject: Re: Possible memory leak?
Message-ID: <20190325123949.GU1877 at mdounin.ru>
Content-Type: text/plain; charset=us-ascii
Hello!
On Thu, Mar 21, 2019 at 05:55:23PM -0400, wkbrad wrote:
> Thanks again! I was a little confused at first because your tests in
> freebsd were so much different than mine but then I found what you did
> wrong.
>
> You were testing the 2nd reload but the issue can only be seen on the first
> reload. Here is my test to show what I mean.
As can be seen from the pid numbers provided, first ps/top output
in my previous message is from the initial nginx start, and the
reload shown is the first one.
What looks like an important factor is "junk:true" in my
malloc.conf. Without at least "junk:free" I indeed see similar
results to yours - most likely because kernel fails to free pages
which are referenced from multiple processes when madvise() is
called.
[...]
--
Maxim Dounin
http://mdounin.ru/
------------------------------
Message: 2
Date: Mon, 25 Mar 2019 16:26:23 +0300
From: Maxim Dounin <mdounin at mdounin.ru>
To: nginx at nginx.org
Subject: Re: a proxy_module question ,maybe a bug?
Message-ID: <20190325132622.GV1877 at mdounin.ru>
Content-Type: text/plain; charset=utf-8
Hello!
On Sat, Mar 23, 2019 at 12:20:26AM +0800, ?? wrote:
> nginx version: nginx/1.10.3
> uname: Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux
> VPS: Linode $5
>
>
>
> I set about 900 subsite like this:
>
>
> proxy_cache_path /var/cache/nginx/abc.com/aaa levels=1:2 use_temp_path=off keys_zone=aaa.abc.com:64k inactive=8h max_size=128m;
> proxy_cache_path /var/cache/nginx/abc.com/bbb levels=1:2 use_temp_path=off keys_zone=bbb.abc.com:64k inactive=8h max_size=128m;
> ...
> the list is 900+
Just a side note: it is usually a bad idea to configure individual
cache paths for each site, as it consumes much more resources than
using a single cache for all sites. Instead, consider using a
single proxy_cache_path and add site identifier to
proxy_cache_key.
[...]
> but when I type run it again at once, the nginx will go wrong in minutes:
>
>
> 2019/03/22 10:30:03 [alert] 6356#6356: ignore long locked inactive cache entry 3391b383577454e8dfb6337e060c1d22, count:1
> 2019/03/22 10:30:03 [alert] 6356#6356: ignore long locked inactive cache entry 3391b383577454e8dfb6337e060c1d22, count:1
The "ignore long locked inactive cache entry" alert indicates that
nginx was trying to remove a cache entry, but failed to do this
because the entry was locked. This may be either result of a bug,
or may happen if a worker process is killed or crashed. That is,
this may happen, e.g., if your server run out of memory at some
point and OOM-killer killed an nginx worker process. To find out
what actually happened you may want to investigate error log
before the first "ignore long locked" alert.
On the other hand, the first thing you may want to do is to
upgrade - nginx 1.10.3 is rather old and no longer supported.
Invesigating anything with nginx 1.10.3 hadly make sense.
[...]
--
Maxim Dounin
http://mdounin.ru/
------------------------------
Message: 3
Date: Mon, 25 Mar 2019 09:39:15 -0700
From: Hemant Bist <hemantbist at gmail.com>
To: nginx at nginx.org
Subject: Re: Mapping url to physical urls using lua script or
something else.
Message-ID:
<CAHgSXQnaTFp-BxW1PZ0Q-6F3yZ85pyHneUBRrg_7vKvdZHN+gw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks peter,
In this case, both the new set of urls and old set of url are going to be
exposed to different set of users. (And there are some DRM related details
I omitted in the email)
(similar to what you are suggesting ) : One of the changes I am testing is
simply copying the files/linking the files( which means serving tiles via
nginx would be trivial , at the cost of increasing memory / complications
in the backend scripts that sync the data).
1) Computationally the mapping is not that hard, and the production server
is has lot of CPU. So I am hoping that we can get away with some sort of
simple lua script.
2) Additionally it looks like a small percentage of the urls(both number
and traffic wise) are served by lookup on a small redis db, and lua. So no
major changes would be required in installation etc : as long as it scales
decently...
HB
HB
On Sat, Mar 23, 2019 at 7:39 PM Peter Booth via nginx <nginx at nginx.org>
wrote:
> Here?s my opinion:
>
> You can do this however you want. It?s your website. Most of my work has
> been for other people. When I was working on my own startup it made me
> honest. Nothing was dynamic. The rationale was ?do everything ahead of
> time so users never wait for anything and the site has 100% uptime?.
>
> So for your usecase - why make your users pay the price of your hashmap
> lookup? Why not publish/rewrite your content to the ?right? site structure
> ahead of time? Sure, nginx with openresty / lua can be a super fast
> appserver. But boring solutions beat clever every time.
>
> My two cents,
>
> Peter
>
> Sent from my iPhone
>
> > On Mar 23, 2019, at 8:17 PM, Hemant Bist <hemantbist at gmail.com> wrote:
> >
> > Hi,
> > I want to know if this a right way to make the change ( or if there is a
> better /recommended method). So far we have only tweaked the configuration
> of nginx which scales very nicely for us The change I need to do looks
> like a common case to me.
> >
> > Currently our urls map directly to the local dir structure
> > e.g. the url /foo/10000/1234/9999/my.jpg is local file
> /var/www/html/foo/10000/1234/9999/my.jpg so
> >
> > Now the url /foo/first/second/third/my.jpg will map to
> /newfoo/new_first/new_second/new_third/my.jpg
> > where newfoo folder is done by lookup of a static Hash_map/table of
> about 10000 to 20000 entries.
> > new_first (new_second and new_third) are calculated by some arithmatic
> operation on first(second and new third).
> >
> > My plan is: a) pass all handling to a lua script that will do
> internal_redirect to the correct physical url... And do a load test to make
> sure that is not too much performance hit. [ I haven't implemented it, but
> it looks possible from the examples I have looked at so far]
> >
> > Best,
> > HB
> >
> >
> > _______________________________________________
> > nginx mailing list
> > nginx at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20190325/f4146dd0/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 26 Mar 2019 09:13:44 +0000
From: "R, Rajkumar (Raj)" <rajkumaradass at avaya.com>
To: "nginx at nginx.org" <nginx at nginx.org>
Subject: TCP connection limit on dynamic backend
Message-ID:
<MN2PR15MB318137AFE176F967DB36AAF0A65F0 at MN2PR15MB3181.namprd15.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi,
Using nginx in TCP/Stream mode and would like to limit the number of active connection to my backend server whereas the backend is resolved dynamically based on the SNI header ($ssl_preread_server_name). But this does not allow any connections to the backend with below config. I see examples of limiting backend connections if the backend server block is pre configured.
Could you please confirm if this achievable or supported currently with Stream mode?
Below is the related config part.
map $ssl_preread_server_name $backend_svr {
~^(\w+).test.com $1-tcp.default.svc.cluster.local;
}
limit_conn_zone $ssl_preread_server_name zone=perserver:10m;
server {
listen 443 reuseport so_keepalive=30s:30s:3 backlog=64999;
proxy_pass $backend_svr:443;
limit_conn perserver 255;
ssl_preread on;
}
thanks,
raj
+918067153382
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20190326/415cd5b3/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 26 Mar 2019 05:47:51 -0400
From: "sivak" <nginx-forum at forum.nginx.org>
To: nginx at nginx.org
Subject: Is it possible to add milliseconds in error.log and also
timestamps
Message-ID:
<15d1757b0ed2bcc2de430d9f3a7b3a67.NginxMailingListEnglish at forum.nginx.org>
Content-Type: text/plain; charset=UTF-8
Is it possible to add milliseconds in error.log and also to include
timestamps in the output after executing below commands
$NGINX_EXECUTABLE_FILE -I
$NGINX_EXECUTABLE_FILE -P
Posted at Nginx Forum: https://forum.nginx.org/read.php?2,283506,283506#msg-283506
------------------------------
Subject: Digest Footer
_______________________________________________
nginx mailing list
nginx at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
------------------------------
End of nginx Digest, Vol 113, Issue 33
**************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20190326/fa5f128b/attachment-0001.html>
More information about the nginx
mailing list