You may have seen in the last couple of weekly news posts that Baron mentioned we are working on a new adaptive flushing algorithm in InnoDB. In fact, we already have three such algorithms in Percona Server (reflex, estimate, keep_average). Why do we need one more? Okay, first let me start by showing the current […]
My post back in April, http://www.mysqlperformanceblog.com/2010/04/08/fast-ssd-or-more-memory/, caused quite interest, especially on topic SSD vs Memory. That time I used fairy small dataset, so it caused more questions, like, should we have more then 128GB of memory? If we use fast solid state drive, should we still be looking to increase memory, or that configuration provides […]
Some Applications need to store some transient data which is frequently regenerated and MEMORY table look like a very good match for this sort of tasks. Unfortunately this will bite when you will be looking to add Replication to your environment as MEMORY tables do not play well with replication.
I recently encountered an interesting case. A customer reported that mysqld crashed on start on OpenSUSE 11.2 kernel 188.8.131.52-0.2-desktop x86_64 Â with 96 GB RAM when the innodb_buffer_pool_size was set to anything more than 62 GB. I decided to try it with 76 GB. The error message was an assert due to a failed malloc() […]
The amount of memory Innodb will require for its data dictionary depends on amount of tables you have as well as number of fields and indexes. Innodb allocates this memory once table is accessed and keeps until server is shut down. In XtraDB we have an option to restrict that limit. So how much memory […]
While a scale-out solution has traditionally been popular for MySQL, it’s interesting to see what room we now have to scale up – cheap memory, fast storage, better power efficiency.Â There certainly are a lot of options now – I’ve been meeting about a customer/week using Fusion-IO cards.Â One interesting choice I’ve seen people make […]
As continue to my benchmarks http://www.mysqlperformanceblog.com/2009/04/30/looking-on-54-io-bound-benchmarks/ on 5.4 I tried in-memory load (basically changed buffer pool from 3GB to 15GB, and database size is 10GB). The results are on the same spreadsheet http://spreadsheets.google.com/ccc?key=rYZB2dd2j1pQsvWs2kFvTsg&hl=en#, page CPUBound. I especially made short warmup (120 sec) and long run (2700sec) to see how different versions go through warmup stage. […]
As larger and larger amount of memory become common (512GB is something you can fit into relatively commodity server this day) many customers select to build their application so all or most of their database (frequently Innodb) fits into memory. If all tables fit in Innodb buffer pool the performance for reads will be quite […]
I vaguely recall a couple of blog posts recently asking something like “what’s the formula to compute mysqld’s worst-case maximum memory usage?” Various formulas are in wide use, but none of them is fully correct. Here’s why: you can’t write an equation for it.
Quite commonly I get a question similar to this – “My Innodb Buffer Pool is already 90% full, should I be thinking about upgrading memory already?” This is a wrong way to put the question. Unless you have very small database (read as database which is less than innodb_buffer_pool_size) You will have all buffer pool […]