The above reply from me can be dismissed, for I now better understand why you refer to it as custom work @LeonidS

I run a complete analysis and found that it has nothing to do with custom work, also an old issue, but only started to show when volumes escalated from 18 March 2026, when the server really picked up on traffic(more site visitors) 

Logs indicate a few vital clues: The bx_ntfs_* tables are missing, and vanilla cron.php(hardcoded) runs BxNtfsCronQueue regardless, which is why we never really picked it up until the server got spiked hard by site users/visitors plus FPM Max_children(PHP).

I have an idea but wanted to know from you first since it is a /boonex/notifications issue.

(In simple english: Let's say the "Groups" module is problematic right. If I deactivate/uninstall and than delete it, so will all related users data be deleted. But there are times when we can save the "Groups" modules in other ways provided we are able etc.

Now "Groups" holds on to some data that has business values whereas Notifications that can only be installed during the initial core installation , has no uninstall/reinstall so to speak and that the data in our case no data risks include, seemingly making not that difficult to fix the missing table.

As for the hardcoded cron that is not checking the module status and simply run regardless, has contributed to the persistent and escalated growth in PFM max_childrens. (But to add, looking from our audit report in studio, is our periodic cronsjobs that run on intervals, up to date as planned and configured, so don't think we've not setup any cronjobs)