disable sendfile in Varnish, please

[Eirik Øverby]

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?

/Eirik



> 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>