> On 2014-11-12 07:45, Roberto De Ioris wrote:
>
>> I tried hard, but i was not able to reproduce it (ubuntu trusty 64bit
>> default perl).
>
> Well... I've switched to trusty too (and ran apt-get dist-upgrade, just
> in case), to check if this is a perl issue, and I still can reproduce
> it.
>
> Results (without writing to stream):
>
> After 1st request:
>
> {address space usage: 66813952 bytes/63MB} {rss usage: 8884224
> bytes/8MB} [pid: 13449|app: 0|req: 1/1] 127.0.0.1 () {24 vars in 247
> bytes}
>
> After 100000 requests:
>
> {address space usage: 76546048 bytes/73MB} {rss usage: 18571264
> bytes/17MB} [pid: 13449|app: 0|req: 100001/100001] 127.0.0.1 () {24 vars
> in 251 bytes}
>
> And another 100000 requests:
>
> {address space usage: 86142976 bytes/82MB} {rss usage: 28270592
> bytes/26MB} [pid: 13449|app: 0|req: 200001/200001] 127.0.0.1 () {24 vars
> in 251 bytes}
>
> As you can see, it is definitely growing.
>
> valgrind (valgrind --log-file=0vg --leak-check=full
> --show-leak-kinds=all --) reveals this (after 100000 requests):
>
> ....
> ==13832== 2,411,280 bytes in 591 blocks are still reachable in loss
> record 2,311 of 2,313
> ==13832== at 0x4C2AB80: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==13832== by 0x67AE864: Perl_safesysmalloc (in
> /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x67D4DCD: ??? (in /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x67D57C4: Perl_sv_newmortal (in
> /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x48137E: XS_stream (psgi_loader.c:86)
> ==13832== by 0x67D3865: Perl_pp_entersub (in
> /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x67CBE85: Perl_runops_standard (in
> /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x675D48F: Perl_call_sv (in /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x489150: uwsgi_perl_call_stream (psgi_plugin.c:169)
> ==13832== by 0x48CFA5: uwsgi_perl_request (psgi_plugin.c:576)
> ==13832== by 0x41B801: wsgi_req_recv (utils.c:1427)
> ==13832== by 0x462C73: simple_loop_run (loop.c:144)
> ==13832==
> ==13832== 2,415,360 bytes in 592 blocks are still reachable in loss
> record 2,312 of 2,313
> ==13832== at 0x4C2AB80: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==13832== by 0x67AE864: Perl_safesysmalloc (in
> /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x67D4DCD: ??? (in /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x67DC720: Perl_newSV_type (in
> /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x67DC73D: Perl_newRV_noinc (in
> /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x481397: XS_stream (psgi_loader.c:86)
> ==13832== by 0x67D3865: Perl_pp_entersub (in
> /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x67CBE85: Perl_runops_standard (in
> /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x675D48F: Perl_call_sv (in /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x489150: uwsgi_perl_call_stream (psgi_plugin.c:169)
> ==13832== by 0x48CFA5: uwsgi_perl_request (psgi_plugin.c:576)
> ==13832== by 0x41B801: wsgi_req_recv (utils.c:1427)
> ==13832==
> ==13832== 4,798,080 bytes in 1,176 blocks are still reachable in loss
> record 2,313 of 2,313
> ==13832== at 0x4C2AB80: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==13832== by 0x67AE864: Perl_safesysmalloc (in
> /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x67D5216: Perl_more_bodies (in
> /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x67DC3C6: Perl_sv_upgrade (in
> /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x67E5E7F: Perl_sv_bless (in /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x4813B3: XS_stream (psgi_loader.c:86)
> ==13832== by 0x67D3865: Perl_pp_entersub (in
> /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x67CBE85: Perl_runops_standard (in
> /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x675D48F: Perl_call_sv (in /usr/lib/libperl.so.5.18.2)
> ==13832== by 0x489150: uwsgi_perl_call_stream (psgi_plugin.c:169)
> ==13832== by 0x48CFA5: uwsgi_perl_request (psgi_plugin.c:576)
> ==13832== by 0x41B801: wsgi_req_recv (utils.c:1427)
>
> Without streaming everything is fine (expectable). Just in case, I've
> tried 2.0.1 and 2.0.5 - similar results.
>
> It does not look like it has something to do with perl itself (5.16.1 in
> CentOS and 5.18.2 in trusty).
>
> The only thing in common between those two systems (CentOS 7 & Trusty)
> is that both are running in Proxmox/openvz, but I doubt that this has
> (or could have) any impact, especially after looking at valgrind
> results.
>
> Additional info:
>
> ################# uWSGI configuration #################
>
> pcre = True
> kernel = Linux
> malloc = libc
> execinfo = False
> ifaddrs = True
> ssl = True
> zlib = True
> locking = pthread_mutex
> plugin_dir = .
> timer = timerfd
> yaml = embedded
> json = False
> filemonitor = inotify
> routing = True
> debug = False
> capabilities = False
> xml = libxml2
> event = epoll
>
> ############## end of uWSGI configuration #############
>
> *** Starting uWSGI 2.0.8 (64bit) on [Thu Nov 13 06:57:27 2014] ***
> compiled with version: 4.8.2 on 13 November 2014 06:54:03
> os: Linux-2.6.32-33-pve #1 SMP Fri Sep 26 08:02:30 CEST 2014
> nodename: u1404
> machine: x86_64
> clock source: unix
> pcre jit disabled
> detected number of CPU cores: 2
> current working directory: /home/aldem/src/perl
> detected binary path: /home/aldem/src/uwsgi/uwsgi-2.0.8/uwsgi
> *** WARNING: you are running uWSGI without its master process manager
> ***
> your processes number limit is 127542
> your memory page size is 4096 bytes
> detected max file descriptor number: 1024
> lock engine: pthread robust mutexes
> thunder lock: disabled (you can enable it with --thunder-lock)
> uwsgi socket 0 bound to TCP address :9090 fd 3
> initialized Perl 5.18.2 main interpreter at 0x1682b30
> your server socket listen backlog is limited to 100 connections
> your mercy for graceful operations on workers is 60 seconds
> mapped 72768 bytes (71 KB) for 1 cores
> *** Operational MODE: single process ***
> Plack::Util is not installed, using "do" instead of "load_psgi"
> 2014-11-13 06:57:27.0.240637 [14603] Worker started
> PSGI app 0 (psgi-streamer.pl) loaded in 0 seconds at 0x18583e8
> (interpreter 0x1682b30)
> *** uWSGI is running in multiple interpreter mode ***
> spawned uWSGI worker 1 (and the only) (pid: 14603, cores: 1)
>
> Regards,
> Alexander.
>
> _______________________________________________
> uWSGI mailing list
> [email protected]
> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
>
Can you run with --show-config and paste the output ?
I have tried with every combination, so i must be missing something
--
Roberto De Ioris
http://unbit.it
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
