Openedge 32bit running on a sparc 64bit server performance problems.

[adamk84]

Hi Everyone,

I was wondering if anyone would happen to know why we would be seeing a performance slowdown in our progress environments.

We are currently running OpenEdge 10.2A 32bit,
The server we are running is a newer Sparc Sun4V with 64 bit and 32core cpu and 16gb ram.

We are going to be upgrading to 64bit OpenEdge in the foreseeable future.

We have been testing various areas in our system and have found that our systems are slower then they were when they ran on our old box. The old box was a 32bit Sparc with 8gb ram and 4 cpu's. The areas that we are finding slowdowns is when we need to run system compiles with roughly 3000-6000 programs. These compiles used to take between 1 - 1.5 hours. With our new systems we were expecting to have these compile times to be at minimum on par with the old system. The average time to compile on this new server is 2 - 3 hours, which is double what it used to be.


Does anyone have any suggestions on what to try or tweaks that should be attempted to try and cut that number in half? Would changing from 32bit to 64bit make a difference for this?

Let me know if you need more information.

Thanks,
Adam

 

[RealHeavyDude]

In the past we had onetime a dramatic performance drop when the file systems were mounted with the forced direct IO option switched on. It seems that Oracle recommends to switch it on for database file systems but for Progress/OpenEdge it's not supported and when switched on, may cause such a dramatic performance drop.

Heavy Regards, RealHeavyDude.

 

[atopher1]

What's the server model? If it's a T series you could be limited by the individual thread CPU speed.

We run a T5440 (4 CPU * 8 cores per CPU * 8 threads per core = 256 threads). Works great for day to day stuff (appservers/webspeed etc) but for longer running batch processes it doesn't have the same grunt as a combined CPU.

Chris

 

[TomBascom]

I too would suspect that it is a T.

As Chris says -- they're fine for some things. I have have customers who run them without problems -- but those are just small systems that don't demand much of their servers. If you need top of the line performance they are a big mistake. Progress is not a good fit for that architecture. It's great for web servers or Java code. But not Progress.

 

[adamk84]

Hi, Thanks for your replies; We have a T5120. Chris is there a way of tweaking the settings to allow the batch process to use as much cpu as it needs? We are also thinking of changing the server from running as a 64bit to 32bit to see if that would somehow gain performance power when running longer batch processes.

 

[atopher1]

You can do things like restrict the process to a particular thread or range of threads (processor set) to prevent it switching from thread to thread/core to core/CPU to CPU etc. You may get some mileage from this but I suspect not a lot (I haven't done enough testing in this area). The compile process itself is single-threaded - as is 99% of Openedge (AFAIK).

You could look at making your compile process multi-thread - i.e. it starts a bunch of compilers off at once that each have different start and finish points. This way you can utilize multiple threads and potentially cut the compile time down to even lower than the original box.

We had similar issues - 2 * 1.6Ghz CPUs changed to 256 * 1.2Ghz CPUs gave a great performance improvement for standard web/web-client users but the trade-off was for users running CPU intensive batch jobs - month-end reports etc. That said, it was worth it - Previously these batch jobs would cause a system-wide slow-down, and the new threaded architecture prevented this.


Chris