× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 31-May-2010 09:37, Kurt Anderson wrote:
I'm just starting to use SETOBJACC b/c we have some heavy file
reads that I'd like to move into memory.

I know there's the job log entry saying that the files were
moved into memory, but is there any way to see that the job is
utilizing the memory the file was loaded into? Specifically I
was wondering if the Display Open Files screen when looking at a
job would show no I/O if it was actually using memory - or does
that page not care if the I/O is against disk or memory? Is
there any indicator that the job is using it, other than a
performance comparison?

<<SNIP>>


The single level storage ensures "the memory the file was loaded into" is *the memory* being used; i.e. there is just one copy in memory, and thus any reference to the data will be via *that* memory... with the only exception being, when the referenced data had already been /paged out/ such that the data would have been faulted into any memory for any allowed pool. Thus if properly loaded into a pool that will not have other storage displace the file-data in memory, the utilization of the memory versus having to refer to the disk, is assured; i.e. little reason to seek out any indication that the job used the in-memory data, and to be clear, that is irrespective of in what pool the job runs when accessing the data.

If some value is perceived in attempting to verify that the file data was not paged into memory from disk, concentrate on the database faults, not the file I\O counts. The I\O counts from the WRKJOB OPTION(*OPNF) are of no use for the given, as they are effectively read\write counts, not paging\faulting counts. The Elapsed Auxiliary IO for a job would be telling for access counts which include non-fault IO, but those counts also include non-database IO requests. IIRC, TRCJOB output provides some IO count details.

A performance comparison is a good indication of the effect. Run a test once after *PURGE of the file, then again after loading the file data [and index] into memory, each time tracking CPU time, Clock time, and difference in database fault counts from beginning of the request to the end. That will give a good sense for how well the request to Set Object Access has effected the intent of ensuring the file data is referenced from memory versus disk; plus an idea of the benefit measured in reduced clock time, from having pre-loaded the data instead of having the data faulted or paged into memory.

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.