I have noticed that my mysql instance on Amazon's RDS is running quite slow. When I run:
SELECT NOW()
From my local computer, it takes 0.2ms to run. When I run that same query on rds, it takes 35.1ms to run -- even running these multiple times to rule out caching it's about that value.
What are some things I can do or tools I can use to figure out why the rds server is running so slow?
Related
I have a product built with laravel, with multi-tenancy.
Deployed on EC2 instance and using AWS RDS as the database server.
I am currently having around 100 databases on the production.
Laravel's hyn tenancy module is handling the connections.
Now, the problem is for each tenant after some idle time, the first request takes too long. around 15-20 seconds. and after that, it works smoothly.
In the test environment, we are not using RDS but a local MySQL instance. and the problem does not occur in the test environment. the only difference between test and production is the AWS RDS.
I have looked into max connections, query cache, and so on... but no luck so far.
Any suggestions?
The solution will depend on what kind of RDS you have.
I assume it's serverless (more common). In that case, there's a setting for min and max for ACU. It will (I believe) go down to zero by default if the DB is not accessed in a while. Check that and see if it is properly set.
If you have a Provisioned DB, then it's more complex. It will start caching things once queries are executed but until a particular query is run, you will be waiting for the DB to "wake up" and run a full query.
Check this page for relevant info.
I have a RDS MySQL Aurora DB(db.t2.medium) hosted in us-east region
A select query returning around 25k(5 MB) rows is taking around 3 mins.(When executed by my back-end(same VPC as DB) and executed by me via MySQL workbench from India)
Same query on the dump of same db on my local is taking around < 2 seconds(using MySQL workbench) and is returning same no of rows(25k).
I've checked out the CPU utilisation metrics of my db instance and there are no spikes/surprises there.
My db is hosted in us-east region and I am executing the query from India using MySQL workbench.
One thing to note that when the query is executed by my backed on db(they are in the same VPC) still the query is exactly slow.
When i hit the query from India via MySQL workbench to my RDS instance the duration time is under a second but the fetch time is around 3 mins(with or without VPN).
duration vs fetch
When i hit the same query on dump of same db on my local, the duration is almost same but the fetch time is around 1 second(same no of rows).
I am not sure why there is no much of difference is fetch time?
Im using the official mysql node module in a node module.
The connecting to the database happens instantly. When I execute a query though, t takes almost ten/twenty seconds for a response. The next time the query (identical SQL) is executed it is near instantaneous.
This only happens on my local machine (speaking to the same mysql database) but not on my production server(where the mysql database is located).
I had to edit my timeout values on my local machine to allow the queries to not timeout.
Edit: to clarify, I am not running a local db. I'm speaking to the production DB when I'm running from my local machine.
What could be happening here?
I have a a query which only takes 0.004s on my development machine (Windows 7 running WampServer on an HDD) but takes 0.057s on my production server (CENTOS 6.5 running on an SSD) -- a difference of 14x. Both MySQL versions are the same.
The explain results are identical on both servers, as are the databases (I exported the database from my production server and imported it into my development machine). I also ran optimize table on both servers, and tried putting in SQL_NO_CACHE, but that didn't make a difference on either one.
Navicat shows this under the Profile tab:
Production
Development
The execution times for the queries are consistent on both servers.
The database versions are the same, the content is the same, and the explain results are the same. Is there any way to determine why the query is taking 14x longer on my production server?
EDIT: In an attempt to determine if the MySQL server is under load, I found the Process List area in Navicat and can see that there are only a few processes, all of which are for "Sleep" commands. So I don't think the production server is under any load.
The production server seems to be slower in every parameter listed. There could be many factors involved, so you should check each one:
First of all, check if there is any other load on the production server. Is the server doing something else in the meanwhile? Use Linux command top to see running process and check if any of them is using a lot of computing power. Use the MySQL command SHOW STATUS to get info about the MySQL server status (memory, open tables, current connections, etc.)
Check the hardware: nowadays some desktop PCs are more powerful than cheap virtual servers (CPU, RAM frequency and access times, ...)
MySQL could use different settings in the two environments
Make sure you have the same indexes on both databases.
I have found out that MySQL on EC2 (Ubuntu 12.10) could be extremely slow.
It takes just 700ms for a certain set of SQL queries to perform on my local PC (Windows 7), whereas on EC2 it requires more than 13sec.
The database is very small, just 12MB. There is almost no disk IO during the query.
Nevertheless, EC2 instance is 20 times slower.
All the databases are based on the same dump: same tables and same indexes. The queries return the same results.
The only difference is the execution time.
I tried M1.small and M2.xlarge (which has 7 times more computing power than M1.small) - the outcome is the same: queries take almost the same time on both servers and both are extremely slow.
Why could this happen?
The problem was with MySQL 5.5 which executes subqueries inefficiently.
My home PC run MySQL 5.6 which is far better in this regard.
So I upgraded MySQL on EC2 to version 5.6 and it became almost as fast as my home PC (as far as only one simultaneous query is concerned).