## The Blog will be a little slow for the next few hours or day…

In the way I have set up WordPress.org, it makes use of a caching daemon named ‘Memcached‘, that runs on my server and speeds up the fetching of specific, frequently-requested content. This is not to be confused with whatever cache is also speeding up your browser.

As part of a routine set of updates fed through my package manager this evening, this daemon also received an update, which required that it be restarted. As a result, the cache is now cleared, and the fetching of the favorite postings to the readers will be somewhat slow for the next few hours, or maybe even for a whole day.

I apologize if this inconveniences anybody.

Also, this behavior does not represent any sort of malfunction, either by the daemon, nor in the update process. All the updates seemed to go through just fine.

Dirk

## How Finally to get Memcached to Lock its RAM

I use the daemon ‘memcached‘ to accelerate my blog. But in its default configuration, this daemon runs as user ‘memcache‘, has only 64M of space configured, and does not have the ‘-k‘ option set, to pin the virtual memory it is caching into physical RAM. It was a past project of mine, to remedy this, and to that end I put an entry into the file ‘/etc/security/limits.conf‘ which went like so:


memcache        hard    memlock         unlimited
memcache        soft    memlock         unlimited



Thus removing the default limit on how much memory any one user can lock.

But much to by dismay, when launching or restarting, ‘memcached‘ would leave a characteristic error message in my syslog, which indicated that it did not have permission to lock – say 128M – of RAM.

The solution which finally worked for me, was also to change the configuration of the service to include the option ‘-u root‘, so that this daemon actually runs as user ‘root‘, and to put into the limits file:


root            hard    memlock         unlimited
root            soft    memlock         unlimited



Once I had done that, the daemon was able to run, with the option set, to pin its pages in RAM.

My corollary of the initial problem is as follows: