Sorry no Linux box can be enter to this location, this was the first suggestion we made
but the NHS reject is.
I will check the server tomorrow, I am in UK and it is after working hours.
From: Shawn Green [mailto:shawn.l.green@stripped]
Sent: Tuesday, October 23, 2012 7:24 PM
To: Tal Ben-Gal
Subject: Re: mysql threads too high
On 10/23/2012 1:13 PM, Tal Ben-Gal wrote:
> If I turn the pooling off the connection going up the roof, none stay sleep, I have
> about 40 queries per min for each connection, its take long time to open the connection,
> some of the queries are very complex and involve lots of join and some on 2 different
> Opening one connection at the time (and close it - yes with .close - it been tried.)
> is not an option, as it is slowing the application drastically.
> It is windows base application, there is no 'block' of quires, users can't go any
> farther until the query finish, furthermore some queries are background work that need to
> update the user screen every 5 Min.
> The application been tested with all the option you suggested and the
> best solution is with pooling, the application running in 4 locations, no problem on
> 3 of them Only one location having this problem. The one we have the problem is the most
> powerful server 12GB memory and 12 core CPU.
> This application is for the NHS and lots of testing done on it to see the best
> solution, and it is running on 2 locations (about 300 users in each) with no problem.
> The location that having this problem is actually the one with fewer users, only
> The My.ini is identical in all location, the application identical in all location.
> Could it be the server too fast??!!
> No, changing the application now can't be done - it will require NHS approval all
> over again - it is running fine on 3 locations.
That kind of throughput reduction is nearly always hardware based. As your code has not
changed, your MySQL version is not any different, your query patterns are alike, and your
configurations are probably very similar, then that leaves the hardware as the next
logical place to look.
You asked "Could it be the server too fast??!!" This machine wouldn't happen to be using
the NUMA architecture, would it? If so, the way it maps our memory allocations may be
creating a HUGE volume of cross-zone access requirements. The solution would be to break
your MySQL data down into pieces that require less cross-talk between memory zones or get
some hardware that is not NUMA-based.
As a test, put it on a reasonably powerful Linux box and see how that handles the load.
This post represents the limit of free advice I can give on this topic.
MySQL Principal Technical Support Engineer Oracle USA, Inc. - Hardware and Software,
Engineered to Work Together.
Office: Blountville, TN
This e-mail message is intended to be received only by persons entitled to receive the
confidential information it may contain. E-mail messages to clients of ben-gal.net may
contain information that is confidential and legally privileged. Please do not read,
copy, forward, or store this message unless you are an intended recipient of it. If you
have received this message in error, please forward it to the sender and delete it
completely from your computer system. For more information please e-mail tal@stripped