-
Bug
-
Resolution: Fixed
-
Major
-
3.5.3, 3.6.1
-
MOODLE_35_STABLE, MOODLE_36_STABLE
-
MOODLE_35_STABLE, MOODLE_36_STABLE
-
MDL-64400-master -
This is what we discovered on moodle.org site. The "notifications" table, introduced in May 2018 as a part of MDL-36941, now contains around 5.3 millions records. The whole table has around 18 GB of data as reported by MySQL:
mysql> SELECT table_name AS `Table`, round(((data_length + index_length) / 1024 / 1024), 2) `Size in MB` FROM information_schema.TABLES WHERE table_schema = "moodleorg" AND table_name = "notifications";
|
+---------------+------------+
|
| Table | Size in MB |
|
+---------------+------------+
|
| notifications | 17828.38 |
|
+---------------+------------+
|
The table takes significant part of the database dump size. All operations in it (such as personal data access requests etc) take long time and has caused us various troubles recently.
We have had the $CFG->messagingdeletereadnotificationsdelay set for a short period (one day) to avoid this kind of bloating before. But this setting did not seem to help us any more to keep things under control.
I was looking at it quickly and I have a suspicion now that forum post notifications that are being emailed via the email output processor, are not set as read in the notifications table. So if there is a discussion with 100 subscribed users (via email notifications) and someone posts into that discussion, we create 100 notification records in this table (each holding the copy of the whole forum post) and send them via email. But we never set the "timeread" value so it remains NULL and the task that deletes read notifications, never removes them.
As a result, the table bloats quickly.
This is seen as a serious issue for us with significant performance impacts. Let me suggest to:
- Change the behaviour so that once the notification is sent via email output processor, it is marked as read in the notifications table. If someone has both email and popup / mobile notifications enabled, I don't think it is expected to have the notification still marked as unread if it is already in the INBOX.
- Introduce a new setting next to the existing "messagingdeletereadnotificationsdelay" that would allow to define a period after which we delete all notifications, both read and unread. The default value can be quite high here, such as 3 months. I believe that after 3 months, most notifications are outdated anyway.
- caused a regression
-
MDL-65173 Marking notification as read simply because it was emailed is potentially wrong logic
- Closed