6

I am currently testing memcached on a system that will be rebooted once a week, and would therefore like to pre-warm memcached after the reboot.

Wondering if anyone has a sample script they have found works well for this purpose?

5 Answers 5

4

This would be very dependent on your application. memcached is simply a way to store values for some key in a non-persistent manner, and as such there's no real way to build a standardized script. It also does not have a way to browse current contents, so there's not a real way to save the contents before reboot.

If you're using some sort of application framework that internally tracks popularity, it may have some functionality to do this (this is unlikely). The best way to to actually prime memcached would be for a custom script to take appropriate things and push them into the store. However if you use expirations, not randomizing on this priming could create problems later when things expire at the same time. Alternately and assuming a web app, setting some sort of crawler loose doing a 2-3 link deep crawl may be effective. Not attempting priming of the cache and focusing on making non-cached requests respond reasonably fast would probably be a better use of resources than any of the above.

The real solution is to not reboot the server weekly. A properly running system should not require regular reboots (only reboot for very low level system patches).

2

Perhaps look at migrating to a caching solution which persists to disk like Redis (http://code.google.com/p/redis/)

2

If anyone is still interested in this, memcached now supports it https://github.com/memcached/memcached/wiki/ReleaseNotes1518

1

I agree with the sentiments that ideally your server probably shouldn't need to be rebooted weekly unless that is your security update schedule.

Redis may or may not solve your problem; it depends on the data that you're using. At my immediately previous gig we used both Redis (with persistence) and Memcached.

To answer your question, though, in order to pre-warm your cache all that you would need to do is write a script (or have your devs do it) that copy the queries that they run through memcached, but doesn't act on them. Keep in mind that this makes sense only if your cache expiry is longer than it takes the script to run. You may want to try this out with your heaviest and/or most-frequent queries.

1

Running a web crawler could help, although it wouldn't provide the option of setting an appropriate expiry date.

As general background there is a useful overview of scriptable options here > http://docs.oracle.com/cd/E17952_01/refman-5.1-en/ha-overview.html

To see the items in memcached, (excluding Peep that is a Ruby script that no longer seems to be maintained and that I couldn't get working on Fedora 12) requires netcat installed on system and following examples assume memcached is running on port 11211 >

echo “stats items” | nc localhost 11211

This will list the slab numbers needed in the next instruction. Assuming a slab number of 17, show all items in that slab

echo “stats cachedump 17 0” | nc localhost 11211

Although wouldn't recommend to do this on a heavily used production system!

You must log in to answer this question.