29.06.2011 19:12, Paul Reeves wrote: > > I've been studying the output of the MON$IO_STATS table but something doesn't > make sense. I've built a test rig that > > a) catches the mon$io_stats to disk at the attachment level on disconnect > and > b) modifies a million records randomly during a single attachment.
Did a commit happened after the update? > After this update completes gstat is telling me that the database has > increased by approximately X pages. Which GSTAT counters do you look at? Number of data pages per table? > However the page i/o statistics are > telling me that the attachment only wrote Y pages. > Here are some more detailed figures: > > Page Size GSTAT Before GSTAT After GSTAT Diff MON$IO Page Writes > ========= ============ =========== ========== ================== > 4096 250000 315049 115049 1561 > 8192 111112 140824 29712 7602 > 16384 55556 70214 14658 22320 > > I've repeated the tests several times with similar results. > > I'm also noticing that the cumulative figure for stat_group 0 in MON$IO_STATS > does not even match the figures I'm getting from my capture of stats at the > attachment level. > > So, the question is - just what page writes are counted? I have been convinced > for at least the last fifteen years that the stats counted all physical page > i/o. This does not seem to be the case. In SS, the global (per database) counter may not match the sum of the per attachment counters. This is because writes are also performed by background threads (namely: garbage collector and cache writer), i.e. they're not explicitly bound to user attachments and thus not represented in MON$ATTACHMENTS. IIRC, this has been recently improved in v3.0 and perhaps it's back portable. You could modify the test to trace the IO stats for MON$DATABASE instead of MON$ATTACHMENTS. Get the stats ON CONNECT, store it in the per attachment context variable and then calculate the delta ON DISCONNECT. Surely, it won't work in the multi-user mode, but anyway it could be worth checking that at least the per database stats is more or less correct (matches the GSTAT output). Dmitry ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
