Why is Memcached not working with vBulletin?

Question

I have Memcached configured and setup to with work with vBulletin 4.1.5 on a Gentoo Linux 32-bit Linode VPS. Memcached is started, includes/config.php is configured to use the memcache, and the site does load and operate normally; however, Memcached does not appear to be caching, or at least caching very well. All services, Apache, MySQL, and Memcached run on the same server:

# for service in apache2 memcached mysql; do service $service status; done * status: started * status: started * status: started 

See below the output of psmem showing low memory usage:

 $ psmem | grep memcached 928.0 KB + 27.0 KB = 955.0 KB memcached 

Below, the includes/config.php section of the DataStore configuration:

$ grep DATASTORE config.php -A16 // ****** DATASTORE CACHE CONFIGURATION ***** // Here you can configure different methods for caching datastore items. // vB_Datastore_Filecache - for using a cache file //$config['Datastore']['class'] = 'vB_Datastore_Filecache'; // vB_Datastore_Memcached - for using a Memcache server // It is also necessary to specify the hostname or IP address and the port the server is listening on $config['Datastore']['class'] = 'vB_Datastore_Memcached'; $i = 0; // First Server $i++; $config['Misc']['memcacheserver'][$i] = '127.0.0.1'; $config['Misc']['memcacheport'][$i] = 11211; $config['Misc']['memcachepersistent'][$i] = true; $config['Misc']['memcacheweight'][$i] = 1; $config['Misc']['memcachetimeout'][$i] = 1; $config['Misc']['memcacheretry_interval'][$i] = 15; 

The memcache.ini configuration in /etc/php/apache2-php5.3/ext-active/memcache.ini, which is a symlink to /etc/php/apache2-php5.3/ext/memcache.ini:

/etc/php/apache2-php5.3/ext-active $ cat memcache.ini extension=memcache.so memcache.allow_failover=false memcache.max_failover_attempts=20 memcache.chunk_size=32768 memcache.default_port=11211 memcache.hash_strategy=consistent memcache.hash_function=crc32 memcache.redundancy=1 memcache.session_redundancy=2 memcache.protocol=ascii 

And finally, the output of a Perl script written (not by me) to allow data to be passed to Cacti for graphing purposes, but can also be used manually:

$ perl memcached.pl localhost total_items:898515 get_hits:20219203 uptime:3376080 cmd_get:23939667 time:1312170243 bytes:97280 curr_connections:35 connection_structures:55 bytes_written:102512934173 limit_maxbytes:67108864 cmd_set:1986754 curr_items:35 rusage_user:120.625662 get_misses:3720464 rusage_system:624.975989 bytes_read:3518914943 total_connections:28161 

This last output makes it looks like it's caching but as posted earlier, it's not even using 1 MB of storage.

Am I missing anything? Anything else I should check? If there is nothing wrong with the Memcached or the related PHP extension configuration, then it must be a vBulletin issue, where in it is not actively using the cache in the manner it should.

Ideas? Questions? I've been trying to get this working for months.

Also ran and compared the Perl script against echo "stats" | nc -w 1 localhost 11211, as suggested:

$ perl memcached.pl localhost | cut -d" " -f1 ; awk -F"STAT " '/total_items/{print $2}' <(echo "stats" | nc -w 1 localhost 11211) total_items:923792 total_items 923792 

Answer 1

Found the solution -- memcached was listening on 0.0.0.0; saw an immediate, significant increase in memory usage after changing to 127.0.0.1 and restarted, which continues to climb:

$ ps u -C memcached USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 103 27999 0.0 2.3 62196 18288 ? Ssl 16:30 0:00 /usr/bin/memcached -d -p 11211 -U 11211 -l 127.0.0.1 -m 64 -c 1024 

Answer 2

Given that a bare memcached process uses over 1MB of memory, I'd say that psmem is telling porkies. And, given that the top of the script explicitly says that is looks at RAM usage, not memory usage, I'd say that what you think is going on isn't. On the other hand, there's currently 35 items in the cache, you aren't exactly tearing things up there.

As to why vBulletin isn't using it, I dunno; I've successfully avoided that pile up until now, and I'm quite happy keeping it that way. There are better ways of verifying whether it's working than what you've been using so far (tcpdump -i lo port 11211 and strace -etrace=network immediately spring to mind), but you might have to take advantage of their much-vaunted support if it isn't actually doing what you want it to.