On Tuesday 5 July 2011 at 17:27 Dmitry Yemanov wrote: > > FW and HDD settings don't affect the page I/O stats.
Actually, FW must affect the I/O stats - see my first post in this thread for an example. The only difference between those figures and the second set are that the FW was off in the first test and consequently I could update a million rows quite quickly. When the FW was set to on I had to reduce the test to update just 100,000 rows. > > The attachment only executes a single statement so the difference between > > page writes derived from the perf.h api and the mon$io page writes > > should be statistically insignificant, but in all cases the mon$io stat > > should be slightly larger due to the extra book-keeping for closing the > > isql txns. > > These observations are true only for the statistics reported for > stat_group = 0, as isql measures the database-wise statistics. Yes I know that the perf.h i/o stats are database wide. But in this case there is no difference. The database is restored, isql attaches, does work, and exits. There are no other concurrent connections and no other changes made to the database. There can be no garbage collection under these circumstances. As far as I understand it the perf i/o and the mon$ i/o should be measuring almost exactly the same thing, except that the attachment level stats should also include some extra I/O for the additional book-keeping. > It's hard to guess without having the test at hands. Perhaps it's > related to the background I/O. Could you share the test case? I'll put something together for you. > > After running these tests I then took a look at the MON$IO_STATS for the > > last database run (Windows 16K page size). One would expect to see the > > page write stats for stat_group 0 to be around 39,000. However, I'm only > > seeing 49 page_writes. > > I suppose that you looked at the database stats in the new connection > (after the last isql run has exited), so the stats were reset. > Ah, that is interesting. I don't think that is documented. I was under the impression that stat_group 0 was cumulative for all connections since the start of the server. Paul -- Paul Reeves http://www.ibphoenix.com Specialists in Firebird support ------------------------------------------------------------------------------ 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
