Hardware sizing

cnicola

Hi guys,

I was just reading the Hardware Sizing for 4.00 (hopefully the latest version) and I noticed that for DBs > 80GB and 150+ users they recommend 2 mirrorred drives for log files and 6-7 for data.
I always thought that you needed more than that especially for the log.

I am trying to decide some HW sizing for a client that has about 35-40 users but 160+GB DB. Most of my other SQL sites I have a 2 to 3 proportion for log drives versus data drives . But now I am utterly confused. ](*,)

What is your experience with this?

DenSter

yeah the hardware sizing guide is sometimes not very realistic. It's not about the size of the drives either, the most important part is the number of spindles. More smaller spindles will always perform better than fewer bigger spindles.

Probably the most important bit as far as performance is to have FAST drives for the logs, and to DEDICATE those drives, not to use them for anyhting but the logs. You might have much more disc capacity than you need for the log, but you have to resist the temptation of using it for other purposes.

cnicola

Hi Daniel,

I know they might not be too realistic. And actually right now I have tons of drives just trying to decide how to use them.
I have one Drive Box with 14 drives (146GB) split into 2 RAID 10 arrays: one with 10 and the other with 4 and one Drive Box with 14 drives (36 GB) made into one RAID 10 array.
So my options right now are:

1. Use all 14 146GB drives for data and 14 36GB drives for log
2. To avoid rebuilding the bigger box use 10 146GB drives for data, 4 146GB drives for temp (got to use them for something ) and then the 14 36GB drives for log.

(to put the data on the 36 GB drives is not option since the db will soon go over the 200GB that it offers).

But now I am wondering whether 14 drives for log is overkill. And whether option 2 is good enough and I can avoid the work of rebuilding it.

P.S. And to add to confusion right now the whole system runs on the 14 146GB drives with data on the 10 and the log on the 4 and it is running at an OK speed 8-[

bbrown

I find 146 GB drives a complete waste for Navision systems. You are paying for disk capacity you will never use. Your system performance will drop off long before you use the drive capacity. (Remember: more/smaller is better than fewer/larger). Seeing a lot of these lately. I think the hardware sales people are getting commission bonuses on them.

DenSter

I don't know though, as long as they're 15K drives it shouldn't matter much. I've heard that 36 GB drives are getting pretty hard to find, and 146GB drives are actually less expensive. You have to realize though that 2 146GB drives does not equal 8 36GB drives as far as performance, no matter what the hardware vendor says.

The most common mistake is to purchase half the number of discs with twice the capacity. For performance it's the number of spindles that matters, NOT disc capacity. Even if you can only find 15K rpm 300 GB discs, you still need to purchase a lot of them to have good performance, and accept 'wasted' disc capacity.

What I see a lot is that because there is so much disk space, the 'wasted' disk space is used for file storage or something like that. The log drive is now used for the logs for 5 different systems, including test and development databases, and performance takes a hit. I can't stress it enough that you HAVE to dedicate the log drive for the log files for your NAV production database only. Even if you have a development database, put the log files for that database on the data drive.

I'd probably try to split the 36GB drives into two arrays, one (say 10 or 8 of them) for the log files and one (the remaining 4 or 6) for TempDB, depending on how big your tempdb is. Then, I'd use the 4 146GB array (the one that you're now using for TempDB) and make that a striped array (this could even be a RAID 5 if you have to have hotswap) for storing backup files.

DenSter

By the way, so what if you have 14 discs, and so what if some people think that is overkill. Your system runs at OK speed and that is what counts. Now you set up proper maintenance, maybe purchase a product that I could recommend , tune the indexes, eliminate redundant SIFT, you can make your system fly. I don't know about you, but that I would call a success story.

Alex_Chow

bbrown wrote:

I find 146 GB drives a complete waste for Navision systems. You are paying for disk capacity you will never use. Your system performance will drop off long before you use the drive capacity. (Remember: more/smaller is better than fewer/larger). Seeing a lot of these lately. I think the hardware sales people are getting commission bonuses on them.

Like Daniel said, it's next to impossible to find 146 GB drives with 15,000 RPMs. I don't even think they make them anymore.

Instead of focusing on the recommendations, sometimes, you just have to purchase what these salesperson have to offer.

bbrown

Alex Chow wrote:

bbrown wrote:

I find 146 GB drives a complete waste for Navision systems. You are paying for disk capacity you will never use. Your system performance will drop off long before you use the drive capacity. (Remember: more/smaller is better than fewer/larger). Seeing a lot of these lately. I think the hardware sales people are getting commission bonuses on them.

Like Daniel said, it's next to impossible to find 146 GB drives with 15,000 RPMs. I don't even think they make them anymore.

Instead of focusing on the recommendations, sometimes, you just have to purchase what these salesperson have to offer.

Yes, but 72 GB 15K drives are readily available. I would rather have 12 72 GB drives then 6 146 GB drives.

Hardware sales to day are a volume game. The margins/commission levels are extremely low. The salespersons goal is to close the deal and move onto the next customer.

DenSter

If the recommendation is to get 8 drives, then get 8 drives. If it says get 8 72GB drives, don't think that you can get the same performance out of 4 146GB drives. If 146GB drives are less expensive than 72GB drives, then by all means get the 146GB drives. Just get as many as recommended, and resist the temptation to save money and go for half the number of drives.

cnicola

I know everything you guys are saying. The 146GB are SAS drives BTW.
And I wanted maximum number of drives in each box which is 14 and they got 146GB in one of the boxes. I got what I wanted i.e. max number of spindles and they got what they wanted and the salesman got what he wanted. If I follow this right everyone was happy
Also my db is tuned to a pretty good level (which is why it is running OK on only one box now). And that was due to Jorg Stryk not the product Daniel was about to name drop again ... Nothing wrong with Hynek's product but sometimes you guys push it a little too much (I might just get banned for this last sentence :-$ :-# :whistle: )

And thanks for all the input.

DenSter

I don't think so, I was not about to name drop anything, if you recall I said 'a product that I could recommend'. I try to make it a point not to use the name, because this is not advertising space. I just believe in that product, and it's the one that I work with, so I mention what can be done with it. I have never said anything bad about any other product, as there is more than one way to do things. If anything I would love to work with other products and see how that works.

bbrown

One of our largest clients recently purchased "that product". we have gotten very positive feedback from them about "that product". We are considering recommending it to another client. with continued positive feedback we may even consider making it a standard recommendation to our SQL clients.

This has been an unsolicited comment

DenSter

<edit>

cnicola

bbrown wrote:

This has been an unsolicited comment

Ok Ok it was late and I was cranky.
As you noticed though I did not say Hynek's product is not good. I went to Hynek's class in Atlanta and I know he has worked with MS to improve Navision 5.0 so I am sure the man must know some things :P
So perhaps we should push this more to MS. Maybe we can convince MS to make it part of the std package and let us concentrate on arguing with our clients over implementations issues instead of SQL issues