Stats are stored at Attachment and Transaction Level (amongst others.) Solution catch stats at end of Connection or Transaction.ĩ Capturing Txn Stats Initial analysis indicated that txn level stats may not be complete more study required. This means that even database level stats are lost if all connections to the database are closed.Ĩ Making Stats persist - DBTriggers DB Triggers available at Connection and Transaction Level. Cumulative database level stats requires persistent connections. Once a transaction is finished or an attachment is disconnected the details disappear from the monitoring tables. You need to start a new transaction to see the latest data in the monitoring tables. Be sure to tune DB Cache before drawing any conclusions about Firebird disc I/O.ħ Understanding How the MON$ tables work All the Firebird monitoring tables run within snapshot table stability transactions. Portable across platforms and architecures Works wih all versions since Fb 2.1 Sort of a work in progress -enhanced in 2.5ĥ MON$IO_STATS Firebird tracks four IO counters Page Reads - physical reads from disc Page Writes physical writes to disc Page Fetches pages read from memory Page Marks pages marked in memory for writing to disc.Ħ About Fetches Mostly we can ignore Fetches but be sure to make sure that the cache is big enough otherwise excessive reads will occur. The question is how do we measure our disc I/O requirements?ģ Two Basic Ways To Measure IO From within Firebird itself From the host O/SĤ Measuring I/O from Firebird Firebird knows what it has done MON$IO_STATS allows us to catch this info. A good disc array can give a massive increase in available IOPS. 1 Measuring Firebird Disc I/O Paul Reeves IBPhoenixĢ Introduction Disc I/O is one of the main bottlenecks in Firebird.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |