Home / server / Questions / 296146
Accepted
laebshade
Asked: 2011-08-01 19:46:23 +0800 CST

Why is Memcached not working with vBulletin?

  • 772

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
memcached gentoo vbulletin

2 Answers

  1. Best Answer

    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
    • 1

  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.

    • 0