let’s not mix all things together, let’s just speak about RAM.

1. Generally speaking, the same server will never work worse if you add some RAM to it (except you use a buggy OS).

2. Another point – will it really improve your database performance?..

And following questions coming in mind:

until which size we may consider MySQL cache still being effective?
1GB? 10GB? 100GB? as well, seeing all notes about cache locking – what
about concurrency?

is MySQL cache working *always* better rather OS filesystem cache?
and probably we should compare first the ratio between ‘logical’ reads
from MySQL vs real ‘physical’ reads processed by OS?

There may be other points (like monitoring a global memory usage under OS, etc.), but let’s cover at these first..

Rgds,
-dim

I was too much thinking about situations I know:

- startups: not so many servers + not enough time to investigate + not all the needed skills (That’s why we read carefully your blog daily! ) => RAM upgrade is a cheap, fast and efficient solution…

- Fortune 500: external consultant doing dev (like I was) are expensive. My collegues in India were also not charged as low as we think.

BTW, keep on your great work! I learned a lot with your great site (Except one big mistery about MySQL v5.1… its release date in stable version… )

The innodb_max_dirty_pages_pct will not affect number of free pages only number of dirty pages. Even after page is flushed from the buffer pool it just becomes “clean” but not free

“Regarding flushes if there is any considerable disk IO activity Innodb will be very slow to flush dirty pages unless there is checkpointing activity or amount of dirty pages hits 90%”

But you also start out with people saying that their innodb buffer is 90% full. one of my points was that it may be mostly full of dirty pages, and that can be checked by setting the innodb_max_dirty_pages_pct lower, and seeing if that helps — ie, setting it to 20% or 50% and seeing if your innodb buffer is still “full”.

Good point which I surely have not mentioned. Upgrading RAM should come together with MySQL settings adjustments to use it well.

Regarding innodb_max_dirty_pages_pct – in most cases this being high or low depends on how your load is structured and how large your logs are. If there is working set which is both read and written the value will likely be high because there are little pages which do not need to be modified brought to buffer pool. Regarding flushes if there is any considerable disk IO activity Innodb will be very slow to flush dirty pages unless there is checkpointing activity or amount of dirty pages hits 90%

Few things

1) The ratio between labor and parts cost is different in different region of the world. So there is different sensitivity where. However it is true unless small database is expected it is often good idea to buy boxes with as much “cheap” memory as they can fit. At certain memory cheap size it tends to skyrocket.

2) Rental Servers – even though the memory is cheap many hosting providers would not only charge you effectively cost of memory to upgrade but also will put heavy monthly fees for hosting services with large memory amounts. This needs to be factored in in the cost.

3) Upgrade and testing is time and effort too and causes downtime unless there is redundancy in the system which need to be factored in.

4) Many larger applications have many servers so it is not the question of upgrading 1 server but upgrading 10 or 100 which multiplies both hardware cost as well as labor and testing.

Trial and Error approach is a whole different angle. More Memory ? Faster CPUs ? Faster Disks ? Adding The index ? Changing table engine. For everything you can use “try and see approach” but that may cause a lot of time and money wasted and unneeded downtime caused.

Plus, if you’re not using memory properly, adding more will only help a little bit. If you use RAM better, then it’s better whether or not you add more RAM or not.

As for the OP — I’d also recommend checking out the Innodb_buffer_pool_pages% variables. innodb_max_dirty_pages_pct is set to 90 by default, meaning that by default up to 90% of your buffer pool might be waiting for a flush to disk — if you have a lot of Innodb_buffer_pool_pages_dirty, it can be a sign that you need to flush to disk more, especially if there’s not a lot of disk writes.

Rgds,
-dim