Why not let the fs handle this ??
const at const.org
Tue Jun 6 16:10:33 UTC 2006
2006/6/6, Brian Moon <brianm at dealnews.com>:
> > There is around 5gig in the cache dir but only 5% are massively used ,
> > hard to figure out optimal cache keys , the combinations number grows up
> > quickly .
> memcache would figure this out for you and the cache not used would fall
> off the end of the cache. Sounds like a 512MB cache would be more than
> enough for you.
> > I meant Xfs sorry , but with hashing dir based structure , rm is never
> > a problem
> > in my case .
> Sorry, I don't believe you, but I won't get into this argument.
a simple hash a/b/c for do it well on both reiser and xfs servers in my
never maid any problems (in my cas only i guess) as the names are quite
random due to the md5 they got relocated quite well.
> Sure , but its easy when you have very limited key combination number ,
> > but sometimes
> > its impossible to figure out , so the cache size grows up to several
> > gigs when only 100Meg is realy used , so having memcache "swap" down
> > can be good (maybe the os will do that if properly asked) ???
> Key combination is a problem no matter what the solution. What are you
> using now for file names? Use that for the memcache key. If only 100MB
> is used, then let the rest fall out of memcache. No sense having cache
> around that is not used.
for file names i use an md5 of involved params and i try to keep them as
few as possible
select * from a where a=$a and b=$b and c=$c;
the key is md5($a.$b.$c) the number of combinations is "decent" but its
keep it realy small .
For deciding what cache size is best for you, seem my (and others)
> previous emails about that issue.
> Brian Moon
> Its good to be cheap =)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the memcached