Thank you stating this so well. I suspected it was something along
those lines I just couldn't verbalize it.

Oddly enough, our Windows based Track-It server displays the same
behavior when searching strings. On the other hand, it's not odd. All
computers page to cache right?

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike Amos
Sent: Tuesday, June 14, 2011 11:22 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: FNDSTRPDM is slow

Bryan,

The behaviour that you are seeing, slow the first time a file or group
of files are accessed, is consistent with OS/400 behaviour. I suspect
that the slowness is related to the LRU paging algorithm used by OS/400.

Stated another way, if the file indices and the related contents are not
used for an extended time, they get paged out of the system cash. Then,
the next time you do a string search, both the indices an the file
contents must be read back (paged) into cash. For large files, this
paging may take a significant amount of time.

The only way that I've found to improve the performance in this
situation is to periodically access the file to keep it paged into
memory. This is not a good idea on busy systems as keeping the file
paged into cash will slow down other processes.

Mike
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.


This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2019 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].