Having some I/O performance issues, IBM's been involved in identifying
possible problems.
One that they reported, was the use of a sequence object...
values (digits(netval for myseq)) into :H
Total time: 3,058,421,415
CPU Time (ms): 62,936
Sync DB reads: 377,572
ASync DB reads: 109
Total Page Faults: 976,304
IBM recommended, " ensure that this sequence object is not a bottleneck.
The cache and Order attributes of the sequence should be reviewed."
Sequence object created as follows:
CREATE SEQUENCE MYLIB.MYSEQ
AS INTEGER
START WITH 1
INCREMENT BY 1
MINVALUE 1
MAXVALUE 2147483647
CYCLE CACHE 32 NO ORDER ;
The job requesting the sequence# attaches it to a request it places on a
*DTAQ for a communication job to process so that it can find it's reply on
the response *DTAQ.
Analyzing the logs... I see
max of 4 requests/sec for any given job...
max of 23 requests/min for any given job...
max of 200 requests/sec across all jobs...
max of 150 jobs making a request during the same second...
We're going to run those numbers by IBM, but I thought it'd be worthwhile
to throw them out here to see what you all thought.
My feeling is that the cache setting of 32 is sufficient; along with NO
ORDER...we're not going to be able to get any better performance out of the
statement.
And yes, I've pointed out we don't really need a sequence for this, a
16-byte GUID would probably be a better choice. ;)
Thanks!
Charles
As an Amazon Associate we earn from qualifying purchases.
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.