|
|||
|
|||
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 |
|
|||
|
|||
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 |
|
|||
|
|||
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. |