> My WSGI application occassionally serves up multiple gigabyte files,
> however transmission is getting cut short right on the edge of the 2GB
> mark. I'm using Ubuntu 11.10 packages. Is this expected behavior? I'm
> hoping not, as uWSGI has behaved better than any other server I've tried
> so far, except for cutting off the output.
>
> Kind regards,
> -Charlie
>
> Curl outputs:
>   % Total    % Received % Xferd  Average Speed   Time    Time     Time
> Current
>                                  Dload  Upload   Total   Spent    Left
> Speed
>  23 8708M   23 2047M    0     0   129M      0  0:01:07  0:00:15  0:00:52
> 130M
> curl: (18) transfer closed with 6983579892 bytes remaining to read
>
> uWSGI output:
>
> *** Starting uWSGI 0.9.8.1-debian (64bit) on [Mon Aug  6 21:40:04 2012]
> ***
> compiled with version: 4.6.1 on 28 June 2011 10:48:13
>  *** WARNING: you are running uWSGI without its master process manager ***
> your memory page size is 4096 bytes
> spawned uWSGI http 1 (pid: 25610)
> HTTP router/proxy bound on 127.0.0.1:6665
> uwsgi socket 0 bound to UNIX address 1344314404_25610.sock fd 4
> Python version: 2.7.2+ (default, Oct  4 2011, 20:41:12)  [GCC 4.6.1]
> Python main interpreter initialized at 0x1a909e0
> your server socket listen backlog is limited to 100 connections
> *** Operational MODE: preforking ***
> WSGI application 0 (SCRIPT_NAME=) ready on interpreter 0x1a909e0 pid:
> 25611 (default app)
> *** uWSGI is running in multiple interpreter mode ***
> spawned uWSGI worker 1 (pid: 25611, cores: 1)
> spawned uWSGI worker 2 (pid: 25612, cores: 1)
> spawned uWSGI worker 3 (pid: 25613, cores: 1)
> spawned uWSGI worker 4 (pid: 25614, cores: 1)
> spawned uWSGI worker 5 (pid: 25615, cores: 1)
> spawned uWSGI worker 6 (pid: 25616, cores: 1)
> spawned uWSGI worker 7 (pid: 25617, cores: 1)
> spawned uWSGI worker 8 (pid: 25618, cores: 1)
> [pid: 25611|app: 0|req: 1/1] 127.0.0.1 () {26 vars in 573 bytes} [Mon Aug
> 6 21:40:06 2012] GET /censored-file-name => generated 2147479552 bytes in
> 15774 msecs via sendfile() (HTTP/1.1 200) 2 headers in 87 bytes (0
> switches on core 0)
>

Can you try with a stable/recent uWSGI release ? sendfile support was
rewritten before 1.0, so i suspect it may be the problem here.

sendfile() is 64bit friendly so you should not have problems from a kernel
point of view.

-- 
Roberto De Ioris
http://unbit.it
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to