SETOBJACC Usage
Ian
wondered if anyone had made use of this command and had any
tips to pass on?
Recently added two processors to an iseries and did not improve
dayend runtime.
Run as single thread in a subsystem with nothing much else
going on, so don't believe main storage or processor issue.
Will look into multi thread long term, but initially looking
into interim solutions to improve performance and reduce dayend
duration.
A friend has also mention placing journal and receivers on one
disk, anyone come across this as a way to improve journal write
performance?
Going through index advisor, but personally don't think advice
is that obvious, with regard to indexes to create to get best return,
again any tips or experiences with regard advisor would be helpful.
All constructive feedback gratefully received, happy for my
stupidy to be highlighted if I can get job done as a consequence.
MTIA
Kind Regards
Ian
Brad
As you can imagine it's hard to be specific without seeing more info
about the server's performance stats and config but here's my two
penneth for what it's worth:
As you've added more processing resource and it's made no real
difference and that your server is not doing much else and has
adequate main storage, then we are left with three areas to check
into:
Check for I/O bottleneck
Check your server performance statistics during dayend, particularly I/
O on disk controllers and arms.
Server Configuration
Check system values QPRCMLTTSK, QQRYDEGREE, QTHDRSCADJ, QTHDRSCAFN
Check memory pool allocation & advanced disk cache enablement
Journalling
You mentioned journaling, if you are not using Journal Caching in the
dayend, then try it
Make sure you have the recommended PTFs on your server as these can
make a big difference
Consider moving journal receivers to another ASP
I hope some of this helps. It looks from your profile like you are UK
based, as am I, so if you want to talk about it in more detail drop me
a email and I'd be happy to help.
Cheers, Steve
Doug
RGZPFM
If you don't have many drives and Journaling is heavy then put receivers
into their own ASP. If you have a lot of "arms" don't bother.
If you don't process your files randomly (by keys) then indexes won't help.
Block up your sequential reads by using OVRDBF. If you are using indexes,
optimize them (LF or SQL) over the best columns. And set QQRYDEGREE (be
careful with using the *MAX value, start with *IO then go to *OPTIMIZE).
--
Doug
"Ian" <ile...@caerleon60.freeserve.co.uk> wrote in message
news:97cc5a18-736c-4d27...@24g2000hsh.googlegroups.com...
Rob
Ian
Have you got SMP on? And do any of your day-end procedures use SQL,
because if not my belief (wrongly or rightly) is that changing
QQRYDEGREE won't do a lot for your specific functions. Your code will
probably still be running on a single processor until you can do
something to make it use more, such as enforced multi-threading by
design (as you've mentioned) or by using SQL for set processing and
having SMP on with QQRYDEGREE set to something other than *NONE. In
fact, IBM have said you can experience SQL performance improvements
with SMP even if you only have a single processor as it can choose to
run 2 tasks within the same processor.
I know this is off track as you just wanted to add more hardware and
see an improvement but the memory thing is a biggy (as already
mentioned) as if you have excessive swapping it's effects are
exponential, and you may wish to use something like QSYSMON to explore
functions that are performing massive DCP usage whilst not obtained
much in the way of I/O.