Mailing List Archive

My first try with varnishd
[redirected to the mailing list]

Jiang Hong <netex at 163.com> writes:
> First congratulations to the 1.0 release of varnishd!

Thank you!

> The 'mmap' line told me varnishd uses mmap, so 1.6G cache file *SEEMED* too
> big for it (but isn't the limit 2GB?). Then I tried a 160MB cache file, this
> time varnishd started working!

It successfully mapped the entire file, but for some reason there was
too little address space left for malloc(). Try a slightly smaller
file, or increase maxdsiz, or switch to a 64-bit machine.

> So is it possible for varnishd to use multiple mmaps to use cache files
> larger than 2GB? It is enough for most cases, but when the average file
> size is larger than 2GB, it's much better to use a cache_dir like Squid.

No, it's a matter of address space. Varnish does not use a two-level
cache like Squid, it uses a single cache which is backed by a file to
allow the VM system to swap it out if it runs low on physical memory.
On a 64-bit machine, you can create a cache file as big as your entire
disk if you want.

> Can '-s malloc' be used with '-s file'? Squid uses memory as level-1 cache
> and disk storage as level-2 cache.

No. Squid's two-level cache is precisely one of things that's wrong
with it. It ends up fighting the VM system under heavy load. Varnish
on the other hand tries to avoid doing work which the VM system
already does better (like deciding which objects should be in physical
memory and which should be on disk).

> varnishd's VCL is much stronger than Squid's acl rules, but the sample.vcl
> cannot pass the compilation:
>
> backend vg {
> set backend.ip = 10.0.0.100;
> set backend.timeout = 4s;
> set backend.bandwidth = 2000Mb/s;
> }

I'm not sure where this code is from, but I think it was meant as an
illustration of the principles of VCL, not as an example of a working
configuration.

> backend.ip should be backend.host/port. I can't find replacements for
> backend.timeout and backend.bandwidth in 5 minutes. Is there any plan
> to make a document?

Yes, I'm working on it. For now, look through recent threads in the
varnish-dev archive (http://projects.linpro.no/pipermail/varnish-dev/)

DES
--
Dag-Erling Sm?rgrav - des at des.no
My first try with varnishd [ In reply to ]
[redirected to the mailing list]

Jiang Hong <netex at 163.com> writes:
> First congratulations to the 1.0 release of varnishd!

Thank you!

> The 'mmap' line told me varnishd uses mmap, so 1.6G cache file *SEEMED* too
> big for it (but isn't the limit 2GB?). Then I tried a 160MB cache file, this
> time varnishd started working!

It successfully mapped the entire file, but for some reason there was
too little address space left for malloc(). Try a slightly smaller
file, or increase maxdsiz, or switch to a 64-bit machine.

> So is it possible for varnishd to use multiple mmaps to use cache files
> larger than 2GB? It is enough for most cases, but when the average file
> size is larger than 2GB, it's much better to use a cache_dir like Squid.

No, it's a matter of address space. Varnish does not use a two-level
cache like Squid, it uses a single cache which is backed by a file to
allow the VM system to swap it out if it runs low on physical memory.
On a 64-bit machine, you can create a cache file as big as your entire
disk if you want.

> Can '-s malloc' be used with '-s file'? Squid uses memory as level-1 cache
> and disk storage as level-2 cache.

No. Squid's two-level cache is precisely one of things that's wrong
with it. It ends up fighting the VM system under heavy load. Varnish
on the other hand tries to avoid doing work which the VM system
already does better (like deciding which objects should be in physical
memory and which should be on disk).

> varnishd's VCL is much stronger than Squid's acl rules, but the sample.vcl
> cannot pass the compilation:
>
> backend vg {
> set backend.ip = 10.0.0.100;
> set backend.timeout = 4s;
> set backend.bandwidth = 2000Mb/s;
> }

I'm not sure where this code is from, but I think it was meant as an
illustration of the principles of VCL, not as an example of a working
configuration.

> backend.ip should be backend.host/port. I can't find replacements for
> backend.timeout and backend.bandwidth in 5 minutes. Is there any plan
> to make a document?

Yes, I'm working on it. For now, look through recent threads in the
varnish-dev archive (http://projects.linpro.no/pipermail/varnish-dev/)

DES
--
Dag-Erling Sm?rgrav - des at des.no
My first try with varnishd [ In reply to ]
> [redirected to the mailing list]
>
> Jiang Hong <netex at 163.com> writes:
>> First congratulations to the 1.0 release of varnishd!
>
> Thank you!
>
>> The 'mmap' line told me varnishd uses mmap, so 1.6G cache file *SEEMED*
>> too
>> big for it (but isn't the limit 2GB?). Then I tried a 160MB cache file,
>> this
>> time varnishd started working!
>
> It successfully mapped the entire file, but for some reason there was
> too little address space left for malloc(). Try a slightly smaller
> file, or increase maxdsiz, or switch to a 64-bit machine.
>
>> So is it possible for varnishd to use multiple mmaps to use cache files
>> larger than 2GB? It is enough for most cases, but when the average file
>> size is larger than 2GB, it's much better to use a cache_dir like Squid.
>
> No, it's a matter of address space. Varnish does not use a two-level
> cache like Squid, it uses a single cache which is backed by a file to
> allow the VM system to swap it out if it runs low on physical memory.
> On a 64-bit machine, you can create a cache file as big as your entire
> disk if you want.
>
>> Can '-s malloc' be used with '-s file'? Squid uses memory as level-1
>> cache
>> and disk storage as level-2 cache.
>
> No. Squid's two-level cache is precisely one of things that's wrong
> with it. It ends up fighting the VM system under heavy load. Varnish
> on the other hand tries to avoid doing work which the VM system
> already does better (like deciding which objects should be in physical
> memory and which should be on disk).

Great text/answers for the FAQ, DES.

> Yes, I'm working on it. For now, look through recent threads in the
> varnish-dev archive (http://projects.linpro.no/pipermail/varnish-dev/)

Great. I just wrote in another email that it was in /dev/null land for
now. Nothing is better than I was wrong.

Anders Berg
My first try with varnishd [ In reply to ]
> [redirected to the mailing list]
>
> Jiang Hong <netex at 163.com> writes:
>> First congratulations to the 1.0 release of varnishd!
>
> Thank you!
>
>> The 'mmap' line told me varnishd uses mmap, so 1.6G cache file *SEEMED*
>> too
>> big for it (but isn't the limit 2GB?). Then I tried a 160MB cache file,
>> this
>> time varnishd started working!
>
> It successfully mapped the entire file, but for some reason there was
> too little address space left for malloc(). Try a slightly smaller
> file, or increase maxdsiz, or switch to a 64-bit machine.
>
>> So is it possible for varnishd to use multiple mmaps to use cache files
>> larger than 2GB? It is enough for most cases, but when the average file
>> size is larger than 2GB, it's much better to use a cache_dir like Squid.
>
> No, it's a matter of address space. Varnish does not use a two-level
> cache like Squid, it uses a single cache which is backed by a file to
> allow the VM system to swap it out if it runs low on physical memory.
> On a 64-bit machine, you can create a cache file as big as your entire
> disk if you want.
>
>> Can '-s malloc' be used with '-s file'? Squid uses memory as level-1
>> cache
>> and disk storage as level-2 cache.
>
> No. Squid's two-level cache is precisely one of things that's wrong
> with it. It ends up fighting the VM system under heavy load. Varnish
> on the other hand tries to avoid doing work which the VM system
> already does better (like deciding which objects should be in physical
> memory and which should be on disk).

Great text/answers for the FAQ, DES.

> Yes, I'm working on it. For now, look through recent threads in the
> varnish-dev archive (http://projects.linpro.no/pipermail/varnish-dev/)

Great. I just wrote in another email that it was in /dev/null land for
now. Nothing is better than I was wrong.

Anders Berg