[Resolved] xcache resetting cache every 36 seconds if left idle

[wanah]

Hello,

We are trying to get Xcache up and running with litespeed's process group.

I noticed that the cache was not kept for long to I set up a simple php script to test what was happeing.

<?php

$time = time();

if (!xcache_isset("time")) {
	xcache_set('time', $time);
}

$xcachecurtime = xcache_get('time');

print('xcache cache duration : '. ($time - $xcachecurtime). ' seconds.');

If I refresh the page every 35 seconds the cache stays accessible however if I leave the script idle for 36 seconds or more the cache is reset.

It's not an xcache issue, nor is it PHP as I even set max_execution_time to 60 seconds and it did not change the cache being reset after 35 seconds.

I've searched in litespeed's settings and haven't found one that corresponds to the 35 seconds.

Here are all my time related settings :

General >
Graceful Restart Timeout (secs) : 1200

Tuning >
Connection Timeout (secs) : 600
Keep-Alive Timeout (secs) : 5

External App >lsphp5
Environment : LSAPI_MAX_PROCESS_TIME=600
Initial Request Timeout (secs) : 600
Connection Keepalive Timeout : 120
Max Idle Time : -1

What setting am I missing ? Is there a new setting for the process group children ?

I see process group parents that are never killed, which I believe is the Max Idle Time : -1, why would xcache's variable memory be reset every 35 seconds ?

This time (35 seconds) is reproducable, it always works if called within 35 seconds and always is reset starting at 36 seconds.

My Xcache settings are :

xcache.ttl   =              3600
xcache.gc_interval =         300
xcache.var_ttl   =          43200
xcache.var_maxttl   =       43200
xcache.var_gc_interval =     300

Thanks !

 

[NiteWave]

just bump up this thread, just read it and looks like a good test case.

what's the xcache, php, lsapi, lsws version ? just to make it more clear.

 

[wanah]

Hello,

I'm running CloudLinux's PHPSelector.

I ran my test with PHP 5.4.26 + Xcache 2.0.1 + Litespeed lsapi 6.6 + litespeed 4.2.6

 

[NiteWave]

what's the value
max_execution_time
in phpinfo() ?

 

[wanah]

Its currently 60 seconds.

 

[wanah]

Just tested with php 5.4.22 and xcache 3.1.0, same problem, this time it's closer to 30 seconds (30 seconds ok, 34 not ok) then 35 that the cache is reset.

 

[NiteWave]

I tested the script at suEXEC daemon mode
initially, it always displays this error message:
"Warning: xcache_isset(): XCache var cache was not initialized properly. Check php log for actual reason in /usr/local/lsws/DEFAULT/html/test/xcache.php on line 5 ..."
after googling, it's because of
xcache.var_size=0
after set
xcache.var_size=1M
in php.ini, the script output as expected

it's lsphp-5.5.6 + xcache 3.0.1 in suEXEC daemon mode.
not test under suEXEC ProcessGroup yet.

 

[wanah]

How long can you wait in between two refreshes before the cache is reset ? It should be able to be left idle for the sime specified in the xcache settings.

I'm trying to find out how to fix why the cache is reset in the following situation :

I call the script in my browser. I wait for 40 seconds and refresh the script. The counter should not be 0 but around 40 seconds.

Is there something i need to set to prevent the 30 second timout ? Or is the new processgroup still not compatible with memory based cache systems ?

 

[NiteWave]

I can wait very long between two refreshes

can you test suEXEC daemon mode at the same time, so can compare with suEXEC ProcessGroup

the 2 mode can run at the same time. i.e., some accounts run in suEXEC daemon mode, some run in suEXEC ProcessGroup, some run in suEXEC Worker

just create a test account and add a new external app lsphp5-daemon, and have this account to run in suEXEC daemon mode.
the document is here:
https://www.litespeedtech.com/suppo...unning-multiple-versions-with-a-control-panel

 

[wanah]

It's under suexec process group that I need this to work.

The suexec deamon mode doesn't work for us as opcache fails due to the fact the cache would have to be larger than what APC and Xcache can cope with.

Also you can not do variable cache safely in suexec deamon mode, only in the processgroup mode.

Each user needs to have his own cache, we've got about 200GB of unused memory and want to enable a cache per user.

I have enabled php selector, on this server so I have all users in the process group mode. I think it would be easier for you to test putting just one user in the processgroup mode than me reverting just one user to the deamon mode.

 

[wanah]

Also, could you ask your developpers if there is a variable to set the timout of a forked process in processgroup mode or something similar with a 30 second timeout ?

 

[NiteWave]

I managed to set up 1 virtual host from apache's httpd.conf

Max Idle Time : -1

and can reproduce this issue.

it looks that this value(-1) not effective, it's equal to 30 seconds in suEXEC ProcessGroup mode.

I set it to 3600 (1 hour), can last long time (so far 10 minutes)

can you try this setting at your environment.

 

[wanah]

I set Max Idle Time in litespeed's settings to 3600 then to 1200 but no luck it still resets after 30 seconds.

It does sound very likley that this is something to do with that setting not working.

In Extranal App > lsphp5 I've got :

Max Connections
1000

Environment
PHP_LSAPI_MAX_REQUESTS=1200
PHP_LSAPI_CHILDREN=1000
LSAPI_ALLOW_CORE_DUMP=0
LSAPI_MAX_PROCESS_TIME=600

Initial Request Timeout (secs)
600

Retry Timeout (secs)
0

Persistent Connection
Yes

Connection Keepalive Timeout
120

Response Buffering
No

Auto Start
Yes

Command
/usr/local/bin/lsphp

Back Log
100

Instances
1

suEXEC User
empty

suEXEC Group
empty

Run On Start Up
No

Max Idle Time
1200

Priority
0

Memory Soft Limit (bytes)
122880M

Memory Hard Limit (bytes)
163840M

Process Soft Limit
2500

Process Hard Limit
3000

Don't know if this helps…

 

[NiteWave]

the settings looks ok.

can you put a phpinfo() along with the test php script in 1st post of this thread, to confirm it's lsapi 6.6 ?

the test script is working as expected under my simplest test env (only 1 apache vhost) . if not working with your much complicated env, maybe it's relating to cloudlinux.

 

[wanah]

I've sent you a private message with the URLs.

Thanks

 

[NiteWave]

received. can you modify the test script, to print
posix_getppid()
posix_getpid()
posix_getpgid()
posix_getuid ()

 

[wanah]

I've updated the script to :

<?php

$time = time();

if (!xcache_isset("time")) {
        xcache_set('time', $time);
}

$xcachecurtime = xcache_get('time');

print('xcache cache duration : '. ($time - $xcachecurtime). ' seconds.<br />');
print('posix_getppid : '.posix_getppid().'<br />');
print('posix_getpid : '.posix_getpid().'<br />');
$pid = posix_getpid();
print('posix_getpgid : '.posix_getpgid($pid).'<br />');
print('posix_getuid : '.posix_getuid().'<br />');

I've also just updated Cloudlinux's phpselector in the hopes that tonights update might resolve the issue but it hasn't.

Thanks

 

[wanah]

It is a new process that causes the problem :

Each time I waited a bit longer :

xcache cache duration : 11 seconds.
posix_getppid : 1047197
posix_getpid : 1047200
posix_getpgid : 1047197
posix_getuid : 504

xcache cache duration : 37 seconds.
posix_getppid : 1047197
posix_getpid : 1047200
posix_getpgid : 1047197
posix_getuid : 504

xcache cache duration : 72 seconds.
posix_getppid : 1047197
posix_getpid : 1047872
posix_getpgid : 1047197
posix_getuid : 504

xcache cache duration : 0 seconds.
posix_getppid : 1048346
posix_getpid : 1048349
posix_getpgid : 1048346
posix_getuid : 504

We can see that a change of pid did not clean the cache but a change of the process parent id happened when I waited longer than 35 seconds (about 45 seconds).

 

[NiteWave]

We can see that a change of pid did not clean the cache but a change of the process parent id happened when I waited longer than 35 seconds (about 45 seconds).

so the root cause is parent lsphp5 process killed and started a new one.

your setting
Max Idle Time 1200
not work. I think it's related to cloulinux php.

 

[wanah]

It's a shame there is no sub-numbering for lsapi versions. Like for exemple 6.6.1, 6.6.2, how can I tell if cloudlinux used the latest version of lsapi when they packaged their php with 6.6 ? I will try and test this with the native php ( version 5.3)