Anyone experience working with openedge and aix, 8 cpu dual core system?

kblackwel

New Member
We are currently running AIX 7.1. Has 8 power5 cpu's (16 cores) Openedge 10.1b 32bit (can't run 64)

I have a ticket with IBM about this issue, but I'm starting to believe it might be a openedge issue?

What seems to be happening is all the odd number cores aren't being utilized like the even ones are.

Looking in topas, I can see utilization evenly across the odd number cores, but the even ones are always at 100% idle.

Thanks in advance.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
I don't know much about power architecture, but the "problem" symptoms sound similar to what you can see on x86 architecture with hyper-threaded CPUs. That's because only half of them are really cores and the other half are just extra registers etc. that the OS thinks are cores. They really only get used with workloads that are parallelizable.

Also, some modern OSes have core-parking algorithms for power savings. If there are many cores with light workload the scheduler will shift it so it can put cores or whole sockets into sleep states to reduce power consumption.

I don't know if AIX does this, but it is possible you are seeing intended behaviour. However, IBM will give you a better opinion than me. :)

P.S.: Why can't you run 64-bit? And why only 10.1B? Just curious.
 

TomBascom

Curmudgeon
What you describe is typical and not a problem. It just means that you do not have enough demand to require the additional CPUs. You probably have SMT=2 (which would be correct for Power 5). It is a result of "CPU folding" and it is a Good Thing.

What is the output of "lparstat" and "lssrad -av"?

Is there any actual problem other than the odd looking TOPAS screen? (BTW -- I like NMON a lot better...)

Why do you think that you cannot run 64-bit?

What is holding you back from upgrading past 10.1? That's a really old and decrepit release...
 

kblackwel

New Member
What is the output of "lparstat" and "lssrad -av"?

bash-3.2# lssrad -av
REF1 SRAD MEM CPU
0
0 15272.00 0-7
1
1 15757.38 8-15
bash-3.2# lparstat


System configuration: type=Dedicated mode=Capped smt=On lcpu=16 mem=32000MB


%user %sys %wait %idle
----- ----- ------ ------
4.2 2.4 1.1 92.3

Is there any actual problem other than the odd looking TOPAS screen? (BTW -- I like NMON a lot better...)

We have a custom API working on our DB. All it takes is for a process to get to to 12% in topas and the system get really slow and everyone's effected.

Why do you think that you cannot run 64-bit?

The application we run on top of Openedge can run on 64bit DB.

What is holding you back from upgrading past 10.1? That's a really old and decrepit release...

I would assume it's because of the application we run on top, but I will looking to the answer to that.
Ever heard of SX Enterprise?
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Why do you think that you cannot run 64-bit?

The application we run on top of Openedge can run on 64bit DB.

I assume that was a typo, and you meant "can't run...". Does your application run entirely server-side? Or do you have a mix of interactive and batch clients?

If you have 32-bit clients that can connect client/server rather than shared memory, then they won't know or care whether your DB server processes are 64-bit. It's the processes that are 32-bit or 64-bit, not the DB itself.
 

kblackwel

New Member
We use a program on top of Openedge called SX Enterprise. Runs in windows and is a client. The people that sold it to us say we can't run 64bit Openedge with application.

We're not happy about it, but it is what it is. Trying to squeeze as much performance I can out of the 32bit DB.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
We use a program on top of Openedge called SX Enterprise. Runs in windows and is a client. The people that sold it to us say we can't run 64bit Openedge with application.

OK, so it's client/server, not shared memory. I use an app with a similar model. The important point is that you don't have one OpenEdge product or installation (assuming the client side is Progress-based, not SQL). You have at least two; one is AIX RDBMS, the other is a Windows client, like Client Networking or AppServer. Either way, whether the clients are 4GL or SQL, they communicate with the database only via TCP. And that means you can run a 32-bit client just fine, and use a 64-bit RDBMS on AIX. That means you can allocate a lot more shared memory for your DB buffers and get better performance.

Ask your vendor if that will work. If they say no then either they're misinformed or they're trying to misinform you.

If they say "you can't run 64-bit OpenEdge on Windows", that's fine; you don't need it. But if they say "you can't run 64-bit RDBMS on AIX with a 32-bit OpenEdge client on Windows", it's a snow-job.
 

cj_brandt

Active Member
If you are trying to squeeze performance out of the database - adding CPU's usually doesn't help much.

Do you know what the disk io activity is while the db is running ?
Do you know what the database server and client parameters are ?
Do you know how much activity the database has during a normal day ? - basic stats like promon -> 5 screen shows.
 

TomBascom

Curmudgeon
Yes, I am familiar with SXE and I happen to know, from quite a lot of experience, that it is perfectly ok to run a 64 bit db server with it. You need to push back at whoever is telling you that you cannot because they are simply wrong.

12% -- that is one full core in an 8 core system. It sounds like you either have a "runaway" or (unlikely) -spin is set to 0.

SXE is what I refer to as a "target rich tuning opportunity". Its out of the box configuration is intended to be "good enough" for most customers. Larger customers really need to spend some time working on getting it properly configured. And you have to be firm with Infor's support people. They tend to think that there is only one true way to do things. There are people at Infor who know better -- you may need to escalate to reach them but they do exist.
 
Top