2

I have a single db.m5.large RDS instance running in my aws setup. When I check for max connection from mysql console, with bellow query.

mysql> show variables like 'max_connections'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 624 | +-----------------+-------+

So I am assuming that, it can handle 624 connections.

And when I check for max used connections with bellow query.

mysql> SHOW STATUS WHERE `variable_name` = 'Max_used_connections'; +----------------------+-------+ | Variable_name | Value | +----------------------+-------+ | Max_used_connections | 99 | +----------------------+-------+

I am assuming that there are 99 active connections and rest are free.

But, my AWS alarm system and RDS monitoring system shows its taking 90+ db connections. But my RDS CPU consumption is only 8% at the same time. Does this alarm/monitoring is just the number or the average max connection count?

I am little worried about this, that my server might stop after reaching max connection(100) after some time.

Could any one tell/explain bellow

  1. How to check actual max connections available and current connection count.
  2. What are metric measure means? (just current connection count or average connection count?)
  3. How to overcome from this?
    1. If I want to increase max connections what I should do?
    2. Do I need to reduce connections from app side?
Improve this question
1

1 Answer 1

Reset to default
2

max_connections = 624 says that it will allow that many connections. It probably can't handle that many at once.

Max_used_connections = 99 means that at some time since startup, there were 99 connections. However, they may have been sitting idle waiting for the application (or user) to issue a query.

Threads_running is an instantaneous count of how many connections are actually doing something at the moment. A few dozen is a "high" number for this. However, this is a fleeting count, so watching it is more intrusive than useful.

A well oiled MySQL server will use only 8% of the CPU (or some number much less than 100%).

In general, you should try to reduce connections from the app side. This can be achieved by

  • Having the app disconnect when finished
  • Lower wait_timeout -- to boot out connections that fail to disconnect.
  • Decrease max_connections -- but this is rather drastic
  • Decrease the number of "threads" (or whatever) the app launches. This is, for example, configurable in Apache.

The various metrics you propose are not 'actionable', so I won't try to concoct how to measure them.

If your app runs slow, that is a clue to look around. The slowlog is my "goto" place -- it not only says that there was trouble, but indicates which query is the "worst" (after using some digest).

If you would like a review of the hundreds of VARIABLES and GLOBAL STATUS, see this for the info I need. There are about 200 potential red flags that it looks for.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.