Another 8mins down due to another frozen pool issue. X(
Sorry to poke my nose in, but may I suggest that with this issue, Jodo support sets up some monitoring on the site which is having an issue.
That way, they know exactly when the issue occurs and can examine the symptoms. Unfortunately, intermittent problems are the hardest kind to find solutions for.
So if Jodo can monitor it the same way you do, they will be able to see the problem in action and that will help work out what it might be.
It would also be good if any other people with sites on Win13 comment on their uptime, to see if the problem is server-wide or restricted to something about that pool or those sites.
Another suggestion is that you ask Jodo for a check-list of things to do when it happens - i.e. 1) ping the url, 2) do a tracert to see if it’s a routing problem, etc.
Sounds like a tricky problem, hope you track it down.
Schooner, I am researching why your DNN site is not loading properly on a pool refresh, the pool you are in is consuming 320MB of ram and recycling after a few hours, and it is taking a long time to regenerate. There are 2 other sites with this issue, one is community server 2.0 one is DNN 3.2.2, and then yours. The CPU seems to be quite fine since making some changes a few weeks back.
There has to be a reason it is going slow.
Oh, and the site move to win15 did not happen because of an error, then the day after when I got the ticket from hsphere about an error it got DDoSed pretty bad, so I did not move it at that point. The thing is, any time your pool recycles it takes 5 minutes or so to regenerate, and this is not correct, other DNNs taking only 13-15 seconds for the initial generation.
Antic, we already have monitoring on it, each minute.
This month this site, in this pool, has had 1 hour 30 minutes down, which I will agree is too much, but to fix the site we have to login and recycle the pool as it happens after a pool recycle, and a new pool recycle fixes it, but it still takes 5 minutes to come up after reycling.
One thing I’d recommend here is checking the modules and exception logs, and make sure it is not throwing any in the background.
320MB sounds like a lot of RAM for one pool… is there perhaps some code that’s being inefficient with resources?
These are just standard DNN 3.2.2 sites, nothing special with them. Not sure whay we are having all these issues. I can only think it is someone else in our pool. We also had an issue with a DNN 2 site today as well. We also have a DNN 3.2.2 site on another Jodohost server that has no issues.
The problem with monitoring is that many will report the domain live when it fact it is frozen in the pool. Unless you monitor to a specific aspx page you can get false positives when in fact the page itself will not load.
Schooner, we monitor to a specific aspx page 
It also looks for this test on the page so be careful about changing it: welcome to atlanticenergy.ca
There are very few sites in the pool your are in, and none of them are asp.net
Ok thanks. I chekced the DNN logs and there are some errors but nothign that would be na issue I don’t think. I’m going to disable all the scheduler events just to see.
It had been working fine for over a week, then yesterday it seemed we had isues again.
If the issue is with our sites please let us know. We got the impresssion to date that it was other processes that caused issues but not us directly. I’m looking into the DNN exception errors now to see if I can track those down.
Is it a big job to put schooner’s sites into their own pool for a week to see if they’re the ones using all that ram? Might help to determine if another site (especially if it’s classic ASP) is mucking things up.
edit As an afterthought, could be a DNN-related or 3rd party .NET DLL leaking memory. Some objects in .NET are still unmanaged (bitmap object for one, I believe)
if we put it in its own pool(we did it once before) the pool sometimes recycles mroe often, however I think this was before all the monitoring on it, with ours monitoring each minute, and the others, it should not have a problem “staying alive” now.
I will move it to its own pool later today, so it doesn’t do down right now, I will do it at 9pm EDT.
Thnaks very much Stephen. We have a monitoring service hitting it as well plus a service that hits the site to keep it alive so it should always be live from all that.
We just replaced a module that was giving an exception error but doubt it was the cause of any issues but worth a shot.
I moved pools and it compiled in a whole 14 seconds, of note is that it compiled in 35 seconds a few moments before I changed pools after a pool recycle, so its going much better.
And about the other part, there was a server side issue that got resolved, and it has been some time now, but you can still clearly see it on the cpu graph:
right about the 4th/5th of the month
http://jodopulse.com:8090/Win13/view.htm?id={76AADB38-3835-4D3B-971C-4D77F33707F8}
Thanks Stephen. I’ll keep an eye on things and post any issues. Appreciate all the work you put into tracking this down.
I am showing a lot of downtime this morning, I don’t know what happened, but I know no tech emailed me, I need to check on this 
Hopefully it was a monitoring error and not correct.
Seems Prakash did something this morning on your pool, but he had already left, I will speak to him first thing when he comes in tonight.
He has some performance monitors and other items setup, I can seem them on the server.
I haven’t noticed any downtime so far Stephen.
Ok great, must have been prakash working on it, he possibly even paused it for a little while, as a pause shows as downtime.
We jsut got an alert that http://www.schoonersolutions.com/ is down and its down for us as well.
Here is the Hyperspin test as well:
Quick Test - Hyperspin Network Tools
It appears to be back up again now.
It is not in the same pool, and the auto pool recycle just hit for that domain pool, I have not seen any problems in generating files for that domain, so it was probably 30-45 seconds tops that it was generating and “down”
recycles are a necessity, without them all the RAM would be exhausted.