Yesterday I was at the Milan VARNISH 3.0 Release Party hosted by ZephirWorks to make a “lightning talk” version of my “Varnish e caching di applicazioni Rails” talk I gave at the last RubyDay.
It was very interesting follow the lightning talks because they gave me new ideas on how to integrate Varnish in the application architecture not only to be the “http accelerator” but to be an active architecture component to separate concerns and responsibilities and have much simpler piece of software.
I had the opportunity to have a deeper understanding on what to watch if varnish is in a good shape or not, good stuffs.
I was impressed by so many people were there for a niche’s software, in italy at least. I think it a good starting point to create a devops community… as discussed yesterday we should start organize some sort of local user-group to start sharing experiences and trying ideas.
I hope to find their slides somewhere to review them 🙂
Last Friday I presented “Varnish e caching di applicazioni Rails” at the first italian RubyDay here you can find my slides:
This morning I’ve updated our amazon 32bit image with varnish.
After I applied the current configuration used on our 64bit image (on which it works flawlessly) varnish was able to start only the admin interface.
Logging in in the admin interface and asking for the status I was receiving:
Child in state stopped
And trying to start it:
child (30152) Started
Pushing vcls failed: CLI communication error (hdr)
Child (30152) died signal=11
Child (-1) said
Child (-1) said Child starts
Child cleanup complete
the options I was originally using were:
DAEMON_OPTS="-a :80 \
-T 127.0.0.1:6082 \
-f /etc/varnish/default.vcl \
-u ubuntu \
-g ubuntu \
-p sess_workspace=262144 \
-p listen_depth=2048 \
-p overflow_max=2000 \
-p ping_interval=2 \
-p log_hashstring=off \
-h classic,5000009 \
-p lru_interval=60 \
-p esi_syntax=0x00000003 \
-p thread_pool_add_delay=2 \
-p thread_pools=2 \
-p thread_pool_min=100 \
-p thread_pool_max=4000 \
-p shm_workspace=32768 \
-p default_grace=3600 \
-p sess_timeout=10 \
-p pipe_timeout=10 \
Using the “-d” option I was able to test all the options and at the end the problem was with:
It was too large for a 32bit system as stated on the varnish documentation:
Be aware that on 32 bit systems, certain default values, such as
sess_workspace (=16k) and thread_pool_stack (=64k) are reduced
relative to the values listed here, in order to conserve VM space.