Patrik:
If your goal is to isolate the jobs using ODBC (or any other job for that
matter) and make them as efficient as possible then we are discussing the
correct methods in work management.
As to using ASP or iASP for work management purposes, I would not worry
about I/O for this situation, since the I/O for paging/faulting in V4 and
beyond is ordinarily not a concern or even worth worrying about given
sufficient memory. On the other hand the application may drive quite some
I/O, but then again that is real work, so while we manage it, that's what
the machine is for. Bottom line, ASP or iASP have no significant place in
this discussion. Besides that a subsystem cannot reside in any ASP other
than *SYSBASE anyway. (that's the actual subsystem, not the description)
As for application I/O and the uses of iASP or standard ASP, I would only
use those in very specific circumstances (PowerHA and separating journal
receivers and such) since storage management is one of the most powerful
parts of IBM i. In the use case you present, I don't see a reason for it
particularly at V4.
If however you are trying to stop the system from paging/faulting certain
memory then that starts an entirely new problem. You have to assume the
system is way smarter about how to manage it's memory, both real and
virtual, than anything we can do as application developers.
The only way I know of to minimize paging/faulting is to put a huge amount
of memory into the pool and set the activity level high enough that jobs
very infrequently loose an activity level. Since that's terribly
impractical, optimizing work management and allowing the system to do it's
job is best. Even private pools will page/fault as the OS determines it
wants to. Private pools just complicate the whole work management scheme
and we don't use them except in very specific cases, this not being one of
them.
IBM spends a great deal of time making sure the memory management systems
are as robust and secure as possible. I'm guessing they collectively are
way better at it than we could possibly hope to be.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Patrik
Schindler
Sent: Monday, December 30, 2019 10:18 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Reducing ODBC connection impact
Hello Jim,
Am 30.12.2019 um 17:05 schrieb <midrangel@xxxxxxxxxxxxxxxxx>
<midrangel@xxxxxxxxxxxxxxxxx>:
While I can speculate all day about why you would want that memory
management granularity, I can tell you work management is not going to
accomplish what I think you are suggesting below.
Now I'm even more confused. What's the point in having memory pools, then?
Why do I want it: I want to reduce ODBC connection impact. That is, if
inserts have been running for a while, my interactive job seemingly gets
swapped out and I need to wait for it to be paged back into memory. I want
to suppress this wait time to an unavoidable minimum. Maybe we're not
talking about the same thing?
I guess that just that is what Frank Soltis and his guys envisioned from the
beginning in S/38: To keep response times low, confine jobs competing for
(back then ridiculously expensive and thus scarce) memory resources into a
single entity, an SBS, so the whole machine won't thrash but just jobs in
the aforementioned SBS. Which is also bad in itself, because disk activity
will be high and affect other jobs in other subsystems. This can be
circumvented only by moving every object that SBS is utilizing into a
separate ASP. Right?
What's your opinion?
:wq! PoC
PGP-Key: DDD3 4ABF 6413 38DE -
https://www.pocnet.net/poc-key.asc
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
