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

Discussion in 'Install/Configuration' started by wanah, Dec 15, 2013.

  1. wanah

    wanah Member

    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:
    <?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 :

    Code:
    xcache.ttl   =              3600
    xcache.gc_interval =         300
    xcache.var_ttl   =          43200
    xcache.var_maxttl   =       43200
    xcache.var_gc_interval =     300
    
    Thanks !
    Last edited by a moderator: Dec 22, 2013
  2. NiteWave

    NiteWave Administrator

    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.
  3. wanah

    wanah Member

    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
  4. NiteWave

    NiteWave Administrator

    what's the value
    max_execution_time
    in phpinfo() ?
  5. wanah

    wanah Member

    Its currently 60 seconds.
  6. wanah

    wanah Member

    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.
  7. NiteWave

    NiteWave Administrator

    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.
  8. wanah

    wanah Member

    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 ?
  9. NiteWave

    NiteWave Administrator

    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:
    http://www.litespeedtech.com/suppor...peed_wiki:multiple_phps_in_control_panel_lsws
  10. wanah

    wanah Member

    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.
    Last edited: Dec 18, 2013
  11. wanah

    wanah Member

    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 ?
  12. NiteWave

    NiteWave Administrator

    I managed to set up 1 virtual host from apache's httpd.conf
    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.
  13. wanah

    wanah Member

    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…
  14. NiteWave

    NiteWave Administrator

    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.
  15. wanah

    wanah Member

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

    Thanks
  16. NiteWave

    NiteWave Administrator

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

    wanah Member

    I've updated the script to :

    PHP:
    <?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 :)
  18. wanah

    wanah Member

    It is a new process that causes the problem :

    Each time I waited a bit longer :

    Code:
    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).
    Last edited: Dec 19, 2013
  19. NiteWave

    NiteWave Administrator

    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.
    Last edited: Dec 20, 2013
  20. wanah

    wanah Member

    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)

Share This Page