It's been taking down the whole app, unfortunately.

How much traffic have you been able to handle with your Django app?

I would love it if we could get half a million page views a day without going down. Are the rails sites that get that many page views daily on shared hosting or one of the other plans?

i have had problems with the samurai too...

i currently have 2 rails apps "live". they got killed more or less regularly since the samurai is protecting the txd shared hosting plans.

the first app is feedication which gets not that much traffic. i guess it was about 30 pageviews a day when the site was up and running 24 hours a day. though the app got killed by the samurai more than just occasionally so i let it down for now.

my reasons: the code is about one year old. ive made no updates to the code and the service is pretty much an rss-feed aggregator that stores feeds in the db, displays them and updates the feeds regularly. and my take on it was: i wrote that app back when i was somehow familiar with rails but i would consider the code pretty ugly now. and i am no expert in telling how resource intensive the app is. so im not really sure right now what to do with the app but unless i dont get the time to get into the code i think its more wise to let the app off of txd shared hosting as i dont consider it as nice neighbour behaviour to deploy an rss-feed aggregator (i guess feed aggregators caused enough trouble on rails already) with code that i wrote 1 year ago and i consider bad code.

the other app is my typo blog over at geek.textdriven.com. the blog gets killed occasionally. the typo version is rather old and i did some manual updates to newer typo versions over the time...but the last update is also some months old now. i don't know what exactly is wrong with my typo app but it certainly doesn't behave as i would expect. there are problems with assigning categories to articles and it seems like caching doesnt work (as i initially wondered how my typo app could be too resource intensive even if lighty serves static html - at least that ought to happen with a working typo version iirc). so i will put my own blog/website built with rails online later today if i manage to don't fall behind my schedule again. and then i will look if the samurai problems are gone.

conclusion: i have 2 apps...both have problems with the samurai...the problems arent really surprises to me and i take the samurai behaviour as advice for me personally to either look into the code of my app or put the app offline.

but im eager to learn more about your problems with the resource restrictions as i would really be interested what i can expect my vc account to host if i plan to host a rails app that is more critical to downtime than a hobby project.

I am having a similar experience. I have an app that has at most 3 concurrent users. It was running for 4.5 days then got killed by Samurai for hogging processor.

What I don't understand is how it can have used more than 30 cpu seconds over 90 real seconds when noone - noone at all - was accessing it. It was killed off 5 hours after the last entry in production.log and the access logs. And 10 hours before the next one.

I thrashed it in my dev environment and watched the resource usage but never logged any issues.

I would really welcome any recommendations on how to troubleshoot.

I don't know if it will help anyone specifically with their problems, but I can speak for myself. I have my blog and another site I run that uses Rails running on the same account. I was having trouble keeping them up for more than a few hours at a time. On occassion, it would be because the Samurai killed a zombie process. On occassion, it would be for the CPU seconds limitation.

I followed the advice of others and tracked down the pretty much completely rewritten instructions, thanks mostly to Harry in this thread who pointed me to this thread where a lot of useful questions are asked.

There are two key changes in the directions since I did them several months ago. First, you're not encouraged any longer to have lighttpd start up the FCGI processes itself. The new instructions encourage you to start them externally and to reference their location in the lighttpd configuration. The spawning of the FCGI processes is now an additional task that you as the account holder have to face, but it's not that difficult. A template script is provided in the walkthrough.

The second major change is the mechanism for starting lighttpd and the Rails FCGI processes. That's done using much more of an rc.d sort of startup script than just a one liner that you toss off to start lighttpd and have it do the rest.

There are some other file structure related changes. It shouldn't take you long to walk through the changes and get your site back up. (I think it took me about an hour.) Since then, my apps haven't been killed more than once. Granted, when they do die, I'll need to learn to do something different to start it up again, but oh well.

Also, I found that the cron job that I had to start lighttpd on boot had been removed, probably a vote on how old my setup was. Not complaining, I think it's totally appropriate to require us to be good tenants. But those who haven't checked it out because it's been "working" since they set it up should do the same.

I'm pretty much exactly in your situation, dpdnolan. I deployed following the TxD manual. My app has used 21 seconds of CPU in total since Monday, the last time I restarted it. Yet it can get killed at apparently random moments for using more than 30 sec in 90 real seconds, even if there is not a single request logged in the preceding hours. Pretty damning, and hard to troubleshoot.

What does Rails do when it's not processing requests? Could something like garbage collection cause this?

We've been heard. Yay TextDrive!

Yay, something changed, but it's bordering too little, too late. My client was pretty close to slitting throats when he found out what was going on. Neither of us got any e-mail and he wasn't aware of the RSS feeds. That didn't matter, though, since the notice about Samurai was posted on the forums about a week after it was put in place.

Between Cardero reboots, the week it took to work with Webmin and Apache to get proxying->lighttpd going (why is it failing? why did I have to file a ticket even though I followed the scant documentation?), minimal notice about the new process-slaying policy (the least they could have done was told everybody upfront by e-mail!), TextDrive is making my blood boil.

We'll see if my laughably tiny application continues to get slayed unnecessarily.

I don't know where else to go for the moment so I hope things improve in the Solaris era, which I hope will start sometime before the year is out.

ubernostrum wrote:

Eh. I haven't had problems.

And to recount something I posted on one of the Django mailing lists (in a discussion about Django-friendly hosting), I have yet to achieve an understanding of how people have "mission-critical" business and client sites which don't merit more than basic shared hosting. That's like saying that you've got your company payroll and it's of the utmost importance to get it delivered safely, but you transport it in the open bed of a pickup truck with a guard whose only armament is a watergun.

#endrant

Yea... kind of struck me as odd too. I guess I just assume that most companies are too stupid to understand the concept so the cheaper the better. Just turns around and bites them in the ass and they sit there angry at the host for their ignorance.

Well come one now, it does depend, some people develop and maintain sites for quite large, or at least medium sized business. Others, myself included, develop smaller sites that might only get a fraction of the traffic compared with yours, and yet those visitors are ecommerce customers buying products from small cottage industries. Fair enough I'm in the UK where business is perhaps smaller (I don't know the US) but these can easily be described as 'mission critical' since they are the primary revenue stream for a small family business. That they only have 3,000 customers and don't need anything more than shared hosting doesn't mean that it's not mission critical, neither does it mean it's not 'real business'.
Please don't take offence at this, but I feel sometimes that some of you who deal with larger, perhaps international business and 'enterprise' forget about the little people making small but important income from the Internet age - and for a lot of these people moving to a dedicated hosting solution would mean a massive drop in profit for something they absolutely don't need, it would mean running their businesses not to feed their kids but so that they can pay TextDrive (or which ever hosting company they use) their hosting fees. Please don't judge shared hosting account holders as second-class citizens and unworthy of 'proper' support just because you're lucky or skilled enough to be working for the big fish. Peace everyone.