Search results

(should point out to anyone else reading this (prospective LS users etc) that we've been using LS for 2 1/2 years and its been incredibly solid / never had any problems. fixing this problematic script (as it should have been) has eliminated the problem - more trying to protect against my own...

can't use lsapi - we've made customizations to mongrel, and they're running secondary servers. any other possibilities? 1 vhost definitely taking down all the others (and it wasn't a cpu/mem issue, everything seemed fine - only odd number i could find was that "80 requests in processing")...

>Maybe you can consider to create a external app for each vhost, for PHP, use PHP suEXEC. Not sure what you mean here. Each vhost has 3 external apps linked to mongrels. >Your Inital request timeout is too low, keep it at 60 or the longest time that a request would take. Agreed, but I...

Hey, The Whole LS server was hanging up today for a few hours (no sites responding). Restarting it would fix it for 5-10 mins but then the problem started again. In the end I tracked it down to an external app that was hanging and that in turn was causing its virtual host to a large number of...

I'm not using apache httpd.conf, The "htaccess allow overide" is set to none and there's no .htaccess file in the dir. Again, its only effecting .php files so I think it might be related to phpLsapi. Again, its only happening in 3.3, 3.2.4 was fine. thanks

I've upgraded to 3.3 and the admin dir of our wordpress installation now gets a 403 error. This is only happening with php files, and the regular blog pages work fine (/blog/ and all perma links work, but /blog/wp-admin/index.php does not work). File perms are fine. I looked at the demo...

thanks mistwang. i'll try it out and let you know if the problem continues.

thanks mistwang, thats great news.

Hi mistwang, There's output in my previous post #5, it hasn't changed any since the problem occured in May (but see attached and below). I can't tell if Mongrel is sending a valid response back. Restarting mongrel or lwsw when it is occuring stops the problem, but it'll happen again five...

After 3-4 months on new servers, this problem has returned again. I'm pretty sure it has nothing with the apps code (definitely between mongrel and litespeed). While the problem is happening I can view the cached page in question fine in a browser, and all the mongrels seem to behave fine when...

it was 2.2.6 that had the problem for me, and the problem went away with 3.1.1, but this was part of a migration to a completely different setup (two boxes, fresh installs of all packages etc) so it could easily have been something else. sorry i haven't got more to go on :(

what seems to be happening is some sort of loop between mongrel and lightspeed. using strace i can repetitions of one file, for example writev(4, [{"GET /flower_delivery/florists_in"..., 441}, {"X-Forwarded-For: 74.124.192.171\r"..., 35}], 2) = 476 in lightspeed and a similar line saying read...

attached is some strace output from lshttpd (also here http://www.arenaflowers.com:8080/strace_output.txt if the attachement didn't work). interestingly, when it runs it squishes lshttpd back down to about 3%. (it was at 35-40% before i started the trace, and would go back up again if i canceled...

i'm using 2.2.6 at the moment, a friend had an unsmooth upgrade to 3.0 (upgrade failed and he scrubbed the directories and installed fresh) so i'm waiting a month as we're switching hosting providers then anyway. i'm using poll, though if its recommend i can switch to epoll - i assume thats...

i've been using litespeed for almost a year now on a rails/mongrel based site, but in the last few weeks i've been noticing cpu load spikes. up until today i thought it was to do with some changes in the ruby app, but today watching 'top' i've noticed that the lshttpd process occasionally spikes...