Native DB RAID configuration question

TLC

Hi there,

This is a hardware question.

I'm running NAV 2009 native database (30GB, 50 users) and it's currently running in a virtual environment (Hyper-V). The disks are really proving to be a bottleneck due to the way it was originally set up.

We have 8 disks raided together (Raid 1+0) which make up 1 logical disk upon which there are various virtual machines. One of these is a NAV VM which has 1 VHD for the OS and one VHD for the DB. The DB on the VHD is split into 5 chunks.

This entire setup doesn't make any sense to me whatsover, and I believe is the reason behind the bottleneck.

My idea is to buy 6 new 72GB 15k SAS drives, and RAID 1 them together in pairs to create 3 logical disks on which I would put 1 chunk each.

I would still run the NAV DB Server from the VM, but I would point it at the DB on the new drives.

The questions I have are:

1. is this the right thing to do/do you think this will increase performance and
2. should I use pass-through disks, or should I create a VHD on each of the new logical drives, attach them to the VM and put one chunk on each of the VHD's?

Any other suggestions would be welcome.

Thanks in advance.

kriki

First some questions:
How much is your database cache?
Are you using commit cache?

TLC

Hi,

Thanks for your reply.

Database Cache (KB): 102400
Commit Cache: Yes
Object Cache (KB): 32000

kriki

You have a 30GB DB but ONLY caching 100 MB of it........

Try to raise the cache as much as possible. The max I have been able to reach is 950 MB. In theory it should be possible to have 1000 MB, but it is not always guaranteed. I think it is because NAV tries to allocate the memory in 1 big chunk and if there is no big chunk like that available, the service does not start.

An easy way to do it but (YOU REALLY HAVE TO KNOW WHAT YOU ARE DOING!):
-stop your service
-run regedit and search for the name of your service.
-You will find a 'subdir' with CACHE,COMMITCACHE,DATABASE,DisplayName,.... in it.
-Change the CACHE from your current value to 950000 (decimal value).
-start your service. if it gives an error, you might try to restart the server to clean the memory.
-connect a client and check if your cache is 950MB.

After some warming up, you should have a lot better performance both for reading as for writing.

TLC

Thanks, I'm familiar with changing the cache size. I'll give it a go tonight once all my users are logged off and see how it goes.

TLC

Well I changed the cache size, and I also moved the database to another VHD since it was on the system disk, and I guess it's marginally speeded things up. The disk queue on the DB disk is consistently quite low, yet on the system disk (and the one the Database Server is installed on) the queue is still regularly going above 1. Is there anything I can do to prevent this?

kriki

Some other things to check:
-Can you check if it is the reads or the writes that have problems?
-Can you check if some other VM is doing a lot of IO on the disks?

PS: in the beginning it will not gain a lot because the cache has to be warmed up. Later on it should be faster.