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