Umbraco crashes from time to time - NuCache.Content.Db is being used by another process
Hello
I am encountering this weird issue which I cannot explain.
So I got this Umbraco website that we've built for a client, which is hosted in Azure. The site works wonders, but from time to time (it's been quite while since this last happend), the site crashes and we have the restart the entire Azure AppService.
Checking in the Umbraco 8 Logviewer I find this error, the same error that we've encountered before if my memory serves me:
System.IO.IOException: The process cannot access the file 'D:\home\site\wwwroot\App_Data\TEMP\NuCache\NuCache.Content.db' because it is being used by another process.
Something seems to be holding the NuCache.Content.db file hostage, restarting the App service seems to solve it. But this is not a sustainable solution to the problem.
We have recently had a series of downtime because of this issue. The issue for us seemed to be because we had two instances of the Umbraco application on the same App Service Plan, one for the front end of the website and one for the backoffice. The configuration of each was as per the documentation.
It appears that although each were separate applications, they shared access to the same NuCache.Content.db file. This wouldn't necessarily be a problem provided that no attempt was made to move the NuCache.Content.db file.
However, my understanding is that Azure occasionally likes to migrate an App Service Plan from one VM to another for various reasons (e.g. VM health). You will see this in the logs when the machine name changes, e.g. WN1FRDWK1000S9.
When Azure attempts the migration, it will move one application at a time. During the restart of the first application Umbraco will realise that NuCache.Content.db file is still being used by the other instance and refuse to start up, throwing this error.
In our case, once the second application was migrated, the NuCache.Content.db file was released and allowed the first application to complete its start up. But this meant it was down for 10 minutes.
Solution
The solution for us was to ensure that (at least) one instance was always running using the NuCache.Content.db in-memory, i.e. IgnoreLocalDb = true. We opted for the CMS instance as it had lesser impact on the start up.
With the Azure slot swap process, it makes sense that the same issue is happening but between the two instances that are being swapped since by default the apps on both slots are running when swapped. This is why the solution of specifying WEBSITE_DISABLE_OVERLAPPED_RECYCLING = 1 in the app service settings of both slots will work in the slot swapping scenario because it ensures that both applications are stopped when the swap occurs.
An alternative would be to configure that both slots are configured to use NuCache.Content.db in-memory.
Umbraco crashes from time to time - NuCache.Content.Db is being used by another process
Hello
I am encountering this weird issue which I cannot explain.
So I got this Umbraco website that we've built for a client, which is hosted in Azure. The site works wonders, but from time to time (it's been quite while since this last happend), the site crashes and we have the restart the entire Azure AppService.
Checking in the Umbraco 8 Logviewer I find this error, the same error that we've encountered before if my memory serves me:
https://ibb.co/ZM4wbkx
Something seems to be holding the NuCache.Content.db file hostage, restarting the App service seems to solve it. But this is not a sustainable solution to the problem.
Has anyone else come across this issue?
Any suggestions on how we can solve it?
Many thanks,
Mathias
There are a few issues in github discussing this:
https://github.com/umbraco/Umbraco-CMS/issues/5035
https://github.com/umbraco/Umbraco-CMS/issues/6363
https://github.com/umbraco/Umbraco-CMS/issues/6546
There are a few possible solutions suggested, I think the recommended solution is this one.
Thanks Steve!
I followed the instructions from the recommended solution. Hopefully this will sort out our problem.
I tried both the solutions below, but neither of it worked for me unfortunately. I'm still facing the same issue.
https://github.com/umbraco/Umbraco-CMS/issues/6546#issuecomment-545224926
https://github.com/umbraco/Umbraco-CMS/issues/6546#issuecomment-593182604
I have the application running on Azure in two slots and i have made the changes to both the slots. Any help is greatly appreciated.
Hi all,
We have recently had a series of downtime because of this issue. The issue for us seemed to be because we had two instances of the Umbraco application on the same App Service Plan, one for the front end of the website and one for the backoffice. The configuration of each was as per the documentation.
It appears that although each were separate applications, they shared access to the same NuCache.Content.db file. This wouldn't necessarily be a problem provided that no attempt was made to move the NuCache.Content.db file.
However, my understanding is that Azure occasionally likes to migrate an App Service Plan from one VM to another for various reasons (e.g. VM health). You will see this in the logs when the machine name changes, e.g. WN1FRDWK1000S9.
When Azure attempts the migration, it will move one application at a time. During the restart of the first application Umbraco will realise that NuCache.Content.db file is still being used by the other instance and refuse to start up, throwing this error.
In our case, once the second application was migrated, the NuCache.Content.db file was released and allowed the first application to complete its start up. But this meant it was down for 10 minutes.
Solution
The solution for us was to ensure that (at least) one instance was always running using the NuCache.Content.db in-memory, i.e.
IgnoreLocalDb = true. We opted for the CMS instance as it had lesser impact on the start up.With the Azure slot swap process, it makes sense that the same issue is happening but between the two instances that are being swapped since by default the apps on both slots are running when swapped. This is why the solution of specifying
WEBSITE_DISABLE_OVERLAPPED_RECYCLING = 1in the app service settings of both slots will work in the slot swapping scenario because it ensures that both applications are stopped when the swap occurs.An alternative would be to configure that both slots are configured to use NuCache.Content.db in-memory.
is working on a reply...