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 邮箱: [email protected] 网站: http://www.panswork.com 在2019年03月26 17时47分, "nginx-request"<[email protected]>写道: Send nginx mailing list submissions to [email protected] 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 [email protected] You can reach the person managing the list at [email protected] 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 <[email protected]> To: [email protected] Subject: Re: Possible memory leak? Message-ID: <[email protected]> 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 <[email protected]> To: [email protected] Subject: Re: a proxy_module question ,maybe a bug? Message-ID: <[email protected]> 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 <[email protected]> To: [email protected] Subject: Re: Mapping url to physical urls using lua script or something else. Message-ID: <cahgsxqnatfp-bxw1pz0q-6f3yz85pyhneubrrg_7vkvdzhn...@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 <[email protected]> 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 <[email protected]> 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 > > [email protected] > > http://mailman.nginx.org/mailman/listinfo/nginx > > _______________________________________________ > nginx mailing list > [email protected] > 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)" <[email protected]> To: "[email protected]" <[email protected]> Subject: TCP connection limit on dynamic backend Message-ID: <mn2pr15mb318137afe176f967db36aaf0a6...@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" <[email protected]> To: [email protected] Subject: Is it possible to add milliseconds in error.log and also timestamps Message-ID: <15d1757b0ed2bcc2de430d9f3a7b3a67.nginxmailinglistengl...@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 [email protected] http://mailman.nginx.org/mailman/listinfo/nginx ------------------------------ End of nginx Digest, Vol 113, Issue 33 **************************************
_______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
