CommitCRM performance issues

Hi all,

I'm hoping someone can help here or confirm if we have an issue internally.

We run CommitCRM on its own dedicated virtual server (Hyper-V) running Windows Server 2008 R2 Standard (I know it is old now), with 2 vCPUs and 8GB RAM assigned. The host is nowhere near maxing out in terms of RAM or processor usage.

We are running version 22.0.0.2 of Commit CRM with the SQL upgrade with 19 licenses/employees.

We are finding that the database seems to lock up quite often and in general all searching is quite slow even when running CommitCRM directly on the VM itself. I was wondering if anyone else has had these kind of issues and could offer any advise?

The server is obviously rebooted regularly and we have tried re-indexing etc.

CommitCRM support have been very helpful trying to pinpoint the issue.

However, we are now at the stage where the next step is to load a physical server and see if there are any issues like that. Due to our very heavy reliance on the CommitCRM software this is not really an option without spending lots of time out of hours and we would lose our replication and failover via Hyper-V.

This is getting to the stage where if we cannot resolve we will need to consider a new CRM as it is slowing our team down.

Does anyone have any ideas?

Thank you in advance for any help/advise,

Graeme

Does the VM have its own network connection or is it shared?
How is it connected to the network are the switches over loaded?
How does CommitCRM run on the server if you launch the application
What are the disks doing? are they dynamic or fixed?

Hi Blueplanet,

Thank you for the reply.

The VM does have a shared network connection but this is not maxing out either, we have 3 gigabit switches all connected by fibre. The host server has a RAID 50 admittedly on SATA 7.5k drives but this is usually OK for these kind of applications and SQL databases.

The CommitCRM application does also seem to run slowly on the VM itself which makes me think this is a database issue rather than CPU, RAM, network or HDDs. I just wanted to see if anyone else had ideas...

Thank you again

Graeme

Hi Graeme
we have not seen any slowness but we only have 5 users.

Have a look at the disk performance (you can enable it by diskperf /y). also the response time

Could you copy the VHD file to another machine with a SSD and run a test (dont forget to disable the network)

Shut down all VM's on the server and see if it improves.

If you think its a SQL problem could it a delay in the read and write to the drive.

Paul

I have been waiting for a dedicated server to become avialable for testing at the moment we are at capacity. I could try on an i7 with an SSD...

sounds like possibly over commiting of the CPU (how many virtual cores do you have v physical) or Virtual Queue's are enabled?

https://www.dell.com/support/article...nabled?lang=en

we have 12 people using, apart from the odd freeze & snapshot schedule its ok

added AV exclusions?

Thanks 5c,

The CPU on the host seems fine only at 15- 20% usage, isn't VMQ enabled by default? we have not disabled and the network cards are not Broadcom so it shuold not really have this issue. All great checks to make though, thank you.

Our AV is ESET and CommitCRM is excluded.

Thanks again for all this help, it is at least making sure we have checked everything.

suppose the next question would be - what are the other VM's like (speed wise), i've seen bad performance with a built in RAID card (no cache)?

We have Commit installed in the Azure cloud on a single VM server. We moved it to the cloud to provide greater access to all users of the system in remote locations within our company.

We are running the SQL version. No performance issues to speak of.