Calendar Fatal Error Allowed memory exhausted

Hello,

My Production System.
Version 7.12.7
PHP: 7.3
Apache:
post_max_size: 50MB
upload_max_filesize: 50MB
max_execution_time: 30
memory_limit = 512MB

When moving through the shared calendar (clicking the < and > buttons) some of the months are ending up with a blank screen. The log file is show thing:

PHP Fatal error:  Allowed memory size of 536870912 bytes exhausted (tried to allocate 36864 bytes) in Unknown on line 0, referer: https://crm.kwikom.com/index.php?action=index&module=Calendar&view=sharedMonth&&year=2019&month=12&day=1&hour=0

It only takes about 10 seconds and I get the error.

In the settings I have unchecked the Shared Calendar Separate.
Start Time: 08:00
End Time: 19:00
Show Calls, Show Task and Show Completed, Meetings and Tasks are set to Yes.

I have been importing old Cases from an old ticketing system and generating Meetings when meeting has been marked in the old ticket system.

It has crossed my mind that maybe there is some bad data in the Meetings table that might cause this but I am not finding anything that stands out as being bad data. In some cases there are no records for the day/week/month.

As an example, my URL is this:

https://crm.kwikom.com/index.php?action=index&module=Calendar&view=sharedDay&&year=2019&month=11&day=12&hour=0

I manually changed the day from 1-30. The days 6-11 caused and error. Day 19 works.

Looking in the meetings table to make sure the parent_id matched shows there is a parent record for each meeting.

SELECT `meetings`.`id`,`meetings`.`date_start`,`meetings`.`parent_id`,`meetings`.`parent_type`, `cases`.`case_number`
FROM `meetings` 
LEFT JOIN `cases` ON `meetings`.`parent_id` = `cases`.`id`
WHERE `date_start` >= '2019-11-01 00:00:00' AND `date_start` <= '2019-12-01 00:00:00';

id	                                    date_start	        parent_id	                            parent_type	case_number	
11c67bb7-2442-4531-5a14-63da889bb878	2019-11-06 18:00:00	d43759f3-c987-8c02-dd74-63da88c007d4	Cases	    82538	
44986be3-bb5e-eb6e-20c9-63da89f89d01	2019-11-06 21:00:00	4534de35-710b-3387-e06b-63da891affce	Cases	    82562	
7a05350a-ddbe-9ece-7f38-63da895a873e	2019-11-06 22:30:00	e71ad9ea-c798-5679-a06d-63da89024fc8	Cases	    82563	
970464c0-a0de-e892-0109-63da8a6fb256	2019-11-06 23:00:00	20112bff-cfbf-bf6b-29c7-63da8aa27d6a	Cases	    82675	
a6950cd9-4f83-749e-6967-63da8abd103e	2019-11-06 23:30:00	d8412802-4943-f35c-05db-63da8a7765e4	Cases	    82690	
7e927329-a046-80fa-32b9-63da88239cfe	2019-11-07 14:00:00	7bbb7cdf-8693-a2c3-d272-63da8851ba30	Cases	    82477	
964c8680-bef9-9391-c06f-63da8a2163a8	2019-11-07 16:30:00	4e416ab6-73ea-2ca0-63d9-63da8a6ca7cd	Cases	    82614	
b7b9289e-d62d-692e-c458-63da8861f50e	2019-11-07 19:00:00	20f88d03-7ccc-106b-3154-63da884aa403	Cases	    82492	
710e042e-2641-0197-0faa-63da8b77a21e	2019-11-07 22:00:00	bf990dec-ab1c-2862-a7e3-63da8b0e0863	Cases	    82699	
62e6cc52-0339-b20c-8ac0-63da8b837538	2019-11-08 00:00:00	3b1fdcac-aaef-4b80-0b65-63da8b8f854d	Cases	    82702	
3f760173-5e5f-b783-5664-63da8c30b1b3	2019-11-19 16:00:00	c7bd8164-da62-c753-dbca-63da8c1de4c7	Cases	    82810	

The reset of the meetings fields other than id’s, dates and duration fields are all the same.

Any suggestions for ideas?

Tony

I would start by running the first query in this post to check for overgrown tables in the database:

Then I would turn on “slow queries” logging in system settings (more info) and see if your problem is too much data getting returned.

I find it strange that handling the returns of a simple query would require 512Mb of memory. Another possibility is that something is causing an infinite loop, and your memory gets progressively exhausted.