Tuning Your DBMS Automatically with Machine Learning
aws.amazon.com
Tuning Your DBMS Automatically with Machine Learning
1–10 of 25 posts
Re: Tuning Your DBMS Automatically with Machine Learning
#2Technically there is a perl tool to make recommendations for mysql settings - although not with AI.
As a DBA, I would probably use this, but 80% of the performance improvements come from indexing, fixing bad data models and archiving - especially with RDS where the options for performance optimization are limited.
Re: Tuning Your DBMS Automatically with Machine Learning
#3Technically there is a perl tool to make recommendations for mysql settings - although not with AI. As a DBA, I would probably use this, but 80% of the performance improvements come from indexing, fixing bad data models and archiving - especially with RDS where the options for performance optimization are limited.
It would be interesting to see this work expanded to include some of those factors; Namely indexing and archiving. Bad data models seem like a whole other beast, but indexing and archiving should be possible to generate good configuration suggestions for if you had a full history of DB usage trends along with what you were hoping to optimize for.
Re: Tuning Your DBMS Automatically with Machine Learning
#4Technically there is a perl tool to make recommendations for mysql settings - although not with AI. As a DBA, I would probably use this, but 80% of the performance improvements come from indexing, fixing bad data models and archiving - especially with RDS where the options for performance optimization are limited.
I assume you are referring to this project [1].
Re: Tuning Your DBMS Automatically with Machine Learning
#5On GitHub: "No description, website, or topics provided."
In the article: "and collects its Amazon EC2 instance type and current configuration"
... and I switched off.
I recently diagnosed a MySQL latency snag on a well known cloudy platform for a customer. I run rather a lot of comparative bonnie++, MySQL bench and Lord knows what else. I was able to convince the customer that my office PC ran MariaDB better simply because my single SSD on a rather shag Lenovo PC (a cast off from another customer!) had better i/o and latency than whatever they were being given by said cloudy provider.
I suggest you start with the basics: CPU, RAM, disc I/O and latency, network I/O and latency. Optimise those first and then work up the stack (and down, then back up etc.)
If you start with "assume a spherical EC instance" you may not be considering the whole problem -> solution -> realisation thing.
Re: Tuning Your DBMS Automatically with Machine Learning
#6Technically there is a perl tool to make recommendations for mysql settings - although not with AI. As a DBA, I would probably use this, but 80% of the performance improvements come from indexing, fixing bad data models and archiving - especially with RDS where the options for performance optimization are limited.
Any techniques, recommendations, and/or open source tools to simplify the archiving step you mentioned?
Re: Tuning Your DBMS Automatically with Machine Learning
#7So cool! Its not hard to image this same technique used on clouds to tweek infastructure for workloads.
Re: Tuning Your DBMS Automatically with Machine Learning
#8Reminds me of this:
https://blog.acolyer.org/2017/01/17/self-driving-database-ma...
Re: Tuning Your DBMS Automatically with Machine Learning
#9Reminds me of this: https://blog.acolyer.org/2017/01/17/self-driving-database-ma...
Yep! Peloton is by the same people.
Re: Tuning Your DBMS Automatically with Machine Learning
#10Technically there is a perl tool to make recommendations for mysql settings - although not with AI. As a DBA, I would probably use this, but 80% of the performance improvements come from indexing, fixing bad data models and archiving - especially with RDS where the options for performance optimization are limited.
Any techniques, recommendations, and/or open source tools to simplify the archiving step you mentioned?
That's one of those things where money can go a long way quickly - fat i/o (including network if you're off-loading, sharding, peering, vdbs etc.), good cpu, efficient log sizes. Sticking to the basics is probably the best - if you're running high transaction and data change rates then the collective throughput "off" of your transaction server(s) is every bit as important as the throughput "on" the server(s).