[TYPO3-english] Saving pages in BE locks complete database
lists at bytro.com
Wed Jan 27 12:43:17 CET 2010
Am 12.01.2010 16:30, schrieb Peter Russ:
> Please enable also slow queries log in Mysql as there might be other
> queries stopping the system.
Ok, I've enabled the slow query log and it just happened again. I've
extracted the time frame in question and attached the
"mysqldumpslow -l" (-l == "don't subtract lock time from total time")
of that part of the log.
In this case, the longest taking query is definitely this one:
Count: 1 Time=876.00s (876s) Lock=0.00s (0s) Rows=0.0 (0),
Which, given that I did the magical alter pages to InnoDB, should never
ever take that long should it? An update of a single primary key
referenced row in an InnoDB table. And the accessed page is a seldomly
accessed one so I don't even think that it got accessed during the
timeframe in question.
Some notes on what we did exactly before this problem occured:
I manually cleared the large cache tables in case we would get the slow
DELETE * FROM ... queries from the page update
-> truncate table cache_hash;
-> truncate table cache_pages;
2) We logged in to the backend and changed a standard tt_content text
element (which has a translation into a second language) and pressed
--> The browser never returned from "saving" since the database locked.
3) After about 5 Minutes, I stopped apache and a couple of minutes
later, the db was cleared up and running again.
What I furthermore find interesting is, that saving just after something
like that happened does too take some time, but tends to not lock the
database. The same update with sys_lastchanged query took (when saving
the same page 20 minutes later) 15 seconds.
Still too long but at least not locking.
Does anyone get any insight from this information?
Thanks a lot,
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the TYPO3-english