<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 20, 2013 at 9:12 AM, Lasse Karstensen <span dir="ltr"><<a href="mailto:lkarsten@varnish-software.com" target="_blank">lkarsten@varnish-software.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Mar 19, 2013 at 09:46:37PM -0400, Sean Allen wrote:<br>
> One of our varrnish servers is spending about 40-50% of its time in iowait.<br>
> Is this just from the varnishlog getting written? Our IO performance is not<br>
> great and I'm looking to be able to get the amount of time we are spending<br>
> doing IO down. This occurs even when everything is running nicely in memory<br>
> and we aren't overflowing into swap ( which was detailed in a different<br>
> email as I think they might be different issues ).<br>
> varnishd (varnish-3.0.3 revision 9e6a70f)<br>
</div>[..]<br>
<div class="im">> # Without "ban_lurker_sleep," nothing banned from the cache ever gets<br>
> evicted.<br>
<br>
</div>Ban lurker default sleep is 10ms in 3.0.3. You are increasing it a lot, why?<br>
<br></blockquote><div style><br></div><div style>Lack of knowledge when we put it together about what would be good.</div><div style>My understanding is the less frequently that runs the more memory that would be used</div>
<div style>but performance would be slightly better. Is that incorrect?</div><div style><br></div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Are you using smart bans?<br>
<br>
        <a href="https://www.varnish-software.com/static/book/Cache_invalidation.html#smart-bans" target="_blank">https://www.varnish-software.com/static/book/Cache_invalidation.html#smart-bans</a></blockquote><div><br></div>
<div style>A combination of smart bans and purges.</div><div style><br></div><div style>Any invalidation that comes from the backend is handled via a smart ban. There is legacy code</div><div style>that causes db updates that would send a purge via port 6081 to invalidate entities that were</div>
<div style>updated 'out of band'.</div><div style><br></div><div style>The vast majority come via the 'out of band' purges.</div><div style><br></div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<div class="im"><br>
> DAEMON_OPTS="-a :6081 \<br>
>              -T :6082 \<br>
>              -f /etc/varnish/default.vcl \<br>
>              -u varnish -g varnish \<br>
>              -p thread_pool_min=500 \<br>
>              -p thread_pool_max=5000 \<br>
>              -s malloc,6G \<br>
>              -p thread_pools=2 \<br>
>              -p thread_pool_add_delay=1 \<br>
>              -p ban_lurker_sleep=60s"<br>
<br>
</div>Your thread count is a bit on the high side (10k); ~1 thread / concurrent connection is good.<br></blockquote><div><br></div><div style>So workers created says 1000. Nothing ever gets queued. On this varnish we dont get to 1000 concurrent.</div>
<div style>On another we regularly bounce up 3k concurrent connections but the workers stays at 1000.</div><div style><br></div><div style>From the documentation, Ive never been entirely clear about how the thread pool sizes work.</div>
<div style><br></div><div style>I would have thought that as our 1 second rate for connections was 3k, we would create more workers.</div><div style>Would this be requests finishing in less than 1 second so 1000 workers can handle the 3k without queueing?</div>
<div style>If they were going to queue, we would start to spin up more workers yes?</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But it doesn't explain why you are in iowait.<br>
Is this running on a virtualised server? Do you have proper network drivers?<br></blockquote><div><br></div><div style>VMWare on Centos 5.x</div><div style>Drivers are good.</div><div style><br></div><div style>I'm hoping that virtualized isn't the culprit but I won't be surprised if it is.</div>
<div style><br></div><div style>Thanks,</div><div style>Sean</div><div style><br></div></div>
</div></div>