RPM-packages of varnish-2.0.5 for RHEL and Fedora available

2009-11-10 Thread Ingvar Hagelund
I have submitted varnish-2.0.5 for Fedora and Fedora EPEL, and updates 
to the stable releases will be requested, so they will trickle down to 
the stable repos in a few weeks.

For RHEL, both el4 and el5 packages are now in the EPEL testing repo. 
For those who are too impatient to wait for stable, or want to 
participate in testing, you can download the package with yum:

rhel5# yum --enablerepo=epel-testing update varnish

... or download the package from RedHat:

http://download.fedora.redhat.com/pub/epel/testing/

Fedora packages are still pending for testing, but will be visible in a 
few days, I guess. If you need packages for Fedora now, try 
http://kojipkgs.fedoraproject.org/packages/varnish/

Bugs in the package can be reported in Red Hat's Bugzilla: 
http://bugzilla.redhat.com/ or to varnish-d...@projects.linpro.no.

Ingvar
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Re: Varnish stuck on stresstest/approved by real traffic

2009-11-10 Thread Václav Bílek
I have tried setting session_linger =50 on 2.0.4 and it seems that is
solves the problem ( I wasnt able to reproduce after that)

Kristian Lyngstol napsal(a):
 (Excessive trimming ahead. Whoohoo)
 
 On Tue, Nov 03, 2009 at 11:51:22AM +0100, Václav Bílek wrote:
 When testing varnish throughput and scalability I have found strange
 varnish behavior.
 
 What's the cpu load at that point?
 
 Also: use sess_linger. No session_linger == kaboom when things get too
 loaded. It's 50ms default in 2.0.5/trunk, but set to 0ms in 2.0.4 and
 previous.
 
 The behaviour in trunk is slightly different/better, but it's still worth
 using it in 2.0.4.
 
 - Kristian
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Re: varnish 2.0.4 questions - no IMS, no persistence cache - please help

2009-11-10 Thread GaneshKumar Natarajan
Thanks.
I checked /proc/cpuinfo and it shows intel processor.
So even with Intel, we see this limitation of 340 GB. This is a
serious limitation to me, since in Squid, we were using 1.5 TB of
storage and i thought i could mmap and use all the space for Varnish.
Any workarounds or working kernel version in linux, please let me know.

mylinux version: RH4
2.6.9-89.ELsmp #1 SMP Mon Apr 20 10:33:05 EDT 2009 x86_64 x86_64
x86_64 GNU/Linux

ulimit -a:
core file size  (blocks, -c) 0
data seg size   (kbytes, -d) unlimited
file size   (blocks, -f) unlimited
pending signals (-i) 1024
max locked memory   (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files  (-n) 65535
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
stack size  (kbytes, -s) 10240
cpu time   (seconds, -t) unlimited
max user processes  (-u) 278528
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited

cat /proc/cpufinfo

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 23
model name  : Intel(R) Xeon(R) CPU   L5240  @ 3.00GHz
stepping: 6
cpu MHz : 2992.505
cache size  : 6144 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
nx lm pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm
bogomips: 5989.00
clflush size: 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 23
model name  : Intel(R) Xeon(R) CPU   L5240  @ 3.00GHz
stepping: 6
cpu MHz : 2992.505
cache size  : 6144 KB
physical id : 3
siblings: 2
core id : 6
cpu cores   : 2
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
nx lm pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm
bogomips: 5985.03
clflush size: 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 23
model name  : Intel(R) Xeon(R) CPU   L5240  @ 3.00GHz
stepping: 6
cpu MHz : 2992.505
cache size  : 6144 KB
physical id : 0
siblings: 2
core id : 1
cpu cores   : 2
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
nx lm pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm
bogomips: 5984.96
clflush size: 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 23
model name  : Intel(R) Xeon(R) CPU   L5240  @ 3.00GHz
stepping: 6
cpu MHz : 2992.505
cache size  : 6144 KB
physical id : 3
siblings: 2
core id : 7
cpu cores   : 2
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
nx lm pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm
bogomips: 5985.04
clflush size: 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

Ganesh


On Tue, Nov 10, 2009 at 1:48 AM, cripy ccr...@gmail.com wrote:
 GaneshKumar Natarajan writes:
 Tue, 20 Oct 2009 12:35:00 -0700

 3. mmap storage : max i can configure is 340 GB.
 I was able to use only 340 GB of cache. any size after this, i would get 
 error.
 child (25790) Started
 Pushing vcls failed: dlopen(./vcl.1P9zoqAU.so): ./vcl.1P9zoqAU.so:
 failed to map segment from shared object: Cannot allocate memory
 --

 I was having this issue too.  After some googling it appears this is a
 AMD64 Linux 2.6 issue.  According to
 http://lists.humbug.org.au/pipermail/general/2004-July/024139.html

 It maybe important to note that as of the latest 2.6 kernels, Linux on
 the AMD64 platform can only memory map a 340GB per process. This is due
 mainly to a VM paging system ported from the ia32 platform that should
 have been left on the hillside at birth to die. I have not tested *BSD
 because we have not done enough research to confirm if the Linux
 emulation works on AMD64 

Re: varnish 2.0.4 questions - no IMS, no persistence cache - please help

2009-11-10 Thread Michael S. Fischer
amd64 refers to the architecture (AKA x86_64), not the particular CPU  
vendor.   (As a matter of fact, I was unaware of this limitation;  
AFAIK it does not exist in FreeBSD.)

In any event, mmap()ing 340GB even on a 64GB box is a recipe for  
disaster; you will probably suffer death by paging if your working set  
is larger than RAM.   If it's smaller than RAM, then, well, there's no  
harm in making it just under the total RAM size.

--Michael


On Nov 11, 2009, at 1:04 AM, GaneshKumar Natarajan wrote:

 Thanks.
 I checked /proc/cpuinfo and it shows intel processor.
 So even with Intel, we see this limitation of 340 GB. This is a
 serious limitation to me, since in Squid, we were using 1.5 TB of
 storage and i thought i could mmap and use all the space for Varnish.
 Any workarounds or working kernel version in linux, please let me  
 know.

 mylinux version: RH4
 2.6.9-89.ELsmp #1 SMP Mon Apr 20 10:33:05 EDT 2009 x86_64 x86_64
 x86_64 GNU/Linux

 ulimit -a:
 core file size  (blocks, -c) 0
 data seg size   (kbytes, -d) unlimited
 file size   (blocks, -f) unlimited
 pending signals (-i) 1024
 max locked memory   (kbytes, -l) 32
 max memory size (kbytes, -m) unlimited
 open files  (-n) 65535
 pipe size(512 bytes, -p) 8
 POSIX message queues (bytes, -q) 819200
 stack size  (kbytes, -s) 10240
 cpu time   (seconds, -t) unlimited
 max user processes  (-u) 278528
 virtual memory  (kbytes, -v) unlimited
 file locks  (-x) unlimited

 cat /proc/cpufinfo

 processor   : 0
 vendor_id   : GenuineIntel
 cpu family  : 6
 model   : 23
 model name  : Intel(R) Xeon(R) CPU   L5240  @ 3.00GHz
 stepping: 6
 cpu MHz : 2992.505
 cache size  : 6144 KB
 physical id : 0
 siblings: 2
 core id : 0
 cpu cores   : 2
 fpu : yes
 fpu_exception   : yes
 cpuid level : 10
 wp  : yes
 flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
 mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
 nx lm pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm
 bogomips: 5989.00
 clflush size: 64
 cache_alignment : 64
 address sizes   : 38 bits physical, 48 bits virtual
 power management:

 processor   : 1
 vendor_id   : GenuineIntel
 cpu family  : 6
 model   : 23
 model name  : Intel(R) Xeon(R) CPU   L5240  @ 3.00GHz
 stepping: 6
 cpu MHz : 2992.505
 cache size  : 6144 KB
 physical id : 3
 siblings: 2
 core id : 6
 cpu cores   : 2
 fpu : yes
 fpu_exception   : yes
 cpuid level : 10
 wp  : yes
 flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
 mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
 nx lm pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm
 bogomips: 5985.03
 clflush size: 64
 cache_alignment : 64
 address sizes   : 38 bits physical, 48 bits virtual
 power management:

 processor   : 2
 vendor_id   : GenuineIntel
 cpu family  : 6
 model   : 23
 model name  : Intel(R) Xeon(R) CPU   L5240  @ 3.00GHz
 stepping: 6
 cpu MHz : 2992.505
 cache size  : 6144 KB
 physical id : 0
 siblings: 2
 core id : 1
 cpu cores   : 2
 fpu : yes
 fpu_exception   : yes
 cpuid level : 10
 wp  : yes
 flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
 mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
 nx lm pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm
 bogomips: 5984.96
 clflush size: 64
 cache_alignment : 64
 address sizes   : 38 bits physical, 48 bits virtual
 power management:

 processor   : 3
 vendor_id   : GenuineIntel
 cpu family  : 6
 model   : 23
 model name  : Intel(R) Xeon(R) CPU   L5240  @ 3.00GHz
 stepping: 6
 cpu MHz : 2992.505
 cache size  : 6144 KB
 physical id : 3
 siblings: 2
 core id : 7
 cpu cores   : 2
 fpu : yes
 fpu_exception   : yes
 cpuid level : 10
 wp  : yes
 flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
 mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
 nx lm pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm
 bogomips: 5985.04
 clflush size: 64
 cache_alignment : 64
 address sizes   : 38 bits physical, 48 bits virtual
 power management:

 Ganesh


 On Tue, Nov 10, 2009 at 1:48 AM, cripy ccr...@gmail.com wrote:
 GaneshKumar Natarajan writes:
 Tue, 20 Oct 2009 12:35:00 -0700

 3. mmap storage : max i can configure is 340 GB.
 I was able to use only 340 GB of cache. any size after this, i  
 would get error.
 child (25790) Started
 Pushing vcls failed: dlopen(./vcl.1P9zoqAU.so): 

Re: varnish 2.0.4 questions - no IMS, no persistence cache - please help

2009-11-10 Thread Ken Brownfield
Note that the linked article is from 2004.  The kernels that RedHat uses are a 
bag of hurt, not to mention ancient.

If you can upgrade to RHELl5 that may be the easiest fix (I can only assume 
that the mmap limitation has been removed).  Perhaps RedHat has newer RHELl4 
kernels in a bleeding edge repository, or perhaps Fedora/CentOS have packages 
that could upgrade your kernel.

That being said, there may be other pratfalls in the libc on RHELl4; bad 64-bit 
judgment calls persist in libc to this day (e.g., MAP_32BIT).

Ken

On Nov 10, 2009, at 11:47 AM, Michael S. Fischer wrote:

 amd64 refers to the architecture (AKA x86_64), not the particular CPU  
 vendor.   (As a matter of fact, I was unaware of this limitation;  
 AFAIK it does not exist in FreeBSD.)
 
 In any event, mmap()ing 340GB even on a 64GB box is a recipe for  
 disaster; you will probably suffer death by paging if your working set  
 is larger than RAM.   If it's smaller than RAM, then, well, there's no  
 harm in making it just under the total RAM size.
 
 --Michael
 
 
 On Nov 11, 2009, at 1:04 AM, GaneshKumar Natarajan wrote:
 
 Thanks.
 I checked /proc/cpuinfo and it shows intel processor.
 So even with Intel, we see this limitation of 340 GB. This is a
 serious limitation to me, since in Squid, we were using 1.5 TB of
 storage and i thought i could mmap and use all the space for Varnish.
 Any workarounds or working kernel version in linux, please let me  
 know.
 
 mylinux version: RH4
 2.6.9-89.ELsmp #1 SMP Mon Apr 20 10:33:05 EDT 2009 x86_64 x86_64
 x86_64 GNU/Linux
 
 ulimit -a:
 core file size  (blocks, -c) 0
 data seg size   (kbytes, -d) unlimited
 file size   (blocks, -f) unlimited
 pending signals (-i) 1024
 max locked memory   (kbytes, -l) 32
 max memory size (kbytes, -m) unlimited
 open files  (-n) 65535
 pipe size(512 bytes, -p) 8
 POSIX message queues (bytes, -q) 819200
 stack size  (kbytes, -s) 10240
 cpu time   (seconds, -t) unlimited
 max user processes  (-u) 278528
 virtual memory  (kbytes, -v) unlimited
 file locks  (-x) unlimited
 
 cat /proc/cpufinfo
 
 processor   : 0
 vendor_id   : GenuineIntel
 cpu family  : 6
 model   : 23
 model name  : Intel(R) Xeon(R) CPU   L5240  @ 3.00GHz
 stepping: 6
 cpu MHz : 2992.505
 cache size  : 6144 KB
 physical id : 0
 siblings: 2
 core id : 0
 cpu cores   : 2
 fpu : yes
 fpu_exception   : yes
 cpuid level : 10
 wp  : yes
 flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
 mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
 nx lm pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm
 bogomips: 5989.00
 clflush size: 64
 cache_alignment : 64
 address sizes   : 38 bits physical, 48 bits virtual
 power management:
 
 processor   : 1
 vendor_id   : GenuineIntel
 cpu family  : 6
 model   : 23
 model name  : Intel(R) Xeon(R) CPU   L5240  @ 3.00GHz
 stepping: 6
 cpu MHz : 2992.505
 cache size  : 6144 KB
 physical id : 3
 siblings: 2
 core id : 6
 cpu cores   : 2
 fpu : yes
 fpu_exception   : yes
 cpuid level : 10
 wp  : yes
 flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
 mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
 nx lm pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm
 bogomips: 5985.03
 clflush size: 64
 cache_alignment : 64
 address sizes   : 38 bits physical, 48 bits virtual
 power management:
 
 processor   : 2
 vendor_id   : GenuineIntel
 cpu family  : 6
 model   : 23
 model name  : Intel(R) Xeon(R) CPU   L5240  @ 3.00GHz
 stepping: 6
 cpu MHz : 2992.505
 cache size  : 6144 KB
 physical id : 0
 siblings: 2
 core id : 1
 cpu cores   : 2
 fpu : yes
 fpu_exception   : yes
 cpuid level : 10
 wp  : yes
 flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
 mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
 nx lm pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm
 bogomips: 5984.96
 clflush size: 64
 cache_alignment : 64
 address sizes   : 38 bits physical, 48 bits virtual
 power management:
 
 processor   : 3
 vendor_id   : GenuineIntel
 cpu family  : 6
 model   : 23
 model name  : Intel(R) Xeon(R) CPU   L5240  @ 3.00GHz
 stepping: 6
 cpu MHz : 2992.505
 cache size  : 6144 KB
 physical id : 3
 siblings: 2
 core id : 7
 cpu cores   : 2
 fpu : yes
 fpu_exception   : yes
 cpuid level : 10
 wp  : yes
 flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
 mca cmov 

varnish behind varnish and X-Forwarded-For

2009-11-10 Thread Jean-Christophe Petit
Hello,

setup is a varnish behind an other varnish - don't ask ;)
Is there a way to get the X-Forwarded-For from the first varnish to send 
it to the backend (Apache with mod_rpaf) ?
I see in the varnishlog of the second varnish that there are 2 
X-Forwarded-For (the client IP and the varnish IP)
How would I get rid of the second X-Forward-For but not the first one 
(the client IP) ?

Thanks,

Jesse
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc