[TYPO3-dev] problems with cache hashes

Hartmut Plehn plehn at rz.uni-wuerzburg.de
Thu Nov 29 10:05:55 CET 2007


Dmitry Dulepov [typo3] wrote:

> Hi!
> 
> ries van Twisk wrote:
>> I did understood that this discussion was about problems with cache
>> hashes and deadlocks, and not directly about performance (indirectly it
>> is because of the locks)
> 
> I mentioned locks there too. In my case it was not fatal but in other
> cases it can be.
>
I would think that a db system that had a 5 minute average load of 0.4
during the last month should not be called having "performance problems".
If during the same period the 5 minute max load has been over 100 from time
to time there is *some* kind of issue, though.
> 
>> aren't deadlocks problematic and might accure even on smaller sites?
> 
> If you od not use indexing and have cache in external files, than chances
> for dealock is much smaller for small sites.
> 
I of course tried $TYPO3_CONF_VARS['FE']['pageCacheToExternalFiles'] = '1'
but that didn't help with the deadlocks and even caused more problems
(sometimes empty pages were delivered depending on client ip and server
domain; we weren't able to analyze the problem because of complexity with
eaccelerator, php security settings and problem not being actively
reproducible).

We also tried to change to InnoDB for the caching tables already. But InnoDB
didn't seem to improve the deadlocks fundamentally and also has some
disadvantages compared to MyISAM: 

- you loose flexibility because of the harder handling of individual tables
(e.g. copying on filesystem basis; fast synchronizing master/slave by rsync)

- the ever growing ibdata-files (ok, I found the option
innodb_file_per_table lately) 

- lack of filesystem layer utilities like myisamchk

Maybe some more information about our system helps: There are over 10000
entries in cache_pages corresponding to the page with the CE causing the
problems. We have over 30000 entries in table "pages", over 80000
in "cache_pages" and about 180000 in "cache_hash" when the caches are
filled. Deleting the 10000 cache_pages entries for the problem page took
1:40 min just now, blocking page delivery to frontend for 2 minutes. If at
the same time there are some indexed-searches coming in we're in big
trouble.

In give InnoDB another try (after having found out about
innodb_file_per_table lately) and changed cache_pages, cache_pagesections,
cache_imagesizes and cache_hash to type=InnoDB just now.

Best regards and thank you for your comments!

-- 
Hartmut Plehn, Universitaet Wuerzburg




More information about the TYPO3-dev mailing list