New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MariaDB / MySQL peformance #46
Comments
|
Could you post your my.cnf file used on your small, working vps? Are you using InnoDB engine? What is the size of the database? Maybe there are some settings to tweak. |
|
[client] This was formally known as [safe_mysqld]. Both versions are currently parsed.[mysqld_safe] [mysqld] max_user_connections = 50 * Query Cache Configurationquery_cache_limit = 32M open_files_limit = 8196 default-storage-engine = innodb [mysqldump] [mysql] [isamchk] |
Its a Drupal 5 site with 264 tables, ~3million records and 1GB in size. i don't use innodb for all tables, but i do for the major ones - sessions, watchdog, accesslog etc. |
|
Since the example config supplied with Barracuda is not tuned for this size of database, I would recommend running those 3 scripts on Barracuda server to tune it better, since it obviously has allocated far less resources (for MyISAM) than it should with this database. http://omega8.cc/dev/tunesql/tuning-primer.sh.txt I believe you should particularly increase on Barracuda values related to MyISAM (it is set to use XtraDB/InnoDB by default and doesn't care about MyISAM much), so for sure watch there for: key_buffer_size Also, with this size of database, you should probably tweak: myisam_sort_buffer_size |
|
Thank you for the input, i will look into this tomorrow. I will also look to purge some of the tables like the session and perhaps convert more into innodb tables. |
|
Ok, I ran the scripts and I tweaked some of those settings - despite the scripts saying things were mostly ok, I was still having problems with performance. Even in InnoDB the sessions table had god a bit unwieldy, so after struggling for a while to remove the older entries I truncated it. That improved matters, but finally today I converted a big batch of tables to innodb, including node_revisions which seemed to be a problematic one. Since then cpu usage has got down to a reasonable level despite it being the busiest part of the day for the site. So thanks for the pointers :) |
|
Use DB Tuner to get better results - http://drupal.org/project/dbtuner, and use Pressflow to avoid many GB of session table :) |
benosman commentedSep 13, 2010
Hello again.
I realise this may be outside of your area of support, but its got me a bit stumped so i though i'd try.
I'm in the process of consolidating two vps (1 x apache & 1 mysql) into a larger Barracuda based vps.
I attempted to switch over a site database from the 768MB mysql vps to 1.5GB barracuda one and despite their being plenty of memory on the barracuda one and a more powerful CPU when I made the switch mysql took over all the CPU and it basically melted!
First I tried with the default mysql conf you ship with, then I tried one very close to what I use now and neither helped. I did leave it a while to see if it 'warmed up' but still no improvement.
The database is big and site is relatively busy but I don't understand why the less powerful vps manages better... :-s
The text was updated successfully, but these errors were encountered: