I was noticing today many apache segfaults on this server, and pretty high traffic loads at times. I haven’t pinpointed the exact cause of high traffic, there are a couple candidates, but the apache segfaults seem to accompanied by the following PHP errors:
[13-Aug-2008 13:55:27] PHP Notice: MemcachePool::get() [<a href="memcachepool.get">memcachepool.get</a>]: Server 127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout (0) in /var/vhosts/oam/soccerblogs.net/inc/Db/Slopject/Collection.php on line 579 [13-Aug-2008 13:55:29] PHP Notice: MemcachePool::get() [<a href="memcachepool.get">memcachepool.get</a>]: Server 127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout (0) in /var/vhosts/oam/soccerblogs.net/inc/Db/Slopject/Collection.php on line 579
This may be related to the local firewall and ip_conntrack, which has a known problem with memcached.
> This is because kernel try to track all your memcached connections – ie watch > all tcp/ip connection that you made to your memcache. and because conntrack > table have a limited size , and it must hold a connection information for > relative long time, when this table get overloaded, packets are dropped .
The required iptables rule in that email isn’t quite right, I had to do the following on the server
iptables -t raw -I OUTPUT -s ip_addrsss of your memcached box <b>--protocol tcp</b> --sport port of your memcached daemon -j NOTRACK
Here may end my brief fling with memcached. I’d originally installed it after switching to using prepared SQL statements, which do not use mysql’s query cache. I suspect mysql’s query cache is better for local caching, as it may allow mysql to handle client requests much faster. As it is now, mysql is taking more time to do its work, which at some point, knocks memcached offline. For local caches, using the caching mechanism available through php accelerators such as eaccelerator may be a better option to running a local memcached