I maintain a rather large piwik installation. Each month's blob archive usually has an approximate size of 2 GB and typically contains around 3 million rows.
Since the update from 2.9.0 to 2.10.0 (which took approximately 9 hours, btw) I have massive problems with timed out transactions and performance overall. Also, the blob archive for 2015_01 now suddenly has a size of 13 GB and contains approximately 18 million rows. The archiver runs as cron job and is not triggered automatically.
Since the update, the Mysql process list is clogged with updates that look like this:
I assume that this query comes from the method "updateArchiveAsInvalidated" in core/DataAccess/Model.php. Given that there is neither an index on the date columns nor on idsite, this query is highly inefficient in a table as large as this. The query seems to be triggered by a call to the API method "doTrackPageView".
Any ideas how I can resolve this?
Since the update from 2.9.0 to 2.10.0 (which took approximately 9 hours, btw) I have massive problems with timed out transactions and performance overall. Also, the blob archive for 2015_01 now suddenly has a size of 13 GB and contains approximately 18 million rows. The archiver runs as cron job and is not triggered automatically.
Since the update, the Mysql process list is clogged with updates that look like this:
UPDATE piwik_archive_blob_2015_01 SET value = 4 WHERE ( (date1 <= '2015-02-10' AND '2015-02-10' <= date2 AND name LIKE 'done%') ) AND idsite IN ('....')
I assume that this query comes from the method "updateArchiveAsInvalidated" in core/DataAccess/Model.php. Given that there is neither an index on the date columns nor on idsite, this query is highly inefficient in a table as large as this. The query seems to be triggered by a call to the API method "doTrackPageView".
Any ideas how I can resolve this?