Progress on Linux

[skorpius]

hi!

our company is planning to move from HP-UX based progress to linux, we are currently using ssh to access our character-based applications & databases under HP-UX, can anyone suggest the best hardware configuration for a linux based server with 150 concurrent users?

thanks in advance . . .

 

[TomBascom]

The most significant inputs into figuring that out are workload, io rates and budget. None of which can be determined from your post. Version of Progress would also be useful information. If you are using a commercial application it might also be helpful to know which one.

Having said that, and without knowing the answers to the questions above...

I would probably be looking for something with around 8 cores, 32GB of RAM and a handful of SSDs. Maybe a couple of rotating rust disks for local backups and other low speed, high capacity uses. I would also configure it with multiple network interfaces - one for the SSH users and another for "admin" tasks (like backups and such).

 

[skorpius]

thanks, sir tom

here's our current configuration:
HP Server rp5470 (8GB, 4 x 36GB, rather old since 2005)
HP-UX release B.11.11
Progress v9.1D
peak number of users: 85

applications/databases:
Billing & Collection System
Stocks Inventory System
Accounting System

we're planning to move to OpenEdge ABL, with web based customer inquiry, & install a new blade on our HP blade system based on Suse or RedHat linux

we got 250K customers & 8 satellite collection offices, we backup to our NAS blade & tape for offsite, largest database is 12GB, we're having some trouble sometimes during peak hours, ie, printing, denied logins, slowdowns, etc.

hope this gives a clearer picture, thanks again, sir tom . . .

 

[Rob Fitzpatrick]

Hi skorpius,

It sounds like there are a few issues here that could be examined separately. And some more info about your present system would be helpful. For example, how is your storage configured? (e.g. RAID 1, RAID 10, RAID 5, other?) Your DBs are small, but storage config can have a big impact on performance (especially RAID 5, in my experience).

DB clients: are they local? Remote? A mix?

DBs: You mentioned three applications; is it one DB per app or multiple?

Printing: how is this configured? Is your DB server also a printer server, or are you printing to resources on another print server?

Denied logins: does this mean application login? Database? OS?

"Slowdowns": how are these observed? I/O throughput reduction? Perceived reduction in client application performance? CPU spikes on the DB server? Your standard IT checklist applies here: look at the processes on the "slow" system during "normal" performance, and again during "slow" performance; look at CPU usage and disk and network IO. If it is a client/server app that is slow, add in network tracing, both before and after (Wireshark/tshark/tcpdump/your tool of choice). Also, it this box dedicated to these three apps or does it host other apps?

Network: if this is a client/server app, have you confirmed that your link speeds are what they should be, and full duplex? Does your network carry any significant load apart from your production traffic (batch file transfers, etc.)?

And probably the biggest question: based on your anticipated migration time to the new platform, and the severity of the current issues, is there value in trying to determine their root cause? I hope this helps.

 

[skorpius]

thanks, rob, here are additional infos:

RAID: we removed our RAID configuration, so, our 4 HDs are independent
DB clients: mix
DBs: multiple
Printing: our DB server is also our only printer server for the apps
Denied logins: OS
"Slowdowns": varied causes mostly at peak time
Server dedicated only to those 3 apps, might also host 3 more after migration
Network: full duplex, batch procedures are done at night


thank you very much, sir, hope these infos will help you determine what we will need.

 

[TomBascom]

From what you have revealed so far it would seem that you currently have some fairly serious performance and configuration problems. You would probably be well served to bring in a consultant to work with you on those problems and before you buy new hardware. Even though that might seem superficially expensive it could save you a ton of wasted money and aggravation from buying the wrong hardware for the wrong reasons.

Or you could keep posting vague bits and pieces of the problem every week or so for the next couple of years and we can try to guess what the issues are. That won't cost you anything except end-user frustration.

 

[skorpius]

thanks, tom . . .

From what you have revealed so far it would seem that you currently have some fairly serious performance and configuration problems. You would probably be well served to bring in a consultant to work with you on those problems and before you buy new hardware. Even though that might seem superficially expensive it could save you a ton of wasted money and aggravation from buying the wrong hardware for the wrong reasons.

Or you could keep posting vague bits and pieces of the problem every week or so for the next couple of years and we can try to guess what the issues are. That won't cost you anything except end-user frustration.