On Thu, Sep 10, 2009 at 09:33:09PM +, Poul-Henning Kamp wrote:
> All the internal timestamps are in nanosecond resolution, just
> find the right printf and fix the format.
>
> Getting a timespec is just as expensive as getting a time_t, because
> time(2) simply calls clock_gettime(2) under you
In message <20090910212740.gv6...@digdug.corp.631h.metaweb.com>, Niall O'Higgin
s writes:
>Hi all,
>
>I am currently working on a custom logger for Varnish. One of the
>things we need is sub-second granularity for the start request log
>event (millisecond).
All the internal timestamps are in nano
Hi all,
I am currently working on a custom logger for Varnish. One of the
things we need is sub-second granularity for the start request log
event (millisecond).
It seems that currently Varnish only writes timestamps with a
granularity of one second.
I imagine that the reason for not providing
I am just curious in the status of if-none-match support from the
commit logs and this mailing list email
(http://www.mail-archive.com/varnish-misc@projects.linpro.no/msg02738.html)
it looks like its been committed. As was asked in the
aforementioned email are there any examples of how to use/conf
My weapon of choice there would be oprofile, run something like this
under high load and/or when you have a lot of threads active:
opcontrol --init
# You'll want a debug kernel
# For example, the Ubuntu package is linux-image-debug-server
opcontrol --setup --vmlinux=/boot/vmlinux-2.6.24-server
o
Václav Bílek napsal(a):
> is it posible that it is related to clock shift we had after reboot?
> the time was after reboot for few minutes set 2 hours forward ( before
> ntp corects that) ... we forgot to add /dev/rtc to the kernel
>
confirmed... it was problem with the time shift
_
is it posible that it is related to clock shift we had after reboot?
the time was after reboot for few minutes set 2 hours forward ( before
ntp corects that) ... we forgot to add /dev/rtc to the kernel
>>> I have a problem that varnish sometimes returns expired data.
>>>
>>> The ttl of objects i
>> Václav Bílek napsal(a):
>>> I have a problem that varnish sometimes returns expired data.
>>>
>>> The ttl of objects is from 1 to 10 seconds but varnish retuned objects
>>> older than tens of minutes.
>>> Grace is set to 60s.
>>> default ttl to 60s.
>
> Can you attach all the header-data you h
On Thu, Sep 10, 2009 at 09:04:07AM +0200, Václav Bílek wrote:
> Do not know if it is related but this sometime apears in the log:
Not likely to be related, no.
> varnishd[12160]: Child (12161) died signal=6
> varnishd[12160]: Child (12161) Panic message: Assert error in Tcheck(),
> cache.h line 6
>
> I guess my point is that certain use cases (some valid, some not, some
> involving bad pthread libraries in distributions (lots of them out
> there!))
How can I identify if our pthread libraries are in trouble?
___
varnish-misc mailing list
varni
>
>> If it is too much for that, one dirty workaround is to define
>> yourself as a backend, and send all IE6 to pass with yourself
>> as backend, that way you get a cache-hit, but can use vcl_fetch
>> on the pass transaction to nuke the connection closed header.
Pass for IE6 did not solve the
Do not know if it is related but this sometime apears in the log:
varnishd[12160]: Child (12161) died signal=6
varnishd[12160]: Child (12161) Panic message: Assert error in Tcheck(),
cache.h line 648:#012 Condition((t.e) != 0) not true. thread =
(cache-worker)sp = 0x7fd7a1952008 {#012 fd = 1213
12 matches
Mail list logo
