[support] Problem with Drupals built in cache
Jamie Holly
hovercrafter at earthlink.net
Thu Jan 20 15:14:40 UTC 2011
You got a lot of misses in there. Have you checked your error logs to
see if anything is going on? One thing that is possible is that you are
hitting the 1mb limit for objects in memcache with the variable cache.
This thread has some details on it:
http://groups.drupal.org/node/116764
Also if you could post your memcache configuration from settings.php to
see if anything is going on in there.
Jamie Holly
http://www.intoxination.net
http://www.hollyit.net
On 1/20/2011 10:01 AM, Margusja wrote:
> Tnx for hints.
>
> I enabled memcache in my PHP conf. And I think the module is loaded.
> [16:50:57 root at arendus ~]# php -i | grep memcache
> memcache
> memcache support => enabled
> memcache.allow_failover => 1 => 1
> memcache.chunk_size => 32768 => 32768
> memcache.compress_threshold => 20000 => 20000
> memcache.default_port => 11211 => 11211
> memcache.hash_function => crc32 => crc32
> memcache.hash_strategy => consistent => consistent
> memcache.lock_timeout => 15 => 15
> memcache.max_failover_attempts => 20 => 20
> memcache.protocol => ascii => ascii
> memcache.redundancy => 1 => 1
> memcache.session_redundancy => 2 => 2
> Registered save handlers => files user memcache
>
> [16:49:22 root at arendus ~]# echo stats | nc localhost 11211
> STAT pid 30211
> STAT uptime 23950
> STAT time 1295535057
> STAT version 1.2.8
> STAT pointer_size 32
> STAT rusage_user 0.130980
> STAT rusage_system 0.311952
> STAT curr_items 473
> STAT total_items 1763
> STAT bytes 587316
> STAT curr_connections 10
> STAT total_connections 242
> STAT connection_structures 15
> STAT cmd_flush 0
> STAT cmd_get 9007
> STAT cmd_set 1763
> STAT get_hits 1025
> STAT get_misses 7982
> STAT evictions 0
> STAT bytes_read 11112904
> STAT bytes_written 8412213
> STAT limit_maxbytes 67108864
> STAT threads 5
> STAT accepting_conns 1
> STAT listen_disabled_num 0
> END
>
> Still in mysqld log:
> 110120 16:53:15 4102 Connect user at localhost on db
> 4102 Query SET NAMES "utf8"
> 4102 Query SELECT 1 FROM access WHERE type = 'host'
> AND 'IP' LIKE mask AND status = 0 LIMIT 0, 1
> 4102 Query INSERT INTO semaphore (name, value, expire)
> VALUES ('variable_cache_regenerate',
> '14419249754d384c5bd38895.47612777', 1295535225.8664)
> 4102 Query SELECT * FROM variable
> 4102 Query DELETE FROM semaphore WHERE name =
> 'variable_cache_regenerate' AND value = '14419249754d384c5bd38895.47612777'
> 4102 Query SELECT name, filename, throttle FROM system
> WHERE type = 'module' AND status = 1 AND bootstrap = 1 ORDER BY weight
> ASC, filename ASC
> 4102 Query SELECT * FROM languages ORDER BY weight
> ASC, name ASC
> 4102 Query SELECT dst FROM url_alias LIMIT 0, 1
>
>
>
> Tervitades, Margus (Margusja) Roo
> +372 51 48 780
> http://margus.roo.ee
> msn: margusja at kodila.ee
> skype: margusja
>
>
> On 1/20/11 4:03 PM, Jamie Holly wrote:
> > Then I would check phpinfo to make sure that the memcache extension is
> > loading into PHP (you can do this from admin -> reports -> status and
> > then clicking on your PHP version number).
> >
> > If that's showing up ok, you can run a command from the terminal to make
> > sure things are being written/read from memcache:
> >
> > echo stats | nc {memcache address} {memcache port}
> >
> > Your main things to look at are the hits, misses, bytes and connections.
> >
> > There are also some versions of memcache + the PHP extension that don't
> > work well together. This can be a hit and miss thing finding them. I
> > know there was a combination in the CentOS repos a year or so ago that
> > caused problems. Getting the latest version of the PHP extension and
> > building it from source would fix that.
> >
> > Jamie Holly
> > http://www.intoxination.net
> > http://www.hollyit.net
> >
> >
> > On 1/20/2011 8:43 AM, Margusja wrote:
> >> Thx for a replay. I checked again my memcache and I think it works fine.
> >>
> >> [15:40:16 root at arendus ~]# telnet localhost 11211
> >> Trying 127.0.0.1...
> >> Connected to localhost.
> >> Escape character is '^]'.
> >> stats
> >> STAT pid 30211
> >> STAT uptime 19724
> >> STAT time 1295530831
> >> STAT version 1.2.8
> >> STAT pointer_size 32
> >> STAT rusage_user 0.094985
> >> STAT rusage_system 0.230964
> >> STAT curr_items 67
> >> STAT total_items 1089
> >> STAT bytes 168012
> >> STAT curr_connections 11
> >> STAT total_connections 188
> >> STAT connection_structures 14
> >> STAT cmd_flush 0
> >> STAT cmd_get 6580
> >> STAT cmd_set 1089
> >> STAT get_hits 711
> >> STAT get_misses 5869
> >> STAT evictions 0
> >> STAT bytes_read 9254362
> >> STAT bytes_written 5742821
> >> STAT limit_maxbytes 67108864
> >> STAT threads 5
> >> STAT accepting_conns 1
> >> STAT listen_disabled_num 0
> >> END
> >>
> >> rows from settings.php
> >> if(extension_loaded('memcache')){
> >> $conf['cache_inc'] = './sites/all/modules/memcache/memcache.inc';
> >> $conf['memcache_key_prefix'] = 'xxx';
> >> }
> >>
> >> Tervitades, Margus (Margusja) Roo
> >> +372 51 48 780
> >> http://margus.roo.ee
> >> msn: margusja at kodila.ee
> >> skype: margusja
> >>
> >>
> >> On 1/20/11 2:45 PM, Jamie Holly wrote:
> >>> Drupal is still going to check the access table to see if you have any
> >>> blocks in there for the current user, even if the table is empty.
> >>>
> >>> The semaphore you are seeing is to prevent a cache stampede. You said
> >>> that once you disabled memcache, everything worked fine. It looks like
> >>> you have a problem with either your memcache server, the PHP memcache
> >>> extension or your settings in Drupal for memcache. I would check the
> >>> server first, since that's the easier. You can just do a telnet to check
> >>> that out. From shell:
> >>>
> >>> telnet (server address) (server port)
> >>>
> >>> See if it connects OK.
> >>>
> >>> As far as Pressflow+Memcache, yeah they work great together. I run that
> >>> combination for a couple of clients, including one that has seen over
> >>> 150,000 page an hour, and never had a problem.
> >>>
> >>> Jamie Holly
> >>> http://www.intoxination.net
> >>> http://www.hollyit.net
> >>>
> >>>
> >>> On 1/20/2011 4:12 AM, Margusja wrote:
> >>>> If I disable memcache support in PHP then in the problematic server I
> >>>> see that there no problem anymore. So can memcache and pressflow cache
> >>>> work parallel ?
> >>>>
> >>>> Tervitades, Margus (Margusja) Roo
> >>>> +372 51 48 780
> >>>> http://margus.roo.ee
> >>>> msn: margusja at kodila.ee
> >>>> skype: margusja
> >>>>
> >>>>
> >>>> On 1/20/11 10:09 AM, Margusja wrote:
> >>>>> Hi
> >>>>>
> >>>>> I have two separate Drupal instances (Pressflow 6.19) In first one the
> >>>>> local cache works fine. Sql log:
> >>>>> 326 Query SET NAMES "utf8"
> >>>>> 326 Query SELECT 1 FROM access WHERE type = 'host' AND
> >>>>> '195.50.208.170' LIKE mask AND status = 0 LIMIT 0, 1
> >>>>> 326 Query SELECT data, created, headers, expire,
> >>>>> serialized FROM cache WHERE cid = 'variables'
> >>>>> 326 Query SELECT data, created, headers, expire,
> >>>>> serialized FROM cache_page WHERE cid = 'http://IP/path/to/node'
> >>>>> 326 Query SELECT name, filename, throttle FROM system
> >>>>> WHERE type = 'module' AND status = 1 AND bootstrap = 1 ORDER BY weight
> >>>>> ASC, filename ASC
> >>>>> 326 Query SELECT name, filename, throttle FROM system
> >>>>> WHERE type = 'module' AND status = 1 AND bootstrap = 1 ORDER BY weight
> >>>>> ASC, filename ASC
> >>>>> 326 Quit
> >>>>>
> >>>>> But If I request the same node in the second machine. The code is same,
> >>>>> then the Sql log is:
> >>>>> 122 Quit
> >>>>> 123 Query SET NAMES "utf8"
> >>>>> 123 Query SELECT 1 FROM access WHERE type = 'host'
> >>>>> AND 'IP' LIKE mask AND status = 0 LIMIT 0, 1
> >>>>> 123 Query INSERT INTO semaphore (name, value, expire)
> >>>>> VALUES ('variable_cache_regenerate',
> >>>>> '17865562914d37e5d81acd80.47344784', 1295508982.1098)
> >>>>> 123 Query SELECT * FROM variable
> >>>>> 123 Query DELETE FROM semaphore WHERE name =
> >>>>> 'variable_cache_regenerate' AND value = '17865562914d37e5d81acd80.47344784'
> >>>>> 123 Query SELECT name, filename, throttle FROM system
> >>>>> WHERE type = 'module' AND status = 1 AND bootstrap = 1 ORDER BY weight
> >>>>> ASC, filename ASC
> >>>>> 123 Query SELECT * FROM languages ORDER BY weight
> >>>>> ASC, name ASC
> >>>>> 123 Query SELECT dst FROM url_alias LIMIT 0, 1
> >>>>> 123 Query SELECT src FROM url_alias WHERE dst =
> >>>>> 'hoiused-ja-investeerimine' AND language IN('et', '') ORDER BY language
> >>>>> DESC, pid DESC
> >>>>> 123 Query SELECT name, filename, throttle FROM system
> >>>>> WHERE type = 'module' AND status = 1 ORDER BY weight ASC, filename ASC
> >>>>> 123 Query INSERT INTO semaphore (name, value, expire)
> >>>>> VALUES ('locale_cache_et', '17865562914d37e5d81acd80.47344784',
> >>>>> 1295508982.4035)
> >>>>> 123 Query SELECT s.source, t.translation, t.language
> >>>>> FROM locales_source s LEFT JOIN locales_target t ON s.lid = t.lid AND
> >>>>> t.language = 'et' WHERE s.textgroup = 'default' AND s.version = '6.19'
> >>>>> AND LENGTH(s.source)< 75
> >>>>> 123 Query DELETE FROM semaphore WHERE name =
> >>>>> 'locale_cache_et' AND value = '17865562914d37e5d81acd80.47344784'
> >>>>> 123 Query SELECT s.lid, t.translation, s.version FROM
> >>>>> locales_source s LEFT JOIN locales_target t ON s.lid = t.lid AND
> >>>>> t.language = 'et' WHERE s.source = 'Stores details about batches
> >>>>> (processes that run in multiple HTTP requests).' AND s.textgroup =
> >>>>> 'default'
> >>>>> ....
> >>>>> ....
> >>>>> loads of SQLs
> >>>>>
> >>>>> The main question why does the last one ask something from semaphore? In
> >>>>> both servers access table is empty. At first I thought the condition
> >>>>> came from that SQL: SELECT 1 FROM access WHERE type = 'host' AND 'IP'
> >>>>> LIKE mask AND status = 0 LIMIT 0, 1 but as I said in both servers access
> >>>>> table is empty.
> >>>>>
> >>>>> In both solutions caches are enabled.
> >>>>>
> >>>>> Any hints?
> >>>>>
More information about the support
mailing list