disable sendfile in Varnish, please

Eirik Øverby ltning at anduin.net
Mon Dec 10 20:00:08 CET 2007

On Dec 10, 2007, at 17:17, Poul-Henning Kamp wrote:

> In message <EEF3518D-EA59-4B21-9CB0-D3F71075E8DA at anduin.net>, =? 
> ISO-8859-1?Q?Ei
> rik_=D8verby?= writes:
>> Hi,
>> is this still a problem?
> Yes, sendfile is not currently usable because it does not tell
> us when it is _really_ done with the data we send, so it can
> run afoul of our reuse of the memory for short lived objects.

Thanks. What's the likelihood that the error I saw today is in fact  
caused by this weakness in the sendfile implementation, and that  
Varnish has triggered it? In other words; now that I disabled it as  
suggested, how surprised should I be to see a similiar error again?


> I have not spent any time on it, as the performance hit from
> using writev(2) seems to be trivial if one has plenty of RAM
> and because the real fix for the sendfile issue is likely
> to mean a redefinition of the sendfile system call.
> Poul-Henning
>>> I've nailed three different operating system kernels as having
>>> sendfile(2) issues today, so I would advice all of you to
>>> disable sendfile to avoid the various problems we've seen.
>>> The easiest way is to specify
>>> 	-p sendfile_threshold=-1
>>> to varnishd, or by using the CLI:
>>> 	param.set sendfile_threshold -1
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by  
> incompetence.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20071210/3a472b7b/attachment-0001.html>

More information about the varnish-misc mailing list