> Updated, please let me know if that answers your questions.
Yes, this gives now better insight how they are used (not like
daily/weekly automated system, but on demand.)
I'll check my gentoo system when I get it up'n'running if it would be
worth contributing here.
Regards,
Joonas 'kerbe' Häm
Hi all:
I have just installed the latest version 1.4.0, and I read the doc/
protocol-binary.xml. There are some new command like getk, getq, setq
and so on.
I'm not sure how can I use these commands. Can I use them in ascii
protocol? Or they are only used in binary protocol?
And another quest
Yes, there is an idea in our group which could be helpful in
delivering the better performance and more sophisticated which reduces
the fragmentation and stuff. So, I am interested in knowing about the
code of facebook's memcached to know how they are implementing so as
to link it with the idea we
You really do want automatic slab reassignment... What you're doing is
janky and doesn't really solve the problem. If anything happens that ends
up filling more of your cache, you have to restart memcached anyway.
I'm not entirely sure why you're going through all of this trouble,
instead of just
On 21. juli. 2009, at 13.47, dl4ner wrote:
Hello Trond,
The biggest problem with expiration is that in order to locate the
item to expire we would have to look at _all_ items in the cache
Yes, I know. That's the reason why
- I suggested an additional command to have it externally triggere
Hello Trond,
> The biggest problem with expiration is that in order to locate the
> item to expire we would have to look at _all_ items in the cache
Yes, I know. That's the reason why
- I suggested an additional command to have it externally triggered
only when needed
(most users should not
On 21. juli. 2009, at 13.27, Henrik Schröder wrote:
Wait, you say that if you manually find items and delete them, your
cache never really grows much and you avoid the problem. But why
don't you set short expiration times on all items from the start,
then you wouldn't have to do your manu
Wait, you say that if you manually find items and delete them, your cache
never really grows much and you avoid the problem. But why don't you set
short expiration times on all items from the start, then you wouldn't have
to do your manual find/delete because it would never grow, and you would
alwa
The biggest problem with expiration is that in order to locate the
item to expire we would have to look at _all_ items in the cache (we
don't link the items into a expiry list). Currently we work out of the
assumption that the future memory allocation pattern will match the
current patte
There is no communication between memcached servers, only between your
clients and your servers. It is however a good idea to make sure that your
clients can reach all servers as fast as possible, and as Raymond says, it's
a good idea to secure your memcached servers by putting them on an internal
Hi Dormando,
> Can you explain what you mean by "expire" ? You've gone into great detail
> about needing it, but I don't see how explicitly expiring items is doing
> you get good over letting them be evicted? Or by setting more sane
> expiration times?
well, lets say I have 2 G RAM in total for
On Jul 20, 11:37 pm, Joonas Hämäläinen
wrote:
> Hips,
>
> > I wrote up this wiki page to hopefully get you started:
>
> > http://code.google.com/p/memcached/wiki/BuildFarm
>
> Could you update that wiki page to contain info about how heavy usage
> such buildbot has? Like how frequently such bu
12 matches
Mail list logo
