Strange memcached behavior on stress test
time at digg.com
Mon Jun 12 05:45:20 UTC 2006
Jamie McCarthy wrote:
>I was curious, so I checked one of Slashdot's. Like most of our 16
>memcached servers, this one has been running for five months since
>its last restart:
>STAT uptime 13,052,212
>STAT total_connections 1,690,123
>STAT cmd_get 472,869,567
>STAT cmd_set 23,020,413
>STAT bytes_read 87,552,614,529
>STAT bytes_written 830,072,934,139
Ooh! Digg can't stay quiet if Slashdot pipes up... ;) But seriously,
here's another in the "we use memcached a lot and don't reboot it"
campfire stories. We use Debian Testing on AMD Opterons, and the
memcached that comes standard with that.
We recently moved our memcached cluster from one set of machines to
another. By recently, I mean 45 days ago. Here's one of the nodes:
Here you can see the remnants of the original method by which we used
memcached, that is, we would write any slow-produced SQL resultset into
memcached and fetch that to generate the same HTML in the future. That
meant we were writing things that were often never read again. Hence the
orders of magnitude more writing than reading.
Once Digg v.3 comes out, we expect the reads and writes to fall more
into line (reads should surpass writes).
More information about the memcached