The query I was testing with was simply of the form:
select pkcol from table where pkcol = pkval.
When running concurrent queries, the biggest deciding factor on throughput
seems to be the ndb-cluster-connection-pool. According to the manual, you
can set this value up to the # of cores on your box. These are 32 core
boxes, so 30 seemed fine. And with my testing, it handles anything up to a
concurrency of 30 just fine. So, it seems that the connection pool value
directly correlates to the amount of concurrency that mysqld node can
support (you technically can have more than this of course, but you will
start to suffer in performance).
However, it was my mistake -- The counters are working properly. The issue
IS due directly to the ndb-cluster-connection-pool, but I had failed to
test appropriately before posting here, so I apologize for jumping the gun.
The reason I saw all of the connections in threads_connected and show
processlist when I have a connection pool set to 1, is because it's
essentially bottlenecked with that 1 api node connection, so the queries
were slow enough to show clearly in the processlist/global status. However,
when I changed it to 30, the bottleneck was removed, and the queries were
processing too fast to show in either of those status variables.
So the point of this thread was if there was a way to monitor how many
clients are connected, really for the main purpose of monitoring if the
concurrency goes over 30, at which point the query result times begin to
suffer. The answer is yes, the threads_connected variable does indeed work
for this. At least, when correlated to the ndb_api_wait_nanos counter.
Thank you for your help! Please feel free to correct me, if any of my
findings above are incorrect.
On Wed, Apr 17, 2013 at 7:37 AM, Magnus Blåudd
> On 04/15/2013 02:45 PM, Raymond Peachey wrote:
>> Is it possible to actually monitor number of connected clients on your
>> mysql cluster when you have cluster connection pooling enabled?
>> For example, in our case we have a MySQL Cluster node with 32 cores, which
>> we've allocated 30 to use ndb connection pooling. When running a mysqlslap
>> with a concurrency of, say, 60, I do not see that value show in
>> threads_connected. Nor, do I see it show processlist.
>> When I remove the ndb connection pooling, I accurately see the processlist
>> showing all connected clients. I assume this is because of how the ndb
>> connection pooling, in essence (correct me if I'm wrong), a mysqld child
>> process that is used to connect to the cluster, which maybe is retaining
>> it's own counters?? Is my thinking correct here, or is there a documented,
>> alternate way of monitoring connected clients when using ndb connection
> The option --ndb-cluster-connection-pool controls how many connections the
> MySQL Server uses when talking to the NDB data nodes. I.e like the manual
> says "mimicking several MySQL Servers"
> This should not affect how many connections or threads your client
> application(for example mysqlslap) uses when connecting to the MySQL Server.
> Neither can I imagine that the values of threads_connected in any way is
> connected to the above configuration variable.
> Show some queries and the exact values used..
> Btw. I think that 30 is a high value... maybe too high? Check the MySQL
> Server log file for error messages while starting up and connecting to the
> / Magnus