Hi Art,
This subject is topical for me now as I spent some time at the weekend looking at this and could not make sense of it. Your post is somewhat cathartic for me.
I currently use three ways of looking at read-ahead:
1. System profile, either 'onstat -p' or sysprofile SMI view.
2. Sysmaster query to find activity by the read-ahead threads.
SELECT
SUM(r.nreads) AS nreads,
SUM(r.upf_bufreads) AS bufreads
FROM
systhreads t,
sysrstcb r
WHERE
r.flags=524801 AND
r.mttcb = t.th_addr;
(This picks up a few other system threads as there seems to be no obvious way of identifying read-ahead threads via SMI, but as they do little I/O it does not affect the result much. You cannot use thread name reliably, even though they are usually named 'readahead_X', as one of our instances currently has a read-ahead thread named 'ustat_546328'!)
3. And 'onstat -g rah':
https://www.ibm.com/support/knowledgecenter/en/SSGU8G_14.1.0/com.ibm.adref.doc/ids_adr_1126.htm'onstat -g rah' is difficult to interpret so I wrote a few lines of Perl to parse the command, parse it again after a time and display the differences in nicely formatted columns and I can pipe the output through 'sort'. I can use 'partn' from the IIUG site to make the part numbers into friendly names.
With 'onstat -g rah' it seems millions of buffer reads can be generated from a number of read-ahead operations (across all five types) in single figures.
The results I get from these methods have different orders of magnitude although when graphed show similar patterns.
I agree overall it is difficult/impossible to calculate the read-ahead utilisation ratio (pages read from disk then actually used) except at profile level as the efficiency metrics reported by 'onstat -g rah' are to do with fetching pages via read-ahead that were already buffered. I guess this is a different way of looking at things.
There isn't really a question here, just comments really but I share your frustration with the metrics and from not having a deeper understanding of what the numbers actually represent.
Ben.
------------------------------
Benjamin Thompson
------------------------------
Original Message:
Sent: Sat June 06, 2020 11:35 PM
From: Art Kagel
Subject: New RFE for your review.
David:
I wish I knew. One thing I know is that I get closer to an RAU value by adding up the per partnum numbers from onstat -g rah and the equivalent values from sysmaster. However, even those numbers are not complete.
On a site that under the old algorithms reported an RAU of 99% using my formula, under the new algorithms is reporting only 40% utilization which makes no sense to me.
Art
Original Message:
Sent: 6/6/2020 8:31:00 PM
From: David Williams
Subject: RE: New RFE for your review.
Hi Art,
What details are not included in the readahead output?
Regards,
David.
------------------------------
David Williams
Original Message:
Sent: Tue December 03, 2019 10:06 AM
From: Art Kagel
Subject: New RFE for your review.
Please check out this RFE and vote on it if you think it would be a good thing:
IBM Data & AIAha | remove preview |
| IBM Data & AI | With the ubiquity of intelligent storage, the value of readahead in the Informix server is reduced and excessive readahead can be detrimental to performance. However, since the introduction of the AUTO_READAHEAD parameter and the associated changes to the readahead algorithms in the engine that include readahead of data that was not included in earlier versions of the engine, not all readahead details are exposed for analysis making it impossible to tune the AUTO_READAHEAD setting accurately. | View this on Aha > |
|
|
https://ibm-data-and-ai.ideas.aha.io/ideas/INFX-I-346
------------------------------
Art Kagel
------------------------------
#Informix