Wondering if anybody else has run into this issue.
Nop was running just fine on v4.0. We did the upgrade to 4.1; and initially everything appeared fine. However, after a while (typically anywhere from 2-8 hours), the site simply becomes unresponsive and won't load. A simple IIS reset fixes the issue.
Checking IIS; we noticed there's always some request in one of the worker processes that ends up hanging and crippling the site. We applied the fixes detailed out in the high memory usage post here; and while that made the site faster; it didn't resolve the issue.
For the time being; we've increased the worker processes for the application pool from 1 to 2. This seems to prevent it from happening; but it's really more mitigating the issue rather than fixing it.
We're running nop 4.1 in a multi store setup with 3 stores; 2 of which get significantly more traffic than the 3rd. It's on a Windows Server 2016 box with more than enough resources available; we're not pinning the CPU or memory. The nop installation runs under a single application pool in IIS. Database is SQL 2016 and lives on a separate database server; which also doesn't have any sort of resource issue. We've made a few minor customizations, and we're running the Prisma theme from nop-templates.com.
Any ideas?
Site freezes up after 4.1 upgrade
- 1
- 2
MVP
Silver Solution Partner
Certified Developer
- 2639
- 42712
- 1/21/2010
- United States
Hello,
Do you have any errors in the System Log?
You can enable the stdoutLog if there aren't any errors related to your problem in the Systeml log by editing the Web.config like this:
<aspNetCore requestTimeout="00:07:00" processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" forwardWindowsAuthToken="false"
stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />
Regards,
Stoyan
Do you have any errors in the System Log?
You can enable the stdoutLog if there aren't any errors related to your problem in the Systeml log by editing the Web.config like this:
<aspNetCore requestTimeout="00:07:00" processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" forwardWindowsAuthToken="false"
stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />
Regards,
Stoyan
- 14
- 90
- 3/26/2018
- United States
Logs really didn't have too much; mainly a lot of timeouts coming from nop's scheduled tasks. It's almost like the site completely freezes; where none of the requests complete (successfully or not)
We'll set it back and monitor in order to get it to happen again; I'll post again when we have more details
We'll set it back and monitor in order to get it to happen again; I'll post again when we have more details
- 14
- 90
- 3/26/2018
- United States
OK; tried this again this morning. Lasted about 2 hours before it started clogging up.
Unfortunately, both stdout and the error logs are clean. Nothing in there that indicates any sort of problem. Stdout has a whole bunch of info messages; no errors, and the nop log has nothing in it either.
It's almost like the request just hangs there; never completes, never times out, just sits there and blocks everything down the line. The only common thread (if you can even call it one); is that the clogging request seems to be a category page about 75% of the time. Other times it's an image (which is weird cause it's a static file); or a call to /getfilteredproducts. Occasionally we'll see one for something in checkout (like getshippingoptions)
Unfortunately, both stdout and the error logs are clean. Nothing in there that indicates any sort of problem. Stdout has a whole bunch of info messages; no errors, and the nop log has nothing in it either.
It's almost like the request just hangs there; never completes, never times out, just sits there and blocks everything down the line. The only common thread (if you can even call it one); is that the clogging request seems to be a category page about 75% of the time. Other times it's an image (which is weird cause it's a static file); or a call to /getfilteredproducts. Occasionally we'll see one for something in checkout (like getshippingoptions)
- 51
- 301
- 1/10/2019
- United States
jborghesani wrote:
Turn on trace flag 1222 in the database. This will cause any deadlocks to be logged in the SQL Server logs. I also noticed the nopCommerce database does not have Read Committed Snapshot Isolation enabled. Turning this on can greatly reduce the possibility of deadlocks occurring, but there are some slight risks involved, depending on the queries being executed. In general, enabling Read Committed Snapshot Isolation is a good idea as it reduces the amount of lock resources being used as well as reducing the potential for deadlocks.
https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/snapshot-isolation-in-sql-server
https://blogs.msdn.microsoft.com/bobsql/2017/05/23/how-it-works-sql-server-deadlock-trace-flag-1222-output/
OK; so after more digging and investigation; it definitely feels like a deadlock issue.
Does anybody have any tips for trying to hunt this down? So far we haven't been able to reproduce this locally.
Does anybody have any tips for trying to hunt this down? So far we haven't been able to reproduce this locally.
Turn on trace flag 1222 in the database. This will cause any deadlocks to be logged in the SQL Server logs. I also noticed the nopCommerce database does not have Read Committed Snapshot Isolation enabled. Turning this on can greatly reduce the possibility of deadlocks occurring, but there are some slight risks involved, depending on the queries being executed. In general, enabling Read Committed Snapshot Isolation is a good idea as it reduces the amount of lock resources being used as well as reducing the potential for deadlocks.
https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/snapshot-isolation-in-sql-server
https://blogs.msdn.microsoft.com/bobsql/2017/05/23/how-it-works-sql-server-deadlock-trace-flag-1222-output/
- 14
- 90
- 3/26/2018
- United States
Sounds good; we'll give this a shot.
We'll see what we get for results; but it seems like it's more of an IIS deadlock; rather than a sql one. So far sql logs have been clean (and activity monitor hasn't shown anything strange while these issues are going on). What's leading me to think it's a IIS deadlock is because of all the requests piling up when we look at the worker process requests for the nopcommerce application pool.
I'll keep you posted
We'll see what we get for results; but it seems like it's more of an IIS deadlock; rather than a sql one. So far sql logs have been clean (and activity monitor hasn't shown anything strange while these issues are going on). What's leading me to think it's a IIS deadlock is because of all the requests piling up when we look at the worker process requests for the nopcommerce application pool.
I'll keep you posted
- 1
- 2