Search results

Update update: I've been hit with this problem yet again (on a new server). It would be good to get the OLS defaults changed to something that works out of the box. It's been brought to my attention that a good alternative is to store all session information in redis. It's faster and in...

Update: I remembered that as far as Virtualmin is concerned, there was a fix added in 2020 that "will clean up sess_* files in each domain tmp dir that are older than 7 days by default" (https://archive.virtualmin.com/node/52635). However I concluded it's better to leave the Ubuntu behaviour alone.

I just suffered a similar issue (3 years later) and noticed a problem with the above answer and with the default lsphp config. Most sites these days run on Ubuntu which is Debian based, and session.gc_probability is deliberately set to zero there because session files are saved in...

I think it's recommended to set Max Connections to the same value as PHP_LSAPI_CHILDREN. There seems to be a huge variation in the best value for these variables, depending on the number of visitors, the type of sites hosted, the amount of available RAM and so on. In the absence of any guidance...

If it helps, I found that increasing PHP_LSAPI_CHILDREN did indeed eventually help. I had to increase it a LOT - it's currently at 100. Be careful, though. There's a risk that increasing it too much will cause the server to run out of memory and crash. This happened to me three days in a row at...

Thanks for the reply. There have been no more crashes since disabling "enableCache".

The last few days I've been getting segfaults about once a day. I've sent a core dump to bug@litespeedtech.com as requested. No call stack in the message. What do I do next? Just wait for a fix? Update: I tracked down the user ID of the most recent activity before the crash, and there are two...

I have some news on this (in my case) that may or may not help someone. There is a "stderr" log file at /usr/local/lsws/logs/stderr.log that I didn't know existed. It's enabled by default in Webadmin > Server Configuration > Log but not as far as I can tell accessible from anywhere (except...

I've just witnessed an episode of "dead lock" messages (after a couple of days of normal page loads). It's a Sunday evening, there's hardly any traffic in the logs. Network traffic is tiny (both directions). CPU usage and disk activity are normal. The problem has gone away now so I can't...

There's nothing relevant in the PHP error logs that I can see. I've been doing some testing and it appears the "possible dead lock" message may be a bit misleading, in that it appears at times of high load and disappears at quiet times without any interaction from me. Web sites continue to run...

My CPU usage generally looks OK to me. It's easy to blame server resources, but is adding (expensive) capacity really necessary? I'd like to see some evidence before doing that. In particular, if it's due to an attack I'd rather block the attack than spend money helping the attackers, therefore...

This might (or might not) be relevant as well. The server has been running on apache all week without problems. Yesterday though there was a sudden unexplained spike in disk activity, which seems to have been due to the server running out of memory and spending all its time swapping to virtual...

I've managed to reproduce the problem and here's the requested snapshot of "top"

OK, I'll try. It's an intermittent problem and has to be done out of hours so not sure how long it will take, bear with me.

Thanks for your response. I'm a bit reluctant to knowingly inflict pain on my users, but I'll do it once if we're prepared to gather all necessary information in one go. Which "resources" need to be monitored, exactly? I should say that the "possible dead lock" messages are much more common...

(Reposting this from a response to an older similar post at https://forum.openlitespeed.org/threads/possible-dead-lock-lsapi-application-help.4394/, because I've had no response and perhaps this is a better place. Happy to raise an entirely new issue if required. Sometimes you're damned if you...

I've recently had to stop using OLS (and return to Apache2, which does work but slowly) because of this problem. :-( I accept that it may not be a bug in OLS itself - the root cause is probably more likely to be a bug in a WordPress plugin or a misconfiguration of OLS that causes it to run out...