On 10/11/2012 10:07 AM, Tal Ben-Gal wrote:
> Thanks, I try to change it but it made no different, after 1250 mysql threads, no one
> can connect to the database.
> In the new ini:
You have to realize that once you overload your system with RAM requests
and start to use the page file, that all those activities that used to
be operating at RAM speed are now operating at DISK speed. That's a
performance reduction on the scale of 100x to 10000x slower than before.
There are several ways to fix this:
1) Start refusing connections once you reach a number that causes your
system to begin using swap (system paging file). You control this by
configuring a reasonable value for --max-connections (Hint: unless you
have several hundred gigabytes of RAM in this one machine, 3510 is not a
2) Adjust your memory allocation settings to something more reasonable.
Remember, some values are allocated once for the entire server (global)
and some are per thread (local). You must multiply the number of local
allocations by the number of active threads you allow (max_connections)
in order to get an upper-limit estimate of RAM usage just for your
threads. Add that to your global allocations to get an upper estimate
of how much RAM you will use in total.
3) Fix your queries. If they ran faster, you would be able to handle
more queries every second. For example, if you start a query every .5
seconds and each of them takes an average of 1s to compute then you will
need a lot of connections as all of your queries are overlapping. If you
can reduce your average execution time to something less than .5 seconds
(say in the .1 second range) then you can handle at least 500% more
queries every second than you had before you tuned your queries. You
will need at least 10x fewer connections than you did under the original
All of these points (and more) are covered in the MySQL manual:
MySQL Principal Technical Support Engineer
Oracle USA, Inc. - Hardware and Software, Engineered to Work Together.
Office: Blountville, TN