+1
On Tue, Jul 6, 2010 at 2:47 PM, dormando wrote:
> Or you could disable the "failover" feature...
>
> On Tue, 6 Jul 2010, Darryl Kuhn wrote:
>
> > FYI - we made the change on one server and it does appear to have
> resolved premature key expiration.
> >
> > Effectively what appears to have bee
Or you could disable the "failover" feature...
On Tue, 6 Jul 2010, Darryl Kuhn wrote:
> FYI - we made the change on one server and it does appear to have resolved
> premature key expiration.
>
> Effectively what appears to have been happening was that every so often a
> client was unable to con
FYI - we made the change on one server and it does appear to have resolved
premature key expiration.
Effectively what appears to have been happening was that every so often a
client was unable to connect to one or more of the memcached servers. When
this happened it changed the key distribution. B
Found the reset call - that was me being an idiot (I actually introduced it
when I added logging to debug this issue)... That's been removed however
there was no flush command. Somebody else suggested it may have to do with
the fact that we're running persistent connections; and that if a failure
o
> Dormando... Thanks for the response. I've moved one of our servers to use an
> upgraded version running 1.4.5. Couple of things:
> * I turned on logging last night
> * I'm only running -vv at the moment; -vvv generated way more logging than
> we could handle. As it stands we've generated ~6
I think looking at the logs a bit more I can answer some of my own
questions:
- The "71" and "59" are connection IDs?
- An "END" should come after each "get" and a "STORED" should come after
each "set" - correct?
Thanks,
Darryl
On Thu, Jul 1, 2010 at 12:03 PM, Darryl Kuhn wrote:
> Dor
Dormando... Thanks for the response. I've moved one of our servers to use an
upgraded version running 1.4.5. Couple of things:
- I turned on logging last night
- I'm only running -vv at the moment; -vvv generated way more logging
than we could handle. As it stands we've generated ~6GB of
>
> Any thoughts on what might be going on here?
>
> As for vitals/system config:
>
> Here's a recent stats dump:
> STAT pid 19986
> STAT uptime 8526687
> STAT time 1277416425
> STAT version 1.2.8
You should probably upgrade, but I think this version has what you may
need...
If you can reproduce
We've been battling an issue for a while now (in fact not sure quite how
long it's been going on). It appears that keys are being evicted before
their expiration time, however when we check stats we see "evicted: 0" on
all slabs. To track this down we've added logging (see below) for a
particular k
