New Server Disk Configuration

rich Zed

rich Zed

New Member
We're getting a new server supplied shortly, to host our live database application.

Spec is in brief, an HP DL585 (2xCPU), 24GB RAM, 6400 HP/Compaq RAID Controller, and 2 Storageworks (?) SCSI Arrays. Each array contains 14 146GB disks (12 available + 2 Hot Spares). Machine running RedHat AS 4 (It will become part of a system running replication over three machines, but this is a testbed for the moment).

Our Linux/Systems Guy is planning on configuring each array to appear as one single disk, which consists of 6 disks mirrored in the same array (plus the hot spares), so on the box itself, we will only see two logical disks).

This configuration flys in the face of all I know about configuring hardware and disks for Progress systems, though I will admit that the majority of my knowledge goes back 8-10 years, and it's possible that disk and hardware technology may have moved on enough to make my performance tuning knowledge out of date.

I've referred to the old documentation I have, and also with the old Progress Performace FAQ (which is very old now): http://www.westnet.com/~gsmith/pperform.htm

What would be the consesus be on configuring this machine in the way our Linux/Systems guy thinks will work? I'm happy to go this way, if it's proven to be a reasonable way forward, otherwise I'm going to have to push for a Progress confuration as I understand it.

ta muchly for any comments

rich
 
If he's configuring it as a large mirroed and striped filesystem then it's not too bad. The main downside would be that there is no discrete disk for the AI files.

I'd probably take 8 disks and configure them as RAID10 (mirrored and striped) and then setup the other 4 as two sets of mirrored pairs. Thus ending up with something like:

/db -- 8 disks, mirrored & striped, effective storage 584GB
/ai -- 2 disks, mirrored, effective storage 146GB
/app -- 2 disks, mirrored, effective storage 146GB

I would not follow the ancient "put the bi on a dedicated spindle" advice unless I know that my main bottleneck is transaction throughput. Unless you're running a benchmark the main bottleneck is almost always read performance therefore the extra spindles are better used for the db (put the bi files on the db filesystem.)

The ai files should be on dedicated (and mirrored) spindles for robustness reasons not for performance reasons. If they are blended with the db disks any hardware failure that impacts the db also makes the ai files useless. Which defeats one of the main purposes of the ai files. Isolating them on a discrete filesystem also provides a bit of additional safety from human error like "rm *" (it's not perfect safety but it is a bit better...)

The /app filesystem is somewhat debateable. You could argue that the IO rate would be relatively low, which is probably true, and that therefore the IO would be better spent supporting the db but I find it helpful from a diagnostic perspective to isolate the non-db stuff away from the db.
 
Thanks Tom, very useful information. Particularly regarding the bi file location (how things change). The ai is a major bottleneck at present, sharing a HD with a temporary sort area (bad) - this will be addressed.

Yes, he's planning stripping and mirroring, this was something I was very keen on too.

The database itself is heavy read (extracts galore), with periods of heavy writing (imports), along with the normal day-to-day data entry (client/server).

I'm doing some work in the background on one of our test/development systems with regards to tuning the ai/bi files, which I hope will also help.
 
It would be really useful if he also setup a simple method of breaking the mirrors and making /db and /db' (db prime) available when needed. That sort of capability is very handy when you need to do a dump & load or recover from backup without overwriting the source db. Yes, you lose the mirroring during the time when you run that way but that is generally a short time frame and the risk vs the reward is worth consideration (of course it is ideal to have a completely seperate set of disks for that but that isn't always feasible...)
 
Don't fix what aint broke

Rich,

Knowing a BIT about the system, I can say you should tell the Linux Fraud to keep his hands off the configuration. Sure, they run Linux, but he clearly knows next to nothing about Progress.

There IS actually an issue with BI information on the server. It's certainly not the biggest issue, but one you want to keep to a minimum. Especially now that there is a fully fledged "Near Real Time" (don't ask about this anyone - we ALL knew it wasn't really a "Near Real Time" system, but the boss wouldn't call it anything else!) system creating and updating records at a high rate.

You've also got your direct imports which can create a bottleneck.

Are you still monitoring the database?

If so, you'll notice periods where the disk performance of the machine appears to freeze. I think this is linked with high writes to the DB.

You've also got a need to separate the WORK and TEMP disk areas as these certainly get thrashed during the nightly batch run.

The original configuration of the machines was not arrived at at random. Dave did not throw disks at the machine to see where they would land. There are *specific* requirements to separate various disk loads on the machine.

Make sure the Linux Fool is made aware of this and that the machine is configured exactly as the originals. There may be tweaks that can be done, but certainly not a radical shift away to a database unfriendly setup. The situation with AI sharing with temp isn't good, but I think was the best of some bad options. Getting it on a quieter disk would be an excellent idea.

If Linux Nincompoop is worried about reallocating disk space, then point him towards the LVM HOWTO pages for Linux. This allows easy reallocation of disk space in emergencies.

Yours

Duncan

P.S. Are you using the ramdisk for the extract runs yet? I remember that it wasn't set up to do this when I last saw things. This provides a dramatic performance boost to the extracts.

P.P.S I'm not pulling any punches with this reply, but then that's just my style!
 
lol wouldn't expect any less :)

o ramdisk is now in use
o monitoring - yes, but some nonsensical data appearing.. need to check how the vst tables are working now (do we need to run the vst tables update command now that we are on OE10, not 9?) - as always, on a back burner
o Direct Imports impact the database very heavily, though NRT coding has been improved to lessen this impact
o also looking to increase the block size on the file systems.. currently block size is 4096 and db/bi/ai on 8192.

Question had to be raised following a 'discussion' on the advantages of the current 'progress configuration' and the linux admin understanding on other systems.
 
VSTs do not need to be "enabled" in v9+. That was a v8 thing having to do with avoiding the need to change the db version number just to introduce them.

For monitoring my personal favorite :awink: is ProTop
 
Tom,

I've heard of ProTop before, but never got round to investigating it.

I worked with Rich and set up the barebones of a monitoring system that used RRDTool to capture the data. Graphing is then incredibly easy - as long as you collect the right data.

Duncan
 
drunkahol said:
The situation with AI sharing with temp isn't good, but I think was the best of some bad options. Getting it on a quieter disk would be an excellent idea.
Click to expand...

now sorted, with significant gains :)
 
You must log in or register to reply here.
Back
Top