Bug #58644
closed
belog: No output because of memory limit gets reached
Added by Adrian Dymorz over 10 years ago.
Updated about 7 years ago.
Category:
Backend User Interface
Description
In case you have got a huge amount of entries in sys_log, the module belog fails to display anything with certain filter settings.
How to reproduce:
1.) Make sure you have got more than 100'000 entries in the database table "sys_log".
2.) Change filter values in belog module: Select "[All users]" for users, select "[Any]" for "Max", select "no limit" for "Time", select "[Any]" for "Action".
3.) Change your PHP memory limit to 64 MB
Result: Instead of seeing the list, you get an empty page. The Apache error log shows that the memory limit got reached.
To change the filter values back to something that does not end in an error, you have to "Reset Configuration and Clear Temporary Data" using the "User settings" module.
- Target version deleted (
next-patchlevel)
And what do you propose to fix? You selected to show everything.
Thanks for your issue report.
There is not too much we could do to prevent this with the current options and output of the log module. As long as this is not redone UX wise (i could imagine quite some improvements), we will probably not tackle this memory limit issue here, if you select to show everything of those 100k records.
- Status changed from New to Needs Feedback
I consider this as an issue to be solved because the user may select filter settings which break the functionality in a very bad way: He has to wait long time to see nothing.
I see two useful solutions:
1.) Only allow values for "Max" to be selected which do not break the output. This prevents showing a huge list on system capable to.
2.) Implement a paging functionality. Either remove the value "Max" or replace it by "Items per page".
3.) Store the filter values into the database after finishing the output. In case the output brakes, the filter values would not be stored. This would assure, the user could call the belog module again without having to "Reset Configuration and Clear Temporary Data" first.
Well that does not help you either.
Lets assume you set everything to the maximum and you get the output successfully.
3 months later (the log filled up meanwhile) you access the module again, ... bam. Same problem.
You are right. How would you solve the problem?
Honestly: Not at all! You simply can't predict when the max execution time is reached.
I agree that there is no way to make an exact prediction when the max execution time is reached.
But this a problem all PHP application have in common. To solve it you have to use probability: The chance that a actual web server is capable to display 10 000 records is much higher (nearly 100%) than 1 000 000 (nearly 0%).
I still think that this problem has to be solved by the application and not by the user.
So we should limit the "unlimited" option to some "probably sane" value like 10000?
- Status changed from Needs Feedback to Closed
No feedback within the last 90 days => closing this issue.
If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.
- Category set to Backend User Interface
- Status changed from Closed to New
Reopened as requested in ML:
please reopen the issue.
It is reproducible and I think the issue would be worth fixing.
IMHO this isn't worth fixing. What will be a "probably sane" value for "unlimited"? Calculate by available max ram? PHP doesn't provide good function to implement a way to handle the case of memory and execution time.
As described in the comments before, there are some ideas how to improve the situation.
Even if there is no quick way to solve this issue, it should remain open because it is a real problem. I did run into this issue many times and a know from others which did too.
I would prefer a paging and a useful limit for the option "items per page" - 10k would be useful I think.
- Status changed from New to Closed
in v9 we will rewrite the log module anyway.
The current solution to your problem is to change:
module.tx_belog.settings.selectableNumberOfLogEntries to a value your system can handle.
- Related to Feature #82906: pagination for belog and setting in beuser added
- Related to Task #89256: Improve performance of belog "Log" module added
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by