Partition best practicies for built-in database performance?

[BradFelmey]

I have come to the conclusion that the Windows 2003 Server network stack sucks entirely too much for the traffic I'm pushing with HQ Server. The clients keep complaining that the server is busy and won't talk to them. This also manifests itself as the server spitting out erroneous availability metrics, which trigger alerts. Nothing like getting paged in the middle of the night about a system being down that really isn't. 😠

On to what I should have done in the first place - namely, put this on a quad-XEON Linux system with RAID10 for the database array.

Where does the built-in database (Postgres?) keep its data on the *nix platforms? Is it in the same location as the hq-server directory tree, or /var, or... ?

I want to set up a server tailor-made for the best HQ performance. With that in mind, does anyone at Hyperic (or elsewhere) have any data to suggest whether an Oracle instance would help performance over Postgres? We already have extra licenses for Oracle 10, so it wouldn't cost us any more to use that if there's any benefit.

[dgorman_hyperic]

Brad,
I would agree that if you are running HQ with alot of platforms, that a *nix app server would be a better choice.

We currently run ours on a dual-xeon (hqapp) with a quad-opertron (hqdb) with a RAID10 powervault with 14 drives. While this is overkill in many cases, if you start to approach hqapp slow downs here are some suggestions that might help, of which you may or may not already know.

1) Move HQ to a seperate dedicated box
2) Move the HQ DB to a deperate dedicated box. Give this box as much IO as you can (e.g. any DAS or NAS wil be fine.
3) Give the HQ DB as much RAM as you can afford.
4) The only thing that Oracle will give you over Postgres is that you won't hit a vacuum or index table lock scenario. Even with postgres 8.1, they still have the concept of vacuums, where it cleans up a table of the rows that are marked for deletion. This concept doesn't exist in Oracle. Also in postgres you can't create the same index in concurency.

If you have more than 150 platforms, what I would suggest is that (if you have the HW and SW) is:

1) dual xeon app server with 6GB minimum RAM. Mirror the root drives. Set 4GB for HQ java heap
2) dual xeon (or bigger - quad opteron) with 12 GB minimum RAM. Mirror the root drives and put your data on a DAS/NAS/SAN. Seperate your redo logs from your data.


Again, this is probably overkill in *most* cases, but if you want to go full performance this is what I would suggest.

Let me know if this helps.

[BradFelmey]

That's very helpful stuff. I currently have a P4/3.2 HT, 3GB RAM, mirrored SATA all on one partition (C:). HQ Server is running with all defaults, including whatever JVM resource allocations it ships with.

With 68 agents reporting, CPU is barely being touched on this system (average 4.7%). I've got over 2GB of available physical memory. The drive lights are on pretty solid, though.

I have available a dual-XEON 3.2HT, 8GB RAM, RAID1 SATA for OS, fiber-channel connectivity to an EMC Clarion. This is the system I'm looking at loading with SLES for our monitoring server. We have a lot of systems that aren't on the HQ system yet, so I need more performance than I have now.

I'll look into increasing the java heap for the HQ app, but as far as separating the Oracle redo logs from the DB, the HQ instructions specifically say to turn the transaction logs off for performance, since HQ's usage pattern will make Oracle choke if they're turned on. Do you have any input on that?

Thanks for the feedback. HQ is a great application so far, and I'm like a kid with a new toy. 🙂

[BradFelmey]

Hmmm, I am not very Java-proficient, it would seem. Can you point me in the direction of the proper location of the aforementioned Java heap setting?

[cwitt_hyperic]

I assume you've probably found this by now, but you modify the HQ java heap settings in the server startup script. Look for the "-Xmx" flag, and season to taste.

[cwitt_hyperic]

Marking as answered due to inactivity.

[BradFelmey]

Only inactive because nobody responded until you did. 😉

[cwitt_hyperic]

My apologies for the presumption. Did I help answer your question with that last piece of information, or do you need more detail?

[BradFelmey]

That was the answer I needed, thank you very much.

[cwitt_hyperic]

Excellent! And, you are welcome. 🙂