Windows Enterprise Server Sizing

[unitas99007]

All;

Currently we're using JDE 9.0 / Tools 8.98.0.5, migrating to 8.98.2.3/4. We've got a UNIX PA-RISC 64 bit Enterprise server with 32 GB of RAM and 4-way processors.

We're looking at going to Windows JDE Enterprise servers for batch and logic. There's about 250 concurrent users. Any ideas on what kind of hardware sizing we would need for this? Is anyone sucessfully running this many users on a Windows 2003 /2008 Enterprise server?

PS- We do have two other Windows 2003 64-bit Enterprise servers, but they only server about 35 users each for two different timezones.

Please let me know your thoughts. Thanks!

Unitas99007

 

[cdawes]

I have many more than this number of users running on Windows boxes.

What modules are you running and what are your hours of operations? How many batch jobs do you run in a day?

Here are 2 actual configs that I have that map closely to what you have:

Config 1:
-Windows 2003 Enterprise Server
-4 CPU (expandable to 16 CPU)
-24 GB RAM

Config 2:
-2 x Windows 2003 Enterprise Server
-2 x 2 CPU, 12 GB RAM
-hardware load balancer

P.S. Windows 2003 64 bit is not on the MTR's

 

[jacksmccu]

Hi Unitas99007,

As cdawes has pointed out Windows is more than capable of supporting this number of users, especially on the current breed of hardware running Windows 2008 x64 (which is on the MTRs). For batch I always recommned getting the fastest processor possible, though again with the modern dual socket multi-core processors this is less of an issue. Memory is key especially in the 64 bit world where it can really be used so I would consider 16GB a minimum, 32Gb if you can afford it.

Hope this helps.

Jack.

 

[JDEBEE]

Colin, did you mean Dual core or Quad core CPU ? 2 CPU's might be less if batch jobs are also run on the enterprise server.

- Jeff

 

[cdawes]

Just remembered that I have a few other configs running live:

Config 1:
-Windows 2003 Enterprise Server
-4 CPU (expandable to 16 CPU)
-24 GB RAM

Config 2:
-2 x Windows 2003 Enterprise Server
-2 x 2 CPU, 12 GB RAM
-hardware load balancer

Config 3:
-2 x Windows 2008-64bit Enterprise Server
-2 x 2 CPU, 16 GB RAM
-hardware load balancer

Config 4:
-4 x Windows 2008-64bit Enterprise Server on VMWare
-2 x 2 VCPU, 16 GB RAM
-hardware load balancer

The key is to really tune up the database server which for this numbe rof users I keep separate.

Colin

 

[eSky]

Hi,

We are doing upgrade from XE to E1 9.0.

We are facing a performance issue while accessing data especially while running heavy reports/queries.

We are on CRP phase and due to performance issue we have stuck in Go- LIVE which was scheduled earlier.

Config:

Enterprise Server
JDE 9.0 TR 8.98.2.0
2 x 2 Quad Core Windows 2008 64 Bit Server
16 GB RAM
MS Cluster (SAN)

Database Server
SQL Server Enterprise 2005 64 Bit - SP3
2 x 2 Quad Core Windows 2003 64 Bit Server
16 GB RAM
MS Cluster (SAN)
Current Production Size - 400 GB (after Unicode)



We need experts suggestion to find the bottleneck.

We have conducted following -
1. Tune JDE.INI / JAS.INI / JDBJ.INI with 100 concurrent users. Total users 500

2. Identified table with more than 30 % fragmentation. Indexing done.

3. Current CRP Data is RAID 5 (7 Hard Disk)

4. Separate Batch Server to handle heavy / long reports.

5. Websphere 6.1 with Big F5 switch for load balanced of 4 Nodes. JVM size Min 256MB Max 1024 MB on all Box.

6. Latest Full pkg.


JDE E1 9.0 Update 1, TR 8.98.2.0, websphere 6.1, SQL SERVER 2005. Cumulative and all Memory/ Performance ESU Applied to system.

 

[cdawes]

eSky............if you're looking for expert suggestions then why not PAY an expert?

Only so much can be done for free and you may just end up spending more money in the long run fi you don't fix things now.

You hardware and software looking fine and should be able to handle 300 concurrent users no problem so you definately have a configuration issue.


Colin

 

[Alex_Pastuhov]

I'm a bit suspicious about your #3 - RAID5. But of course it would take looking into the fine details to pinpoint the cause(s)...

 

[eSky]

Hi,

we have gone to RAID 5, since environment have more reading during XE also. Write is very less in system.

With RAID 5 we get I/O 0f 7 HD when we read data, though write becomes sloe has it have to stripped data across all HD.

There s no complaints in regards of Write - OK and Update Commands.

Only fetching data causing some issue.
I am not sure what we are missing.

 

[Alex_Pastuhov]

Well, disk io is disk io: if it's busy writing, it would not be fast reading at the same time. I.e.: busy is busy.

But, of course, it's hardly possible to give any answer from just a few facts - there are zillions more facts one needs to know. It will take some time looking into for a specialist.

 

[eSky]

Hi,

There are new paramter in JDE.INI with TR 8.98 onwards.
Earlier I believe these parameter were need to set up in Unix - Solaris, AIX for performance.

I could not able to find any document on support.oracle.com explaining these parameter.

Can anyone rpovide explanation on these. Also what should be best of practice parameter for say concurrent 100 ysers.




[JDENET]
maxNumSocketMsgQueue=200
maxIPCQueueMsgs=100


[JDEIPC]
avgResourceNameLength=40
maxMsgqMsgBytes=2048
maxMsgqEntries=1024
maxMsgqBytes=65536

 

[brother_of_karamazov]

[ QUOTE ]
Hi,

We are doing upgrade from XE to E1 9.0.

We are facing a performance issue while accessing data especially while running heavy reports/queries.

We are on CRP phase and due to performance issue we have stuck in Go- LIVE which was scheduled earlier.

Config:

Enterprise Server
JDE 9.0 TR 8.98.2.0
2 x 2 Quad Core Windows 2008 64 Bit Server
16 GB RAM
MS Cluster (SAN)

Database Server
SQL Server Enterprise 2005 64 Bit - SP3
2 x 2 Quad Core Windows 2003 64 Bit Server
16 GB RAM
MS Cluster (SAN)
Current Production Size - 400 GB (after Unicode)



We need experts suggestion to find the bottleneck.

We have conducted following -
1. Tune JDE.INI / JAS.INI / JDBJ.INI with 100 concurrent users. Total users 500

2. Identified table with more than 30 % fragmentation. Indexing done.

3. Current CRP Data is RAID 5 (7 Hard Disk)

4. Separate Batch Server to handle heavy / long reports.

5. Websphere 6.1 with Big F5 switch for load balanced of 4 Nodes. JVM size Min 256MB Max 1024 MB on all Box.

6. Latest Full pkg.


JDE E1 9.0 Update 1, TR 8.98.2.0, websphere 6.1, SQL SERVER 2005. Cumulative and all Memory/ Performance ESU Applied to system.

[/ QUOTE ]


Your tempdb needs to be optimized. Create 4 small RAID1 or RAID10 sets and place one physical tempdb file on each. At the very least get tempdb away from your data. While you're at it, get the transaction logs away as well.

Also, 16GB is not a lot of SQL Server hardware. You may wish to consider going to 64GB.

Oh, and rebuild indexes on all tables.

You really, really need to have someone do some performance configuration and tuning on the database side.

 

[Joel]

Hi Vikek,

The general recommendation these days is to have database server disks both data and log files on RAID 10.

Is it just these few long running UBE's that is the problem or is your system slow in general. You need to plan your strategy accordingly..

- Joel

 

[eSky]

Hi,

Its only few long running jobs that causing the problem..

And we have just finished re-building index of all tables.

Moving long running job on batch server, so that load on primary server will reduce.

After re-indexing JDE_PRODUCTION Database we have speed up the process.

We cant move to RAID 10 as now structure and hardware are designed with RAID 5.

I personally believe RAID 5 is better than RAID 10 (1+0).
Raid 1+0 have more overhead during write operation. RAID 10 is very good for disaster recovery because every hard disk is mirror and then whole group is stripped on 1 more hard disk. Also for infra you need more twice storage on RAID 1+0 compare to RAID 5.

Our tempdb is on desperate hard disk. With few more tuning it looks to be we will in Go-Live position.

Long running Jobs are been asked to Functional and technical team to look again. Most of these are on F0911 and F4111 which have huge huge data.

We have extended Go-Live by 2 weeks and hopefully by that time we will finish all task.


Thanks to everyone for quick thoughts.

 

[gregglarkin]

[ QUOTE ]

We cant move to RAID 10 as now structure and hardware are designed with RAID 5.

I personally believe RAID 5 is better than RAID 10 (1+0).
Raid 1+0 have more overhead during write operation. RAID 10 is very good for disaster recovery because every hard disk is mirror and then whole group is stripped on 1 more hard disk. Also for infra you need more twice storage on RAID 1+0 compare to RAID 5.


[/ QUOTE ]

eSky

Do what you want, but your might want to rethink the Raid 1+0 recommendation. RAID 1+0 is substantially faster at read and writes than RAID 5. Optimizing tempdb is the key to a fast SQL server. You don't have to resize the entire database server, just a section for tempdb. Don't just take my word on this, Jeff Stevens is both an expert CNC and an expert DBA. just my $.02

 

[cdawes]

Ugg.....

given the same number of phyical drives RAID 5 is faster at Reads than RAID 1 + 0.

Raid 1 + 0 is faster at writes.

That being said I consider the hour of operation for a business when deciding Raid configuration.

24/7 --> RAID 1 + 0.

9/5 --> RAID 5

 

[morglum666]

I'm going to apologize ahead of time for the thread-jack.

Has anyone had any luck with JDE and partitioning tables in Oracle? It might be relevant to the original poster for the mega tables like F0911. We haven't had to go that far in our install as performance is pretty good as a whole, but theoretically the app doesn't know that the table has actually been partitioned.

I would be interested to know if anyone had set this up.

One comment I would make on the long running reports is that chances are a little time with a SQL analyzer could make a huge amount of difference once you know how the data is selected. Index's arn't a magic cure but they can make a huge difference in a short amount of time.


Morglum

 

[gregglarkin]

[ QUOTE ]

Has anyone had any luck with JDE and partitioning tables in Oracle? .....


One comment I would make on the long running reports is that chances are a little time with a SQL analyzer could make a huge amount of difference once you know how the data is selected. ...



[/ QUOTE ]

Malcom,

I'm not sure that table partitioning is supported. From the conversations that I have had on the subject, the big risk with table partitioning is down the road. When it comes time to do an upgrade, the Oracle scripts do not know what to do with a partioned table.

Your comment on SQL analyzer is a good tip. Our DBAs work with our JDE and Cognos developers all of the time to optimize reports. They have taken reports that run for six hours and crunched them down to ten minutes through optimizing the SQL statements and utilizing indexes.

Another thing that will substanially speed up processing is a database server with a huge cache. Our next gen database server that we are in the process of finalizing a contract on will have such a large cache that we can store a good chunk of the database in ram.

 

[brother_of_karamazov]

[ QUOTE ]
Hi Vikek,

The general recommendation these days is to have database server disks both data and log files on RAID 10.

Is it just these few long running UBE's that is the problem or is your system slow in general. You need to plan your strategy accordingly..

- Joel

[/ QUOTE ]

I've actually been looking into comparisons for IO rates on RAID10 vs. RAID5 with lotsa spindles. At some point the cost benefit crosses into favoring RAID5 with a lot of spindles.

The technical concept is that if you get the data going across enough disks concurrently you start to approach IO rates of RAID10 at a lower cost for large amounts of data.

I really haven't had the time to research. Anyone seen hard numbers on this?

 

[brother_of_karamazov]

[ QUOTE ]

Our tempdb is on desperate hard disk. With few more tuning it looks to be we will in Go-Live position.

Long running Jobs are been asked to Functional and technical team to look again. Most of these are on F0911 and F4111 which have huge huge data.



[/ QUOTE ]

How big is your tempdb?, how many physical files is it comprised of?, what are the specifications of the volume it is on? Do you have any other volumes on which you could place portions of tempdb?

What are the UBE's that are not running as fast as you expect? Have they been customized?

Try running this script to get an idea of what SQL is waiting on during the UBE runs:

<font class="small">Code:</font><hr /><pre>

select spid, waittime, lastwaittype, cmd, status
from master..sysprocesses
where waittime >100 and spid > 10

</pre><hr />