OSDL-DBT-2 - 2.4 vs 2.5 4-way/8-way with vmstat
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines
Quoted 2 lines · Cliff White
http://www.osdl.org/projects/dbt2dev/results/8way/LKML2/data/296/vmstat.out
That's progress, thanks.
It is useful to show the collection interval of vmstat in the reports. Is that
vmstat 1' orvmstat 1000'?
vmstat interval is 60 seconds, you are right, we'll fix the report.
Quoted 6 lines
This workload appears to be performing concurrent disk reads and writes. If these are _really_ happening at the same time (ie: if vmstat hasn't confused me) then it could well be the case that the throughput improvement comes from the I/O scheduler's tendency to service reads more promptly when there is a lot of writeback happening.
Re concurrent IO:
The offical answer from the dba's: "Well, it tries"
There are multiple user proccessess doing queries and commits. There should be a difference between the cached and non-cached runs, as the cached runs should not be doing much writing, except to the log device.
Every 10 minutes in all workloads, the database flushes cache to the datafiles,
which should produce a noticeable peak in activity.
These loads suck up all the memory they can, so anything that gives us more free memory should
be goodness. We think we are also seeing improvements in 2.5 in free memory, but
we don't know for sure where is best to look and how best to prove it. Any advice?
Quoted 5 lines
If so then you can expect to see wild swings in results as you wend your way through recent 2.5 kernels :(. I'm working on settling that all down. 2.5.59-mm7 should do well.
Hopefully we can get some results for you on that kernel. cliffw
Quoted 8 lines · Cliff White
...
These loads suck up all the memory they can, so anything that gives us more free memory should
be goodness. We think we are also seeing improvements in 2.5 in free memory, but
we don't know for sure where is best to look and how best to prove it. Any advice?
Monitoring /proc/meminfo would be the main means. Further info could be obtained by drilling down into /proc/vmstat and /proc/slabinfo (the latter via bloatmeter, preferably).
http://www.zip.com.au/~akpm/linux/patches/stuff/
Martin Bligh is working on another VM reporting tool `vmtop', which would be appropriate for that as well.