On 24-1-2010 20:31, Michael S. Fischer wrote:
The other most common reason why the varnish supervisor can start
killing off children is when they are blocked waiting on a page-in,
which is usually due to VM overcommit (i.e., storage file size
significantly exceeds RAM and you have a very
In message 4b5d70b5.5080...@netmatch.nl, =?ISO-8859-1?Q?Angelo_H=F6ngens?= wr
ites:
How are your disks configured ?
2 cheap SATA disks in a gmirror (it's a simple Dell R300).
Hmm, that's going to hurt obviously...
You would probably have been better off, not mirroring and giving
Varnish a
On 25-1-2010 11:24, Poul-Henning Kamp wrote:
In message 4b5d70b5.5080...@netmatch.nl, =?ISO-8859-1?Q?Angelo_H=F6ngens?=
wr
ites:
How are your disks configured ?
2 cheap SATA disks in a gmirror (it's a simple Dell R300).
Hmm, that's going to hurt obviously...
You would probably have
On 23-1-2010 20:57, Michael Fischer wrote:
On Sat, Jan 23, 2010 at 2:20 AM, Angelo Höngens a.hong...@netmatch.nl
mailto:a.hong...@netmatch.nl wrote:
(second try, I found out I was subscribed using a wrong email address)
Hey,
I am having some problems with Varnish.
On Jan 24, 2010, at 7:23 AM, Angelo Höngens wrote:
What is thread_pool_max set to? Have you tried lowering it? We have
found that on systems with very high cache-hit ratios, 16 threads per
CPU is the sweet spot to avoid context-switch saturation.
[ang...@nmt-nlb-03 ~]$ varnishadm -T
On Jan 24, 2010, at 10:40 AM, Angelo Höngens wrote:
According to top, the CPU usage for the varnishd process is 0.0% at 400
req/sec. The load over the past 15 minutes is 0.45, probably mostly
because of haproxy running on the same machine. So I don't think load is
a problem.. My problem is
In message 4b5ad8b0.6090...@netmatch.nl, =?ISO-8859-1?Q?Angelo_H=F6ngens?= wr
ites:
By the way: the balancers do a total of 2000 req/sec now, but when
stresstesting I can easily get 9000 cache/hits persec. So I don't think
it's hanging on the upper limits of its performance.
At that level of
you need to write start after starting varnishd in debug mode.
janis
a satisfied Varnishd user :)
On Thursday 22 November 2007 12:18, Erik wrote:
Hi again,
I made some logging of the memory and it looks fine. I also turned of VCL
Trace but that didn't solved it. The crash happened again
Hi,
This is what I do and what I get:
/etc/init.d/varnish start
Starting Varnish: varnishUsing old SHMFILE
rolling(2)...
It seems to me that the varnish is running? But when
trying to connect it doesn't work! Althought when I run
without -d -d or -d it works!
I would really like to commit some
Hi,
Varnish crashes everyday, same time. This is what I got from the log files:
12 SessionOpen c xx.xx.xx.xx 31989
0 Debug Acceptor is epoll
0 Error CLI read 0 (errno=32)
I also found this thread in the mailing archive from July:
http://projects.linpro.no/pipermail
10 matches
Mail list logo
