Why not let the fs handle this ??

[Constantin B]

2006/6/6, Brian Moon <brianm at dealnews.com>:
>
> > There is around 5gig in the cache dir but only 5% are massively used ,
> its
> > 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
case it
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
so :
  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
difficult to
keep it realy small .


For deciding what cache size is best for you, seem my (and others)
> previous emails about that issue.




--
>
> Brian Moon
> -------------
> http://dealnews.com/
> Its good to be cheap =)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20060606/c5f90060/attachment.htm