• Halloween is coming! To celebrate the occasion, we dusted off a couple of old skins, and even created a brand new one (Pixel).
    To get into the festive spirit, install the Skins extension.
  • The new Python extension is now available. It allows customers to deploy and manage WSGI-based Python applications on their websites directly from Plesk.
  • The Plesk Mobile apps for iOS and Android and the Plesk Mobile Center extension have been deprecated, and are no longer available for new installations. In Plesk Obsidian 18.0.84, the Plesk Mobile Center extension will be removed from servers during the upgrade, and the Plesk Mobile apps will lose their server management features.
  • The Social Login extension has been deprecated and will be removed in Plesk Obsidian 18.0.84. After that, it will no longer be possible to log in to Plesk with a Google, Facebook, GitHub account, or with a passkey. Plesk usernames and passwords, as well as logging in with a WebPros Account, are not affected.

SQL too many connections

Z

ZAPP!?

Guest
Hi!


Does anybody here have an idea about how to advance the max sql connection limit from from 100 to X for only one account and not for the whole server?

ZAPP
 
It can't be done for a single user. I would take a look at the queries that user is executing and turn on slow query logging and try to eliminate the queries with the highest amount of contention.

Tweaking max-connections is often server suicide because each connection has fixed buffers and you can very quickly exceed physical RAM and force the server into swap thrashing. Also keep in mind the less free physical RAM the more the performance of mysql will suffer, because mysql doesn't have it's own buffering mechanism for the database files -- it depends on the OS buffer cache. The OS buffer cache will decrease in size as memory demand increases. It is usually a vicious cycle.

In short, you have to address the query contention issues (which is very common with mysql). If there is a very common table in the web application that is large and many queries are doing full scans then that is likely a potential problem table. I have seen a few cases like this where people were using LIKE to do pattern matching, and the simple solution was to change it to a full text index and use the MATCH() clause.
 
we use a php anti-leech script, mainly for our downloads, so every downloader must have a "sql-connection" until he have finished the download.

ive found a usefull topic right here: http://forum.swsoft.com/showthread.php?s=&threadid=15822


i hope it works! ;)

edit:
here's the proof:
test22pl3.jpg
 
Back
Top