Month view hitting PHP memory limit

[liblogger]

Hello – we’ve had a recurrence of the issue raised here: https://theeventscalendar.com/support/forums/topic/month-view-causing-php-memory-limit-error-with-wp-super-cache/ – when we go to the month view of the calendar, the page crashes.

I’ve managed to reproduce the problem on our test site (just by copying the whole database over), so I’ve had a chance to go through and disable plugins and themes – it’s not just the caching plugin that’s causing the site to hit the php memory limit, although it does get noticeably worse when the caching plugin is enabled.

When all the plugins are enabled and caching is turned on, we get the following error message:

Fatal error: Unknown: Cannot use output buffering in output buffering display handlers in Unknown on line 0

When the caching plugin is turned off (not disabled), we start to see ‘Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 81 bytes) in /home/womensli/public_html/crashtest/wp-includes/wp-db.php on line 2409’ messages – depending on how many plugins we have enabled, the page will start to load and either get no further that the WP theme header, or part-way through the page before getting stuck. It gets a little further when the WP default theme is used, but only nominally; sometimes the error message is logged but not displayed.

We do have a lot of events (2 or 3 long events over weeks or months, with at least 1 and up to five or six one-off or recurring events on weekdays), but there wouldn’t have been many added over the course of the month, so I’m not sure why the problem’s arising now when it had been working okay for the first week or so.

I’ve tried turning on the ECPro month view cache, and that doesn’t seem to make any difference.

If I manually enter the next month’s url, or click forward through the photo or list view until I’m in November and then switch to the month view, it displays, and I can then click into the ‘previous’ month – at this point October, which makes the error even more frustrating.

We’re on shared hosting, so I don’t have control over the PHP memory limit – the system info copied over from WP seems to think it’s set to 256M, but it’s actually 64M.

(Our test site is running v. 4.3, but the live site hasn’t been upgraded yet, and is on 4.2.4)

[Brook]

Howdy Liblogger,

I would love to help you with this. I am sorry it is running that slow!

I am wondering the same thing Cliff did in your last topic: If you might have fallen victim to that but that existed in 4.2.2 of Events Calendar Pro, and was fixed a few hours later in 4.2.2.1.

We have an updated version of the cleanup plugin you tried before, would you mind installing it? The nicest part about the newer version is that it gives us some extra diagnostic information that can be very helpful in figuring out what’s happening on your site.

tribe-extension-recurring-cleanup

With that installed on your test site go to WP Admin > Tools and you will see this. Could you copy/paste your list of recurring events here in a private reply?

Also, how big was your database that you transferred to the new site? Any idea how many posts or rows were in the wp_posts table?

With that info I’ll be better poised to help offer suggestions applicable to your site. Please let me know if you have any questions for me as well.

Cheers!

– Brook

[liblogger]

Hello Brook, thanks for your prompt response.

We’ve over 15,000 entries in the wp_posts table – I suspect quite a lot of these will be post revisions, and I will have a look at cleaning up that table.

WRT the recurring events – I realised that there’s one recurring event that has a far greater number of recurring events than it should. This occurred when I ran the previous version of your ‘recurring event bug fix’ plugin – I unpublished the event, so they’re sitting in the drafts, and had assumed that they wouldn’t affect the front end. I then, admittedly, forgot about it :/ (It did have an end date, and the dates have all passed)

Before I start the new recurring event fix plugin, can I check a few things about the way ECPro deals with recurring events? We don’t have any recurring events that are open-ended – our events get added (for the most part) triannually for our Spring, Summer and Autumn/Winter programmes, so even events that are long-running are added in batches. None of the events (barring the one that flaked out after the attempt to fix it!) have more than about a dozen instances. I had assumed that once the events were generated and could be seen in the dashboard event listing, there wouldn’t be an issue with the calendar having to generate content when it was viewed?

We also quite often have exceptions and/or events that are pulled out of the recurring event series – again, I’d assumed that once the events were generated, and pulled out of the series, the calendar would see them as regular events?

I’m also slightly concerned about the “Clean up recurring events after” setting – does this apply to recurring events with date limits? We like to keep past events on the website so we have a record of them – why should past events (recurring or otherwise) have any impact on the current and upcoming event views? (beyond the obvious one of the post table being large).

[Brook]

You are very welcome liblogger, it’s my pleasure.

WRT the recurring events – I realised that there’s one recurring event that has a far greater number of recurring events than it should. This occurred when I ran the previous version of your ‘recurring event bug fix’ plugin – I unpublished the event, so they’re sitting in the drafts, and had assumed that they wouldn’t affect the front end. I then, admittedly, forgot about it :/ (It did have an end date, and the dates have all passed)

I was wondering if you would have such an event. That sounds like the bug from 4.2.2.1. If that’s the case the last cleanup plugin clearly did not fix it.  Deleting that event and emptying your trash might have a huge impact on site performance — it depends on how big the event is.

Before I start the new recurring event fix plugin, can I check a few things about the way ECPro deals with recurring events? We don’t have any recurring events that are open-ended – our events get added (for the most part) triannually for our Spring, Summer and Autumn/Winter programmes, so even events that are long-running are added in batches. None of the events (barring the one that flaked out after the attempt to fix it!) have more than about a dozen instances.

How you add events sounds great, and the calendar should be more than capable of handling it.

I had assumed that once the events were generated and could be seen in the dashboard event listing, there wouldn’t be an issue with the calendar having to generate content when it was viewed?

Once the events are generated they have never have to be generated again, so loading events from the front end is a pure “read” action.

However, our calendar is designed to scale to thousands of events on even relatively slow servers. To accomplish this feat it does not always generate all of the events right away, it just does as many as it can. You’ve probably noted the progress bar at the top of a recurring event after you hit publish. Once that bar is complete the event is done being generated and everything is a read operation. But depending on the server and number of events, this bar can take a while to complete, sometimes hours. And during that time period events are sitll being generated in the background.

The only exception to the above is if you have events with no end date or a distant end date, and this would not apply to you.

I’m also slightly concerned about the “Clean up recurring events after” setting – does this apply to recurring events with date limits? We like to keep past events on the website so we have a record of them – why should past events (recurring or otherwise) have any impact on the current and upcoming event views? (beyond the obvious one of the post table being large).

This setting will will delete recurrences with a lot of repetitions, when they are x months old. You can determine how  many months, and you can even set this to the very distant past if you want. The setting will never delete the original event in the series, only the recurrences. And typically it does not apply to events with fairly short durations, which yours sound like they are.

We also quite often have exceptions and/or events that are pulled out of the recurring event series – again, I’d assumed that once the events were generated, and pulled out of the series, the calendar would see them as regular events?

You have assumed correct. When an event is broken from the series it just becomes a standard event.

About the cleanup plugin, one thing I should clarify is that the one I shared is completely different than what you tried before. The last one was geared towards fixing that one specific bug mentioned at the outset, when you activated it it would go to work. But, due to how some servers had configured Cron it did not work for everyone. The plugin I shared is completely different. It will only show diagnostic info. It also allows you to quickly delete all recurrences for a single event series if the typical WordPress delete is timing out. But you can only perform this delete action manually. Just activating the new plugin should have no impact on your site, but it might yield some more valuable insights into what’s happening.

Please let me know if you have any more questions.

Cheers!

– Brook

[liblogger]

Thanks for clarifying all that.

I’ve removed the rogue recurring event, and the calendar month view does now display, although it’s still sluggish – I’ll look at cleaning up the database further, and will let you know if we have any further problems with the month view.

Thanks for your help!

[Brook]

Thanks for giving that a whirl.

You are very welcome for the assistance.

Cleaning up the database could be a good idea. The more posts there are in the wp_posts and wp_postmeta tables, the slower your entire site will run. In this case the only two options available are either:

1. Delete some of the posts.
2. Upgrade the server to one designed for that many posts.

So if you think a lot of posts are think your can delete, such as revisions, then doing so is probably the best next step. But if the site is still running slow, it might be time to upgrade the server. You can try doing a conflict test and see if the site continues running slow. If one or more plugins is causing the general slowness, it is possible they could be better optimized for your current server.

I’ll leave this open for a few weeks, just in case you have any more questions.

Cheers!

– Brook

[Support Droid]

Hey there! This thread has been pretty quiet for the last three weeks, so we’re going to go ahead and close it to avoid confusion with other topics. If you’re still looking for help with this, please do open a new thread, reference this one and we’d be more than happy to continue the conversation over there.

Thanks so much!
The Events Calendar Support Team

[Author]

Posts