In an attempt to raise the hit ratio for the parser cache, I've increased the amount of memory available to memcached. Because the client algorithm distributes keys to each available server equally, without regard for the amount of memory in each one, it's necessary to have multiple instances running on each machine, each instance having a fixed amount of memory. We're using 15 instances with 512 MB of memory each, for a total of 7.5 GB. The arrangement is:
bart: 2 bayle: 2 yongle: 4 rabanus: 4 will: 3
I wanted to put some on suda but I had trouble with installation. Keys are distributed using the hash mod the number of instances, so whenever we change the number of instances, most keys get lost. In other words, adding more servers incurs a performance hit since the cache needs to be rebuilt.
-- Tim Starling
Timwi wrote:
Tim Starling wrote:
Because the client algorithm distributes keys to each available server equally,
Is this a shortcoming of the PHP version of the memcached client? This is certainly not true for the Perl version; you can specify weights there.
Before we fixed it, the PHP client sent every key with a key length longer than about 8 bytes to the first server on the list. Since pretty much all our keys are longer than 8 bytes, this caused some problems. I still haven't sent a patch upstream for that one. I can rant all day about problems with memcached, both in the clients and in the server. As soon as I find (or write) a suitable alternative, I'm switching to it. Perhaps some sort of LRU cache wrapper around TreadMarks or SAM would do the trick.
-- Tim Starling
Timwi wrote:
Tim Starling wrote:
I can rant all day about problems with memcached, both in the clients and in the server.
Have you considered reporting the problems with the server "upstream"?
They already know about them. Brad keeps saying on the ML he's going to fix this or that, but no significant work has been done on it in the last 6 months.
-- Tim Starling
Tim Starling wrote:
Timwi wrote:
Have you considered reporting the problems with the server "upstream"?
They already know about them. Brad keeps saying on the ML he's going to fix this or that, but no significant work has been done on it in the last 6 months.
I hate to say it, but memcached _is_ *cough* open source *cough*. :)
-- brion vibber (brion @ pobox.com)
Tim Starling wrote:
I can rant all day about problems with memcached, both in the clients and in the server. As soon as I find (or write) a suitable alternative, I'm switching to it.
Would you specify (in detail) the problems you've had, and possibly a list of new or improved features over memcached that you'd want? I might be able to find someone to write a replacement or patch the existing source.
Cheers, Ivan.
Ivan Krstic wrote:
Tim Starling wrote:
I can rant all day about problems with memcached, both in the clients and in the server. As soon as I find (or write) a suitable alternative, I'm switching to it.
Would you specify (in detail) the problems you've had, and possibly a list of new or improved features over memcached that you'd want? I might be able to find someone to write a replacement or patch the existing source.
Memcached has a mailing list. Maybe this person you're referring to should join it. :)
wikitech-l@lists.wikimedia.org