[TYPO3-dev] problems with cache hashes

Hartmut Plehn plehn at rz.uni-wuerzburg.de
Tue Nov 27 12:33:37 CET 2007


We occasionally observe massive performance problems during which all
http-processes have status waiting until all open process slots are
occupied. 

Analyzing the problem showed that in this situation the mysql daemon has
hundreds of "locked" processes of the form

SELECT S.* FROM cache_pages S,pages P WHERE
S.hash='c0e6fccd30de20a5fdeddbe4601de76c'

while at the same time there is one process with

DELETE FROM cache_pages WHERE page_id IN (46772)

which is presumably causing the locks. The page with id 46772 contains a
content element that is used with different sets of parameters resulting in
hundreds of "different" page realurl's based on this one content element.
The two extensions for which the problem mainly occurs are cal and one that
is developed by ourselves for internal use.

In "normal" situations the load of the db server is way below 1. The problem
can be avoided by clearing the full FE-cache before making changes to the
page with id 46772. But that can't be the intended behavior?

I admit that I do not really understand the Typo3 caching mechanisms and
chash mysteries according to
http://typo3.org/development/articles/the-mysteries-of-chash/, although I
think that the extensions do not have "useless parameters". 

Can anybody provide some more information about the topic and hints how to
solve it? Would it make sense to disable the cache for theses pages or the
realurl CHashCache alltogether? 

Thanks in advance!
-- 
Hartmut Plehn, Universitaet Wuerzburg




More information about the TYPO3-dev mailing list