Strange memcached behavior on stress test

[timeless]

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:

uptime:3,956,179
bytes_read:81,743,715,223
bytes_written:7,345,267,298,630

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).

--
timeless