On Wednesday 6 July 2011 at 09:06 Dmitry Yemanov wrote: > > Sorry, but it doesn't not. Our I/O stats reports page writes performed > by the engine (OS call). They could either reach the disk (FW=ON) or > stay in the file system cache (FW=OFF), but the write has happened and > it's reflected in the stats.
Yes, I can confirm that. And it looks as if the weird stats I got when updating one million rows are related to the cache writer thread. See below. > Wrong. I've already told you about the cache writer thread, which > flushes dirty pages to disk in the background. > OK, things are starting to become clearer. My first anomaly is related to the cache writer thread on SS. Basically when the 4K page size is used the 100,000 rows fit into approx 3,000 pages. The random update procedure causes the data pages to increase to 4,000. The database buffer is only 2,048 so obviously all those pages aren't going to fit, so the cache writer thread kicks in. With the 8K and 16K pages they all fit into the buffer so the cache writer never gets involved. I've confirmed this by running the same tests agains CS on Linux. This explains the first mystery - why the perf.h page writes for 4K were 70,000 and the MON$IO_STATS page writes were only 33,000. Unfortunately, in answering that question I've now got another, but that will have to wait until tomorrow. 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
