tag:blogger.com,1999:blog-375697951860081841.post7187987959505669729..comments2008-12-11T07:20:53.164ZJonathanhttp://www.blogger.com/profile/17336586681878234499BoogyBo@gmail.comBlogger4125tag:blogger.com,1999:blog-375697951860081841.post-74512857137271701622008-12-11T07:20:53.164Z2008-12-11T07:20:53.164ZYou might want to set the --max-connections to something lower, so you make sure scripts don't run amok.<BR/><BR/>Also, make sure that no client application uses SUPER privilege, so you can always connect to the MySQL server when max_connections -1 has been reached.Geert JM Vanderkelenhttp://www.blogger.com/profile/00145367107699066606noreply@blogger.comtag:blogger.com,1999:blog-375697951860081841.post-41042230022384730222008-12-11T02:38:28.707Z2008-12-11T02:38:28.707ZYou really think prepared statements killed your database? ...really?Ms. Anthropenoreply@blogger.comtag:blogger.com,1999:blog-375697951860081841.post-27768002420417993322008-12-10T22:38:06.229Z2008-12-10T22:38:06.229ZFrom your post, It doesn't seem to be a problem with prepared statements as much as it does with the perl/php code that was opening connections. If the code was performing the same table lock the prepared statement was, the result could very well have been the same. <BR/><BR/>Although, I guess the developers might not have attempted to open all of the connections, if they had a little more transparency as to what was going on in the prepared statements.water outbreakshttp://www.blogger.com/profile/16957222317299096782noreply@blogger.comtag:blogger.com,1999:blog-375697951860081841.post-90113495718373707972008-12-10T22:06:52.421Z2008-12-10T22:06:52.421ZHi!<BR/><BR/>Did you turn them on purpose? Most of the drivers have them disabled (for the reason you mention).<BR/><BR/>Cheers,<BR/> -BrianBrian Akerhttp://www.blogger.com/profile/10779939131479683690noreply@blogger.com