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