Re: New hardware thoughts

[Ben Suffolk <ben@xxxxxxxxxxx>]

Cheers Shane,

> Sounds like you have a very good idea of what to expect. Are these  
> solid stats or certain estimates? Estimates can vary when it comes  
> time to start.

The figures all come from how my application interacts with the  
database when an event happens, so the scaling of operations to each  
other is accurate, the number of operations is based on an estimate  
of the user interactions with the system, and the figures I quote are  
actually peak figures based on some fairly reliable research. If  
anything its more likely to be lower then higher, but I like to air  
on the side of caution, and so its important for know that I can  
sustain this throughput, and have an easy upgrade path in the  
hardware I choose now to help if I do need to be able to cope with  
more load in the future.

Although I suspect the next step would be to move things like the  
logging into a separate database to relieve some of the load.

> I would think 2 will cope with what you describe but what about in  
> 12 months time? Can you be sure your needs won't increase? And will  
> the cost of 4 CPU's cut your other options? If all 50 users may be  
> running the 3rd part at the same time (or is that your 50 trans. a  
> second?) then I'd consider the 4.

The 50 connections is pretty much a constant from the distributes  
application servers, and only some about 10 of them will be  
responsible for running the transactions , the others being more  
related to the reading, and logging, and thus mainly staying in the  
idle state. So I would think I am better off keeping the CPU sockets  
spare, and adding them if needed. Thus enabling more budget for  
memory / disks.

> 8GB is a good starting point for a busy server but a few hundred $  
> on the extra ram can make more difference than extra disks (more  
> for the reading part than writing).

I guess any spare budget I have after the disks should be spend on as  
much memory as possible.

> What you describe plans several times 300 inserts to logging plus  
> 150 inserts and 50 updates and 1 read a second plus occasional  
> reads to the logging and user data.
> Will it be raw data fed in and saved or will the server be  
> calculating a majority of the inserted data? If so go for the 4 cpu's.

The inserts are all raw (pre calculated) data, so not work needed by  
the database server its self bar the actual insert.

> Generally more disks at slower speed - 2 10K disks in raid 0 is  
> faster than 1 15K disk. More disks also allow more options.

Yes I figured striped slow disks are faster then non striped fast  
disks, but what about 8 striped slow disks vs 5 striped fast disks?  
How do you calculate what the maximum throughput of a disk system  
would be? I know that a bit academic really as I need to split the  
disks up for the transfer log and the table data, so the large number  
of slower disks is as you suggest better anyway.

> I might consider RAID 5 with 8 disks but would lean more for 2 RAID  
> 10 setups. This can give you the reliability and speed with system  
> and xlog on one and data on the other.

Assuming I go with 8 disks, I guess the real question I have no idea  
about is the speed relationship of the transfer log to the table  
space data. In other words if I have 2 disks in a raid 1 mirrored  
pair for the transfer log (and the O/S, but can't see it needing to  
use disk once boots really - so long as it does not need swap space)  
and 6 disks in a raid 1 + 0 striped mirrored pair would that be  
better than having 2 equal raid 1 + 0 sets of 4 disks.

Clearly if the requirements on the transfer log are the same as the  
table data then 2 equal 1+0 sets are better, but if the table data is  
at least 1/3 more intensive that the transfer log I think the 2 + 6  
should be better. Does anybody know which it is?

> Sounds to me like you have it worked out even if you are a little  
> indecisive on a couple of finer points.

Thanks, I guess its more about validating my thoughts are more or  
less right, and helping tweak the bits that could be better.

Regards

Ben