9

enter image description here

I am using the Performance Logging Module. Above screenshot, one strange thing I noticed that Insert Cache_bootstrap on every page. When you go to any page (both admin theme and frontend theme) Insert cache and then delete cache is running. It means that cache is set and destroyed in each page and actually no cache is occurring. How can I further elaborate it? To diagnose that issue because currently I am working on performance of the site.

enter image description here

I am also using New Relic for performance check. It also shows that database load is high.

and my.cnf information.

enter image description here

8

Slide #85 from my performance presentation talks about max packet size in MySQL, you need to increase that value; SET GLOBAL max_allowed_packet=33554432; or change it inside of the configuration file https://dev.mysql.com/doc/refman/5.7/en/packet-too-large.html

  • really helpful answer. – Mr. J Sep 1 '14 at 8:11
3

Max allowed packet size could be one reason this is happening, but I can see multiple reason why it is probably something else in this case.

  1. You don't just have cache writes, you also have explicit cache deletions. A failed cache write would just result in repeating cache writes and then cache misses, but not deletions.
  2. This is the cache_bootstrap table. There are some caches that can get big but they're usually not from that bin.

The most common reason for this pattern are variable_set() calls that happen on every page. Have a look at the where those cache deletions are coming from, either with xhprof, with xdebug and setting a breakpoint or by adding a debug_print_backtrace(DEBUG_BACKTRACE_NO_ARGS). I'm pretty sure that you will see a variable_set() call there.

The problem is that there is a single global cache for variables. Every cache write results in a cache delete and the next request will read out the whole {variables} table and write it back into the cache.

Many developers aren't aware of that and are doing things like "ensuring values" by calling variable_set() directly in a .module file or another place that is executed on every request.

  • yeah.. thats true most developer even me dont know about variable_set() fact which you discussed. and also i get to know about debug_print_backtrace(DEBUG_BACKTRACE_NO_ARGS). Thanks for that. :) – Mr. J Sep 3 '14 at 3:21
3

It is just a hypothesis but if your bootstrap cache rebuilds on every page load it may happen that some of your modules missing in modules folder but still present in system table. On each page load drupal tries to find it and rebuild bootstrap_cache.

Try the Bootstrap optimizer module, it will help to find such records and delete them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.