NAV 2009 client slow on Hyper-V

nielsvdc

So we are planning to move our infrastructure with NAV 2009 from a hardware environment to a virtual environment. But the first tests on our virtual platform are going bad with performance. But it looks like the NAV client is de bottleneck.

We are running NAV 2009 R2 build 6.00.33194 classic client. NAV is maintained by our partner, who has build a retail supporting environment inside NAV. So we are not programming NAV ourselves.

Our current platform is:

- HP DL380G5 with2 core and 32GB memory - Attached are 2 MSA60's 40 SAS disks RAID10 - Running Windows 2008 R2 - SQL Server 2008R2 as database

Out new platform will be:

- HP C7000 blade 3PAR SAN attached using SSD and SAS disks - BL460 with 2 cores and 256GB - Running Windows Server 2012 Hyper-V hosts - Windows server 2012 R2 VM for the SQL Server 2008 R2 NAV environment - The VM is assigned 6 procs and 128GB of memory.

The new hardware is a big improvement compared to the current hardware platform.

What we are now testing is on the new platform is a long running tasks that is dividing our itemstock over about 250 stores, according to the available central stock and sales history in the stores. In our current platform this process takes about 5 hours to run. But on the new platform this process takes more then 7 hours with the same data. Not what we expected to happen.
The task is running in the NAV client. Analysing the hardware performance we found that the hardware has no problem with performance. It looks like the client is just slowing things down on the new platform.

Does anyone have experience with moving to a virtual (Hyper-V) environment and ran into the same problems? Do you have any suggestions in things to check/change to improve performance?

Thanks.

Marije_Brummel

Adding an extra layer on top of dedicated HW almost always costs performance. There is no way you can outperform dedicated HW with virtualisation.

However in your case it can be related to the SAN too. If the previous config was DAS the data has to travel from the server (SQL) to the SAN and back via a virtual layer.

With SSD, network throughput can be the bottleneck. What connection do you have between the san and the server? What third party SAN do you use?

nielsvdc

If we look at the assigned hardware for the VM, it should be better than the dedicated HW. Processor is not really applicable for the process we are running, memory assigned to the VM is 4 times more and the underlying SAN disks performance should outmatch the old DAS MSA's. Our current HP 3PAR C7200 SAN is directly connected via fiber to the C7000 bladesystem. There is no extra switch between. If I'm correct there are 4 8Gb fiber connections between the SAN and bladesystem.
The I/O capability difference between the current HW DAS and SAN is about 10 times higher in favour of the SAN. We planned this, because we want to move our entire HW infrastructure to the bladesystem. But this is the first server, so not much performance is taken yet from already running VM's on the baldesystem. This we can also verify with reports, that the SAN is not performing at it's max yet. Running the NAV process sometimes askes to about 30% of what the SAN is capable of.

DenSter

One more thing you should plan for is the easy with which you will be able to create VM's for various purposes. Instead of just one dev and just one test box, in no time you will have 15-20 VM's running for all sorts of purposes. The controller will want one with a copy of production for reports, you'll have a System Test, a Unit Test, and a Acceptance Test VM, and maybe you will want to have a number of different development environments to facilitate different releases at the same time. Your current plan may be for virtualizing your current setup, but you will have many more VM's running that you can imagine now.

These virtualization efforts always start out great, and they ALWAYS run into scaling problems.

Slawek_Guzek

Hi

1. Disable hyper-threading on host machine
2. Decrease number of CPUs assigned to VM - try retesting with just 2 vCPUs or even 1 vCPU only.

Slawek

nielsvdc

Thanks Slawek. These points I will check.