Question 32b Progress Above the 4G line

kdefilip

Member
Hi
Experienced DBA, new to Progress so please forgive any transgressions :)

We have a 32b install of OpenEdge Release 11.1.0.037 on a 64b Win2008 server. 96G Ram, 16 cores.

My question, what ability does the 32b release of Progress have to see RAM above the 4G mark? I know with Oracle and MSSQL 32b versions, we can "teach" those systems to utilize RAM above 4G. Does progess have this ability and what are the steps to make it happen?

Thanks in advance
 

Cringer

ProgressTalk.com Moderator
Staff member
I am not sure you can. Are there any reasons why you aren't running 64bit server executables?
 

TomBascom

Curmudgeon
No. A 32 bit executable can only address 4GB. The Windows architecture normally only allows 2GB of that to be application memory. (There is a way to get 3GB but it isn't supported.). Various other considerations make the practical limit for Progress 32 bit on Windows somewhere between 1.5 and 1.7 GB.

The year is now 2014. Your OS and Progress should both be 64 bits. Stop ordering 32 bit products.
 

kdefilip

Member
No. A 32 bit executable can only address 4GB. The Windows architecture normally only allows 2GB of that to be application memory. (There is a way to get 3GB but it isn't supported.). Various other considerations make the practical limit for Progress 32 bit on Windows somewhere between 1.5 and 1.7 GB.

The year is now 2014. Your OS and Progress should both be 64 bits. Stop ordering 32 bit products.
Thanks Tom
Yes, I am aware of the year. However, this is vendor driven and their app is not ready for 64b, so I have been told. Having said that, as far back as 1990 and possibly earlier, Oracle and MSSQL have had the ability to use memory above the 4G line. So what I am implying here is that this inability in a Progress 11x database seems to be yet another limitation of Progress. And yes, a vendor rolling out a solution on 32b that encompasses a user base of 340-350 users at any given time is a fools folly, but unfortunately, this has dropped in my lap.
Trying to functionally survive on a system with 340+ users with a buffer cache of 750M, limited lock table, etc is certainly not a good situation. But still, I find it hard to believe that Progress has not addressed this issue in the year 2014 on a version that is still available and to some degree, widely used.
 

Cringer

ProgressTalk.com Moderator
Staff member
It may be a good idea to contact your vendor for an exact reasoning why it is not ready for 64 bit server executables. You can still run 32bit clients so it shouldn't be an issue. Your limitation isn't Progress really, it's a dodgy vendor IMO.
 

kdefilip

Member
It may be a good idea to contact your vendor for an exact reasoning why it is not ready for 64 bit server executables. You can still run 32bit clients so it shouldn't be an issue. Your limitation isn't Progress really, it's a dodgy vendor IMO.
Oh yes, you've hit the nail on the head, however, I did not pick them and I am stuck at the moment.
Let me ask you this, is there a way to confirm that the DB is in fact 32b? I ask this because the app layer is installed on the same box as the DB and I am beginning to wonder exactly what you are alluding to, i.e., that it is their app that is 32b. If I could confirm this and confirm that the DB is 64b I can recommend that we separate the app layer from the DB, but again, I am very new to Progress, like a week ago. So if there is a way to confirm the Bit level of the DB, I would appreciate any insight you can offer in this regard.
kd
 

Cringer

ProgressTalk.com Moderator
Staff member
There's a good chance that the clients need to be running 32bit Progress, because they are using some DLLs or OCXs that only run on 32bit clients. The DB server itself should in theory be able to host the database on a 64bit installation of Progress, meaning you have everything you need available for memory management etc.
What is the vendor application you're running? Someone might have experience with it.
What do you mean by the app layer being installed on the server?
 

TomBascom

Curmudgeon
"The db" is neither 32 nor 64 bits. The executables are one or the other. The db server can use 64 bit executables while the clients (aka prowin32.exe) can remain 32 bits if they connect via tcp/ip (as most windows clients do).

The "showcfg" command will show the "port". 33 is 64 bit windows executables.
 

TomBascom

Curmudgeon
What do you mean by "above the 4G line?". If you are talking about address space then my comments apply. And I seriously doubt that 32 bit Oracle or SQL Server are any different. If you are asking if Progress can be "mapped" into that space and run there then the answer has always been "yes".
 

kdefilip

Member
What do you mean by "above the 4G line?". If you are talking about address space then my comments apply. And I seriously doubt that 32 bit Oracle or SQL Server are any different. If you are asking if Progress can be "mapped" into that space and run there then the answer has always been "yes".
Hi
First, yes, Oracle and later, MSSQL have the ability to run all their shared memory resources in RAM space above the 4 G line on 32b systems. I can show you how if you're really interested. 32b installs of Oracle using 5-10G buffer cache was not an unusual thing, of course, most have gone to 64b at this point.

On your second point, for clarity's sake, what I am referring to is this. I am restricted to a limit of a 2G buffer cache due to 1046 block size. This appears to be a limitation of Prgress, i.e,. max buffer is tied to block size. Anyway, I would like to at least take advantage of the 2G limit, but it would appear - and my fear is - that due to the 32b limitation, if I were to attempt that, this DB will not start or certainly would complain on the way up. However, if indeed Progress 32b is loading its shared memory structures in RAM above the 4G line, then I have that as an option. But I am uncertain of Progress's ability to accomplish this and my post generally is looking for clarification on this issue. This DB in my install is choking right now due to stressed shared memory structures and I have to find some relief ASAP.
 

TomBascom

Curmudgeon
Oracle supports some ugly trickery with PAE that also has some downsides but that's just a kludge. The real solution, just like with Progress, is to go to 64 bit executables.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
My question, what ability does the 32b release of Progress have to see RAM above the 4G mark?
Progress executables, like any other Windows executables, don't allocate RAM or choose physical memory addresses. They allocate virtual memory and the OS memory manager determines whether the pages are memory-resident. 32 bits = 2^32 bytes = 4 GB of virtual memory address space for a 32-bit process; 2 GB for the OS and 2 GB for the user-mode code and data. Given the code, shared libraries, thread stack, heap, etc. that already reside in the user portion of the database broker's virtual memory address space, the practical limit of the size of shared memory is somewhere around 1.5 GB, but it will vary depending on your system. If you want to allocate larger shared memory structures, like buffer pool (-B) and lock table (-L), you need to run the 64-bit Enterprise RDBMS product rather than 32-bit.
Trying to functionally survive on a system with 340+ users with a buffer cache of 750M, limited lock table, etc is certainly not a good situation. But still, I find it hard to believe that Progress has not addressed this issue in the year 2014 on a version that is still available and to some degree, widely used.
I agree that that is not a good situation, and you can change it for the better. OpenEdge is indeed widely used, but as Tom has indicated most customers no longer face these constraints as they have moved their back end to 64-bit executables.
I ask this because the app layer is installed on the same box as the DB and I am beginning to wonder exactly what you are alluding to, i.e., that it is their app that is 32b. If I could confirm this and confirm that the DB is 64b I can recommend that we separate the app layer from the DB
Unfortunately one legitimate limitation of OpenEdge (though only on Windows) is that you cannot have both a 32-bit installation and a 64-bit installation of products in the same release, e.g. a 64-bit database and a 32-bit runtime. But you certainly can move your application tier to a different box. So you want the 32-bit executables for the client side (Client Networking or AppServer for example; your vendor will tell you) and 64-bit executables on the server side (Enterprise RDBMS and, likely, 4GL Development System, aka the compiler). With proper tuning of the clients, the database brokers, and the network path(s) for TCP connections instead of shared memory connections, you can make the clients perform well and eliminate most of the performance hit of connecting client/server. Though I suspect you may have larger bottlenecks at the moment.

A remote (TCP) client neither knows nor cares whether the database it connects to is running with 32-bit or 64-bit executables, so splitting the tiers isn't something that should cause you application compatibility issues unless you have clients that for some reason "must" run on the database server. But do talk to your vendor about concerns and your plans for addressing them.
This appears to be a limitation of Prgress, i.e,. max buffer is tied to block size.
I am restricted to a limit of a 2G buffer cache due to 1046 block size.
I'm not sure what number you are quoting but 1046 is not a Progress database block size. And as Tom said, this has nothing to do with your -B constraint. Shared memory (most of which is -B, usually) is constrained in that its segments must fit (be able to be mapped into) the free contiguous blocks of virtual memory in the address space of all processes that connect to it. Your limiting factor is the use of 32-bit executables to create and connect to shared memory.

On any modern OS the file system block size is at least 4 KB. It is 4 KB by default in NTFS. So if your database block size is less than that you will pay a severe performance penalty for having a small block size. The only way to change it is with a dump and load to create a new database. If you do this, I recommend 8 KB blocks.

In a "proenv" command prompt (find it in the OpenEdge group in the Start menu), navigate to the database directory and type:
proutil dbname -C describe

That will show you your database block size. If it isn't at least 4 KB then that is likely your biggest performance issue.
 

kdefilip

Member
Progress executables, like any other Windows executables, don't allocate RAM or choose physical memory addresses. They allocate virtual memory and the OS memory manager determines whether the pages are memory-resident. 32 bits = 2^32 bytes = 4 GB of virtual memory address space for a 32-bit process; 2 GB for the OS and 2 GB for the user-mode code and data. Given the code, shared libraries, thread stack, heap, etc. that already reside in the user portion of the database broker's virtual memory address space, the practical limit of the size of shared memory is somewhere around 1.5 GB, but it will vary depending on your system. If you want to allocate larger shared memory structures, like buffer pool (-B) and lock table (-L), you need to run the 64-bit Enterprise RDBMS product rather than 32-bit.

I agree that that is not a good situation, and you can change it for the better. OpenEdge is indeed widely used, but as Tom has indicated most customers no longer face these constraints as they have moved their back end to 64-bit executables.

Unfortunately one legitimate limitation of OpenEdge (though only on Windows) is that you cannot have both a 32-bit installation and a 64-bit installation of products in the same release, e.g. a 64-bit database and a 32-bit runtime. But you certainly can move your application tier to a different box. So you want the 32-bit executables for the client side (Client Networking or AppServer for example; your vendor will tell you) and 64-bit executables on the server side (Enterprise RDBMS and, likely, 4GL Development System, aka the compiler). With proper tuning of the clients, the database brokers, and the network path(s) for TCP connections instead of shared memory connections, you can make the clients perform well and eliminate most of the performance hit of connecting client/server. Though I suspect you may have larger bottlenecks at the moment.

A remote (TCP) client neither knows nor cares whether the database it connects to is running with 32-bit or 64-bit executables, so splitting the tiers isn't something that should cause you application compatibility issues unless you have clients that for some reason "must" run on the database server. But do talk to your vendor about concerns and your plans for addressing them.


I'm not sure what number you are quoting but 1046 is not a Progress database block size. And as Tom said, this has nothing to do with your -B constraint. Shared memory (most of which is -B, usually) is constrained in that its segments must fit (be able to be mapped into) the free contiguous blocks of virtual memory in the address space of all processes that connect to it. Your limiting factor is the use of 32-bit executables to create and connect to shared memory.

On any modern OS the file system block size is at least 4 KB. It is 4 KB by default in NTFS. So if your database block size is less than that you will pay a severe performance penalty for having a small block size. The only way to change it is with a dump and load to create a new database. If you do this, I recommend 8 KB blocks.

In a "proenv" command prompt (find it in the OpenEdge group in the Start menu), navigate to the database directory and type:
proutil dbname -C describe

That will show you your database block size. If it isn't at least 4 KB then that is likely your biggest performance issue.
Sorry, meant 4096 (4k)
 

kdefilip

Member
Is that a DB Blocksize of 1024? Ouch. Should be same as the OS Blocksize really. No reason not to be 8192 on Windows.
Obviously the biggest gain you are going to get is going to be from getting on to 64bit executables, but there may well be other things you can tune without so much of an impact on memory. Could you post the database log file from the last start up of the db? Look for 333 in it, and paste the next chunk of entries. That will tell us all your startup parameters.
Also run Promon on the DB and select option five. Wait five minutes or so and hit return. It will tell you a snapshot of the figures for that five minutes. How many checkpoints in that 5 minutes?
Thanks for reply Cringer.
Sorry, block size is 4k.
I'll have to attach a file, too large for post.
kd
 

kdefilip

Member
Is that a DB Blocksize of 1024? Ouch. Should be same as the OS Blocksize really. No reason not to be 8192 on Windows.
Obviously the biggest gain you are going to get is going to be from getting on to 64bit executables, but there may well be other things you can tune without so much of an impact on memory. Could you post the database log file from the last start up of the db? Look for 333 in it, and paste the next chunk of entries. That will tell us all your startup parameters.
Also run Promon on the DB and select option five. Wait five minutes or so and hit return. It will tell you a snapshot of the figures for that five minutes. How many checkpoints in that 5 minutes?
File Attached.
 

Attachments

  • Startup1.txt
    10.4 KB · Views: 7

Rob Fitzpatrick

ProgressTalk.com Sponsor
Your primary login broker supports both 4GL and SQL clients and is configured to support several hundred remote clients. You have a secondary broker supporting SQL clients. When serving remote clients, a better practice is to keep your remote 4GL clients and your SQL clients on separate brokers.

You said your application tier is on the DB server right now. Do those clients connect via TCP or shared memory? A TCP client will have a "-S <port # or service name>" startup parameter in its configuration. Also, in promon (the Progress command-line monitoring tool) screen 1, shared memory clients show up as type "SELF" while TCP (remote) clients show up as "REMC".

-L 800,000: for 350 users, this is... generous. The default is 8192. I would hazard a guess that poorly-scoped code and a spate of lock table overflows led to this large value being set.

-spin 800,000: this is unusually high. I would be interested to know why it was chosen. It is possible that 800,000 is an appropriate setting for you. But I wouldn't bet on it.

Do you know whether your company chose these startup parameters or received them from the vendor?

What is the size of the database?

This DB in my install is choking right now
Are your users complaining of poor performance? What does "choking" mean to you in terms of performance metrics?
 

kdefilip

Member
Your primary login broker supports both 4GL and SQL clients and is configured to support several hundred remote clients. You have a secondary broker supporting SQL clients. When serving remote clients, a better practice is to keep your remote 4GL clients and your SQL clients on separate brokers.

You said your application tier is on the DB server right now. Do those clients connect via TCP or shared memory? A TCP client will have a "-S <port # or service name>" startup parameter in its configuration. Also, in promon (the Progress command-line monitoring tool) screen 1, shared memory clients show up as type "SELF" while TCP (remote) clients show up as "REMC".


-L 800,000: for 350 users, this is... generous. The default is 8192. I would hazard a guess that poorly-scoped code and a spate of lock table overflows led to this large value being set.


-spin 800,000: this is unusually high. I would be interested to know why it was chosen. It is possible that 800,000 is an appropriate setting for you. But I wouldn't bet on it.


Do you know whether your company chose these startup parameters or received them from the vendor?


What is the size of the database?


Are your users complaining of poor performance? What does "choking" mean to you in terms of performance metrics?

-- We have "SELF", "REMC" and "BATCH"

-- Not sure how any of these parameters were originally set or justification for same. Yes, I saw that, but have no point of reference.

-- -spin has already been lowered to 100,000 with no change apparent. I am considering lowering to 10,000-12,000. We are still experiencing very high "Resource Waits" and "Latch Timeouts". Frequent checkpoints during peak load times, I am suspecting -Bi cluster size as as cause of High Checkpointing.

-- Don't know full history, but surely it was vendor driven

- Locking, freezing, App crashing.

-- 150G
 
Top