Bug #1663
closedMem Leak: 1.4.19-0ubuntu3 + torrentflux + php5 + download as zip on Ubuntu 8.04
Description
I am running Fresh Ubuntu Linux 8.04 install with the packaged lighttpd version and torrentflux_2.3.tar.gz. I am not 100% sure if I am using fastcgi or normal cgi since both are enabled. I suspect normal CGI ( let me know the easy way to tell if it's important).
Noticed a memory problem on the box after I used the "download as a zip" function in torrentflux. Memory usage of lighttpd increases by roughly the size of the file and doesn't decrease afterwards. Further downloads keep increasing file size.
To duplicate:
Install Ubuntu Server 8.04
Install Torrentflux version above ( using mysql backend but probably important)
Config bits:
server.modules = ("mod_access",
"mod_alias",
"mod_accesslog",
"mod_compress",
"mod_rewrite",
"mod_redirect",
- "mod_status",
- "mod_evhost",
- "mod_usertrack",
- "mod_rrdtool",
- "mod_webdav",
- "mod_expire",
- "mod_flv_streaming",
- "mod_evasive"
)
- .php, .pl, .fcgi are most often handled by mod_fastcgi or mod_cgi
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" , ".cgi" )
- compress module
compress.cache-dir = "/var/cache/lighttpd/compress/"
compress.filetype = ("text/plain", "text/html", "application/x-javascript", "text/css")
Modules:
cgi, fastcgi , simple-vhost
In torrentflux:
- Add a user (just the initual one will do)
- Using you shell account create a directory with some largish (megabytes) files in it in the users download directory ( /www//torrentflux/downloads/ )
- Navigate to users home directory in torrentflux
- Use the yellow "download as zip" button in torrentflux on this directory
Watch memory usage as file downloads and afterwards.
I grabbed strace and valgrind memleaks stuff. I'll emailURLs for these to Jan
-- Simon Lyall
Updated by hoffie over 16 years ago
It's not a real memory leak as the memory does not get lost (it is re-used later). It's a design problem in 1.4 which cannot be fixed easily, don't expect 1.4 to be ever fixed.
Updated by Anonymous over 16 years ago
Replying to hoffie:
It's not a real memory leak as the memory does not get lost (it is re-used later). It's a design problem in 1.4 which cannot be fixed easily, don't expect 1.4 to be ever fixed.
This afternoon I had lighttpd using 1GB on a machine with just 512MB of RAM :(
-- Simon Lyall
Updated by hoffie over 16 years ago
Well, that happens if you send huge files (or multiple "small" files concurrently) over *cgi. The proper way is to use X-Sendfile, *cgi was never designed to allow for such tasks. And well, lighty just happens to handle this case not as gracefully as other servers might do.
Updated by admin over 16 years ago
Replying to hoffie:
The proper way is to use X-Sendfile,
That only works for files that exist already in the filesystem.
*cgi was never designed to allow for such tasks. And well, lighty just happens to handle this case not as gracefully as other servers might do.
You mean Lighttpd's implementation wasn't designed for cases like this?
Updated by stbuehler over 16 years ago
- Status changed from New to Fixed
- Resolution set to duplicate
No real memleak, known problem. And won't fix in 1.4.
Also available in: Atom