wrong img path results in too many sql connections

[modxbot]

smooth-graphics created Redmine issue ID 5825

I updated a website today and after updating the chunk my server went down dompletely due to overload of SQL connections.

I now found sth out: I have an image path inside the chunk. This image is thumbnailed using phpthumbof and the autofiximagesize plugin. After changing a incorrect filname (was 'img.png_sw') to 'img_sw.png' site immediately works again.

Here's the complete error log:

[2011-09-30 18:36:51] (ERROR in xPDO::connect @ /var/www/vhosts/publishing-conference.de/httpdocs/core/xpdo/xpdo.class.php : 344) SQLSTATE[08004] [1040] Too many connections
[2011-09-30 18:36:51] (ERROR in xPDO::connect @ /var/www/vhosts/publishing-conference.de/httpdocs/core/xpdo/xpdo.class.php : 344) SQLSTATE[08004] [1040] Too many connections
[2011-09-30 18:36:51] (ERROR @ /index.php) Error preparing statement for query: SELECT `modSession`.`id` AS `modSession_id`, `modSession`.`access` AS `modSession_access`, `modSession`.`data` AS `modSession_data` FROM `modx_session` AS `modSession` WHERE `modSession`.`id` = ?  - 
[2011-09-30 18:36:51] (ERROR in xPDO::connect @ /var/www/vhosts/publishing-conference.de/httpdocs/core/xpdo/xpdo.class.php : 344) SQLSTATE[08004] [1040] Too many connections
[2011-09-30 18:36:51] (ERROR in xPDO::connect @ /var/www/vhosts/publishing-conference.de/httpdocs/core/xpdo/xpdo.class.php : 344) SQLSTATE[08004] [1040] Too many connections
[2011-09-30 18:36:51] (ERROR @ /index.php) Error preparing statement for query: SELECT modAccessContext.id, modAccessContext.target, modAccessContext.principal, modAccessContext.authority, modAccessContext.policy, Policy.data FROM `modx_access_context` AS `modAccessContext` LEFT JOIN `modx_access_policies` `Policy` ON `modAccessContext`.`policy` =  `Policy`.`id` WHERE  ( `modAccessContext`.`principal_class` = ? AND `modAccessContext`.`target` = ? )  ORDER BY modAccessContext.target,modAccessContext.principal,modAccessContext.authority,modAccessContext.policy ASC  - 
[2011-09-30 18:36:51] (ERROR in xPDO::connect @ /var/www/vhosts/publishing-conference.de/httpdocs/core/xpdo/xpdo.class.php : 344) SQLSTATE[08004] [1040] Too many connections
[2011-09-30 18:36:51] (ERROR in xPDO::connect @ /var/www/vhosts/publishing-conference.de/httpdocs/core/xpdo/xpdo.class.php : 344) SQLSTATE[08004] [1040] Too many connections
[2011-09-30 18:36:51] (ERROR @ /index.php) Error preparing statement for query: SELECT `modResource`.`id` AS `modResource_id`, `modResource`.`type` AS `modResource_type`, `modResource`.`contentType` AS `modResource_contentType`, `modResource`.`pagetitle` AS `modResource_pagetitle`, `modResource`.`longtitle` AS `modResource_longtitle`, `modResource`.`description` AS `modResource_description`, `modResource`.`alias` AS `modResource_alias`, `modResource`.`link_attributes` AS `modResource_link_attributes`, `modResource`.`published` AS `modResource_published`, `modResource`.`pub_date` AS `modResource_pub_date`, `modResource`.`unpub_date` AS `modResource_unpub_date`, `modResource`.`parent` AS `modResource_parent`, `modResource`.`isfolder` AS `modResource_isfolder`, `modResource`.`introtext` AS `modResource_introtext`, `modResource`.`content` AS `modResource_content`, `modResource`.`richtext` AS `modResource_richtext`, `modResource`.`template` AS `modResource_template`, `modResource`.`menuindex` AS `modResource_menuindex`, `modResource`.`searchable` AS `modResource_searchable`, `modResource`.`cacheable` AS `modResource_cacheable`, `modResource`.`createdby` AS `modResource_createdby`, `modResource`.`createdon` AS `modResource_createdon`, `modResource`.`editedby` AS `modResource_editedby`, `modResource`.`editedon` AS `modResource_editedon`, `modResource`.`deleted` AS `modResource_deleted`, `modResource`.`deletedon` AS `modResource_deletedon`, `modResource`.`deletedby` AS `modResource_deletedby`, `modResource`.`publishedon` AS `modResource_publishedon`, `modResource`.`publishedby` AS `modResource_publishedby`, `modResource`.`menutitle` AS `modResource_menutitle`, `modResource`.`donthit` AS `modResource_donthit`, `modResource`.`privateweb` AS `modResource_privateweb`, `modResource`.`privatemgr` AS `modResource_privatemgr`, `modResource`.`content_dispo` AS `modResource_content_dispo`, `modResource`.`hidemenu` AS `modResource_hidemenu`, `modResource`.`class_key` AS `modResource_class_key`, `modResource`.`context_key` AS `modResource_context_key`, `modResource`.`content_type` AS `modResource_content_type`, `modResource`.`uri` AS `modResource_uri`, `modResource`.`uri_override` AS `modResource_uri_override` FROM `modx_site_content` AS `modResource` WHERE  ( `modResource`.`id` = ? AND `modResource`.`deleted` = ? )   - 
[2011-09-30 18:36:51] (ERROR in xPDO::connect @ /var/www/vhosts/publishing-conference.de/httpdocs/core/xpdo/xpdo.class.php : 344) SQLSTATE[08004] [1040] Too many connections
[2011-09-30 18:36:51] (ERROR in xPDO::connect @ /var/www/vhosts/publishing-conference.de/httpdocs/core/xpdo/xpdo.class.php : 344) SQLSTATE[08004] [1040] Too many connections
[2011-09-30 18:36:51] (ERROR @ /index.php) Error preparing statement for query: SELECT `modSession`.`id` AS `modSession_id`, `modSession`.`access` AS `modSession_access`, `modSession`.`data` AS `modSession_data` FROM `modx_session` AS `modSession` WHERE `modSession`.`id` = ?  - 
[2011-09-30 18:36:51] (ERROR in xPDO::connect @ /var/www/vhosts/publishing-conference.de/httpdocs/core/xpdo/xpdo.class.php : 344) SQLSTATE[08004] [1040] Too many connections
[2011-09-30 18:36:51] (ERROR in xPDO::connect @ /var/www/vhosts/publishing-conference.de/httpdocs/core/xpdo/xpdo.class.php : 344) SQLSTATE[08004] [1040] Too many connections
[2011-09-30 18:36:51] (ERROR @ /var/www/vhosts/publishing-conference.de/httpdocs/core/cache/includes/elements/modplugin/4.include.cache.php : 57) PHP warning: getimagesize(http://publishing-konferenz.de/assets/images/image.png_sw) [function.getimagesize]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found

[2011-09-30 18:36:51] (ERROR @ /var/www/vhosts/publishing-conference.de/httpdocs/core/cache/includes/elements/modplugin/4.include.cache.php : 57) PHP warning: getimagesize(http://publishing-konferenz.de/assets/images/image.png_sw) [function.getimagesize]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found

This last message appeared 100 of times on…

This is a blocker. No error like this should result in a overload!

[modxbot]

smooth-graphics submitted:

Of course, I'm not entirely sure if the bug is really caused by the wrong image tag.

I had this once before on another server and modx setup with a resource: After deleting the resource and undelete after it had worked there again. Not sure what was the problem there.

[salscode]

thekiller237 submitted:

I saw this before also and just brushed it off (should have reported it I know, thank you Anselm). It didn't crash our server but still seems like an issue or concern.

[modxbot]

smooth-graphics submitted:

So you don't think it's a blocker it the CMS can kill a server completely?

[modxbot]

rethrash submitted:

Blocker is a reserved status meaning every single instance of MODX out there is experiencing this problem right now. Your issue is critical and we very much appreciate the report.

[modxbot]

smooth-graphics submitted:

Okay, thanks for clarifying.

[modxbot]

smooth-graphics submitted:

Okay, it's not related to wrong image paths. Now have this error again(!!!!) on another setup. This time simply edited a chunk and did a FormIt call. Server gone down again due to overload of mySQL connections.

This is a server-killer. Never had such a buggy version of MODX!

[modxbot]

smooth-graphics submitted:

This time session resets automatically all the time. Sometimes I get the callback error that user wasn't found. Server overload again and again from MODX.

[modxbot]

smooth-graphics submitted:

Still can't work on this setup. Goes down from time to time when accessing the frontend. No error output in manager error log. So this seems not to be related to a snippet or wrong path but a core / or caching problem?!

[opengeek]

opengeek submitted:

It sounds too me like this server simply does not have enough MySQL connections available to support the application. You could try disabling the database session handler (set the _session_handlerclass System Setting to empty) and see if that reduces the load enough, or work with your hosting provider to increase the number of available connections.

[modxbot]

smooth-graphics submitted:

Why does MODX need so many connections? Is it possible to restrict the connections in MODX itself? Should be.

[modxbot]

jeroenkenters submitted:

Today a 2.0.7 site had similar problems; lots of mysql processes after the client logged into the manager. After updating to 2.1.3 everything seemed fine for a while, but the problem came back. Turned out resource 8 had 33 as parent and resource 33 had 8 as parent (race condition). Something that should never happen. After fixing this (deleting 8 and assign 0 as parent for 33) the problem was over.

[opengeek]

opengeek submitted:

Jeroen Kenters wrote:

Today a 2.0.7 site had similar problems; lots of mysql processes after the client logged into the manager. After updating to 2.1.3 everything seemed fine for a while, but the problem came back. Turned out resource 8 had 33 as parent and resource 33 had 8 as parent (race condition). Something that should never happen. After fixing this (deleting 8 and assign 0 as parent for 33) the problem was over.

Yeah, this sounds like the OP may be experiencing something similar, perhaps caused by a problem outside of the normal operation of MODX.

Anselm Hannemann wrote:

Why does MODX need so many connections? Is it possible to restrict the connections in MODX itself? Should be.

MODX Revolution does use more connections than Evolution did, because of the way the manager is constructed (small, modular AJAX requests), but we run it on a number of reasonably configured servers with no issues regarding the number of available connections.

[modxbot]

smooth-graphics submitted:

Jason Coward wrote:

Jeroen Kenters wrote:

Today a 2.0.7 site had similar problems; lots of mysql processes after the client logged into the manager. After updating to 2.1.3 everything seemed fine for a while, but the problem came back. Turned out resource 8 had 33 as parent and resource 33 had 8 as parent (race condition). Something that should never happen. After fixing this (deleting 8 and assign 0 as parent for 33) the problem was over.

Yeah, this sounds like the OP may be experiencing something similar, perhaps caused by a problem outside of the normal operation of MODX.

If it's the same problem that was on my server: no actions except in MODX manager. Really.

Anselm Hannemann wrote:

Why does MODX need so many connections? Is it possible to restrict the connections in MODX itself? Should be.

MODX Revolution does use more connections than Evolution did, because of the way the manager is constructed (small, modular AJAX requests), but we run it on a number of reasonably configured servers with no issues regarding the number of available connections.

But is it normal that MODX uses over 20 persistent mySQL connections at a time?

[opengeek]

opengeek submitted:

There are no persistent connections being used. It lets go of them when done.

There are quite a few things being loaded in the manager on some of the full page loads, so yes, there may be as many as 20 connections triggered by a single request in the manager in some places, but they are very short, quick connections with only one or two queries a piece.

[modxbot]

smooth-graphics submitted:

Hm. Jeroen had 20+ connections persistently firing(!) from MODX this afternoon.

[modxbot]

jeroenkenters submitted:

It happened again on another (2.0.8) site today. Server load went crazy. Lots of MySQL processes. 2 resources had each other as parent again. Fixed one and everything went back to normal again.

If you want to reproduce our problem; just change 2 resources (using phpMyAdmin or something similar) so they have each other as parent. Not sure how this situation occurred, but it does cause some serious trouble.

[opengeek]

opengeek submitted:

This must be possible via a bug that is already addressed in subsequent releases; I cannot reproduce the parent as self behavior no matter how hard I try.