Hi,
I was trying today to see the monthly visitor for July and I get the following error:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 8208 bytes) in /var/www/.../core/DataTable.php on line 935
I only get this error when I try to see monthly reports.
I have the latest version (v1.0) and the monthly visitors are somewhere around 100.000/month.
Thanks.
You should setup autoarchiving using a cronjob for your installation. Have a look at How to Set up Auto-Archiving of Your Reports - Analytics Platform - Matomo
I did as you said but the error continues. I tried to run the archive.sh manually from the shell but it only runs for less than a second and the only output I get is ‘Starting Piwik reports archiving…’.
Any clue on what could be wrong?
Regards.
Ok, I managed to run archive.sh (had to install php5-cli), and I still got the same memory error in the shell. I solved it by setting the memory limit at 512 MB in cli/php.ini.
Thanks.
Can you give a detailed info about the size of your Piwik installation?
Number of Websites, average number of Visits/Day, etc.
It’s one website, with an average of almost 100.000 visits/month and 3.000/day. I have piwik installed since Jan 2010. My database is now 636.1 MB with 4.617.339 records.
Sorry guys for bumbing that old a topic but it is still a relevant issue for our site.
I reckon our site visited by 10 to 13 thousand people and about 150.000 actions a day is pretty good in the scale of “medium to high-traffic sites” piwik I read is intended for.
Our piwik installation is version 1.1.1 and yet a limit of 512MB does apparently not suffice:
Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate
15 bytes) in /web/htdocs-ssl/intern/piwik/core/DataTable.php on line 940
I have cron run archive.sh once an hour. The process crashes just before processing the month periods.
How can I really solve this problem? I’m afraid increasing the memory limit every now and then cannot be a long-term solution. Some time, all physical mem would be exhausted and we’d have a severe problem …
line 940 is
public function addRowsFromSerializedArray( $stringSerialized )
{
$serialized = unserialize($stringSerialized); /* <-- HERE */
if($serialized === false)
{
throw new Exception("The unserialization has failed!" );
}
$this->addRowsFromArray($serialized);
}
If it is a bug in piwik, what is your priority of fixing it? 
Kind regards,
HamsterDerwisch
Hamster, yes this is a known bug, however we have done significant improvements in performance, and this is currently a RC release:
http://forum.piwik.org/read.php?2,72265
Please try it out, on a backup of your current Database, then run the update, then see if memory requirement is less.
However, it also mostly improves performance of dates going forward, so you might see better performance in the future with this version.
Hi matt,
even rc5 does not sort out that problem, now archive.sh apparently ignores or rather steps over the fatal error warning though (just as if you called ‘@’ function call prefix somewhere a solution 
- sure you don’t, right?) and finally claims there was no error but I can’t find the results of the month/year.
We really do not like to spend piwik more than 512MB of memory. Sorry, so it seems to us it is not a good idea to apply piwik in our productive environment. In the end we’ll have to fall unhappily back to load demanding log-analysis.
Is it possible that you did solve the problem but archive.sh still hits the limits because it tries to process so many rows afterwards as having them left unprocessed due to the error? How to get around that?
kind regards,
HamsterDerwisch
by defaut the archive.sh will try and archive the last 52 weeks / months / year.
Instead can you try the following change:
--- misc/cron/archive.sh (revision 3962)
+++ misc/cron/archive.sh (working copy)
@@ -73,7 +73,7 @@
for period in day week month year; do
echo ""
echo "Archiving period = $period for idsite = $idsite..."
- CMD="$PHP_BIN -q $PIWIK_PATH -- module=API&method=VisitsSummary.getVisits&idSite=$idsite&period=$period&date=last52&format=xml&token_auth=$TOKEN_AUTH"
+ CMD="$PHP_BIN -q $PIWIK_PATH -- module=API&method=VisitsSummary.getVisits&idSite=$idsite&period=$period&date=last1&format=xml&token_auth=$TOKEN_AUTH"
$CMD
for segment in $SEGMENTS_TO_ARCHIVE; do
This will only process the last week, last month, etc.
then if it is working we know that the error comes becomes memory is not freed after each period, this will be a good start.
Hello matt,
I applied the patch. Now the script indeed outputs only numbers of the last one day, week, month too, yeah!, but year … no, it still crashes. 
Seems like the month calculation is not based on the day calculation, and likewise year on month, is it? Thus, the process would need to hold 28-31 rows in memory, or 12 rows respectively.
kind regards,
HamsterDerwisch
Hello “HamsterDerwisch”,
keep in mind - 150k actions per day is a lot. Considering the heavy processing and correlation of data, piwik has to do, 512MB is not very much! You should allow piwik to use 1024MB of RAM. If that is not possible, your server is simply too small-sized for this szenario. Roundabout christmas time, our machine must handle about 150k unique visitors a day (running the website AND piwik), and we did not have any problems with a 1024M memory_limit.
Nevertheless, the server must be of course optimised to handle this - bytecode cache, an apache with not too much module overhead (that consume more and more RAM), etc.
Regards
Peter
150,000 is definitely possible with Piwik, but agree it is better to run on a server with 4Gb of ram and dedicate up to 1.5 for PHP process if needed. It really depends if you have a lot of page view data.
I recommend you delete your database, and install 1.2 from scratch. It has some memory improvements that might help. Make sure you setup the cron archive.sh and please report here after a few days if it is working or if you still have issues
Hello,
sorry I am visiting this board every once in a while. Tried successfully to change memory_limit temporarily to 1024M. We decided to increase this limit only once a month particularly for that archiving process. Any other time it is okay for us seeing it hit the limits and crash, or would that corrupt any data? Doesn’t seem so.
I’d like to propose you not to recalculate all 30 days for a month or so, but to simply sum up the values of completed weeks so far calculated since the 1st of each and then the values of the remainding days (for year full months and weeks respectively). I guess that should then be just a matter of kilobytes, shouldn’t it?
That is just a proposal if I see the problem right. Otherwise: nothing said. 
Kind regards,
HamsterDerwisch
Sorry to drudge up ancient report. But if the cron was executed without calls to the piwik web url would negate the need for excessive ram limits. Setting php ram limits really high per process drastically reduces the amount of concurrent connection you can handle.