Just to clarify: are you running the “5 minute ping hack” against a blank php file on a domain set as FastCGI, and yet still encounter unresponsive periods?
I have two affected websites. Both were initially on Fast CGI; on one of the sites I turned off FastCGI so that it can act as a baseline. When the ProblemX is active, this site is consistently unresponsive.
A cron job pings the other site at varying intervals of between 4 and 8 minutes (easily arranged using “custom minutes” in the cron panel); when ProblemX is active, this site is consistently responsive when the ping interval is 4 or 5 minutes, and consistently unresponsive when the interval is 7 or 8 minutes (6 is borderline).
ProblemX vanished from both sites, apparently simultaneously, some time between 12:25 PST and 12:30 PST 16th Jan, and has not (yet) returned. Hopefully Dreamhost have found SolutionX.
I think that’s a “no”. Good stuff.
And everything is running okay now without the need to manually keep PHP loaded with a 5 minute ping - yet you have not received a clarifying response from Support on what the issue was or if it was rectified?
Ugh, this is quite annoying. I set up a cron job to curl one of my files every ten minutes, but it either isn’t resolving the issue or I can’t run it often enough.
I try not to get too upset about this kind of thing, but I literally have to tell customers that it will take 30 seconds to view my site.
sXi, " … have not received a clarifying response from Support on what the issue was or if it was rectified?" Well it’s still early in California, so I’m not expecting anything quite yet. Will post when response arrives.
Still looking like ProblemX is solved, on my sites. All sites responsive, both on CGI and on FastCGI, without need for pinging.
Omnivore, " … cron job to curl one of my files every ten minutes," but if the problem affecting your site is the same as ProblemX, then ten minutes is not a small enough interval; should be 5 minutes or (to allow a safety margin) 4 minutes. Easy to set up in the cron panel: select ‘custom minutes’ and click on every 4th minute (might seem laborious but it’s only 15 clicks in all).
P.S. Omnivore, have you got a support ticket open? Maybe Dreamhost can’t automatically solve the problem for everyone but need to do something manually on each site that they are advised there is a problem on.
PHP FastCGI should close gracefully after 5 minutes of inactivity. A 5 minute ping might keep it active, circumventing the issue.
Are you saying this is expected behavior?
[quote]Easy to set up in the cron panel: select ‘custom minutes’ and click on every 4th minute (might seem laborious but it’s only 15 clicks in all).
P.S. Omnivore, have you got a support ticket open? Maybe Dreamhost can’t automatically solve the problem for everyone but need to do something manually on each site that they are advised there is a problem on.[/quote]
I tried that with every 5 minutes, but it said it was too many selected minutes.
I did open a ticket and referred them to this thread.
Yeah, it’s expected behavior. All good systems should free resources that aren’t being used - in this case an cgi process and it’s memory.
Keep in mind I am just a regular user like you and am firing blindly here
With regard to your “too many selected minutes”… where are you seeing that?
Good point! As I have just now discovered, there is indeed a limit on the number of minutes that it will accept. I guess this limit is around 10. (I didn’t run into it previously because I had selected a variety of different intervals, which happened not to break the limit.)
Evidently we need to be more resourceful. Let us install two interleaving cron jobs, each of which pings at 8 minute intervals, so that between the two of them they ping at 4 minute intervals.
So I’ve just tested this as proof of concept, and it seems to work, but one needs to make a copy of the command file so that they don’t both try to run the same file.
Hopefully the prospect of thousands of their customers installing so many cron jobs will prompt Dreamhost to hurry up and fix the problem for everyone.
Are you now saying you never actually ran a 5 minute ping?
Forgo the Sherlock Holmes malarkey; just spit it out man. In whatever language you feel comfortable with.
[quote=“sXi, post:28, topic:59014”]
Yeah, it’s expected behavior. All good systems should free resources that aren’t being used - in this case an cgi process and it’s memory.[/quote]
Well, sure, but if it’s going to shutdown it should be able to start back up in less than 30 seconds. I don’t think that would have been acceptable 15 years ago. It certainly isn’t now.
I imagine something very specific is going wrong here. Whatever it is it has some sort of timeout of 30 seconds… then when that is over the PHP gets interpreted and the whole thing finishes in 30.x seconds.
Are you going to answer the question you cropped from that quote or do you actually prefer pissing in the wind?
Sorry, I thought that was already covered. That error message appears on the “Add New Cron Job” page when selecting minutes.
Cool. Bear with me on this (like I said I’m shooting blind here). I have no idea what servers or domains either of you blokes are talking about because neither of you have given even that much information up. The 5 minute thing was simply to see if keeping the cgi process active would circumvent the problem - and from what I was reading it appeared to be working. But now it seems it couldn’t have worked at all because you can not even call a script at 5 minute intervals.
It would be helpful to get a clear perspective sans ProjectY versus WindowX and 8 or 17 minutes alpha.
Panel > Cron Jobs > Edit
When to run: Custom
Minutes: Select Minutes
What it means is that a cron job is not allowed to run more than x times in any hour (where probably x = 10).
The cron job which I ran for about 72 hours ran at:
00 mins past the hour
04 mins past the hour
08 mins …
00 mins … etc
Thus it ran 10 times in each hour, and tested intervals of 4 mins, 5 mins, 6 mins, 7 mins and 8 mins.
Just seen this:
You can call a script at intervals down to 1 minute; what is limited (to 10) is the number of times you can call it in each hour.
Thanks, now I can appreciate what you were talking about. I’m positive I could cron at more regular intervals when I first signed up here but maybe something changed or I am simply mistaken. Ten an hour is just a smidgen outside what would be required - as you’ve noted. This 10 per hour thing could be “by design” to inhibit users running pseudo-persistent apps or the likes. Anyway, if you have a Pingdom account (free one is okay) you could have it load the blank file every 5m. Of course it will only work if the Pingdom server can actually contact the server at the time, but I believe they still use a minimum of 2 servers per ping; so chances are reasonably good that your blank.php will receive a hit at the 5m mark.
Edit: and of course you could ping more often than 5 minutes, too.
Or alternatively, one can achieve pinging every 5 minutes by using two Dreamhost cron jobs.
One job runs every 10 minutes, at xx:00 xx:10 xx:20 xx:30 xx:40 xx:50.
The other runs every 10 minutes, at xx:05 xx:15 xx:25 xx:35 xx:45 xx:55.
There’s just one minor complication, which is that you have to make a copy of the script file so that there is one script file for each job. (If you don’t do this, the cron setup panel complains.)
Still no response (apart from that “not forgotten” note) from Dreamhost on my open ticket. My websites have been working fine since Jan 16th (without any need for pinging). I still don’t know if this is because Dreamhost fixed something or because the problem disappeared spontaneously.
I should also mention that phpMyAdmin on that domain in unbearably slow. I figure the problems are related, but here the delays are often 1 minute or more for each request. And it’s not like the original problem where after I make the first request, things seem fine for a few minutes.
That sounds more like a load issue. If you have a shell user enabled, log in and check top (or type uptime).
Would I login to the webserver or the mysql server (this is not something I typically do)?
I suppose it could be a shared load issue, but my site is not really getting any traffic.