Announcement

Collapse
No announcement yet.

Entry Procs and mod_hostinglimits

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Entry Procs and mod_hostinglimits

    Hi,

    I think I dont understand how Entry Procs is counted or we are dealing with an issue.

    We are using mod_fcgid with suexec to run php. Also we are using mod_hostinglimits. Our Apache is running worker mpm.
    What I understand is when new request is coming to php script it enters LVE context and then php-cgi process is spawned inside that LVE. After processing is done and request is completed the php-cgi process stays alive. That is expected as mod_fcgid manage php-cgi processes. Now, when request is done I would expect EP counter to decrease but I think it doesnt because php-cgi is still alive - in fact still running inside LVE. When next request is coming it might be increasing counter again but possibly it would enter the same LVE context. So we end up with hitting EP limit and having less php-cgi processes running, eg EP limit is set to 300 but there is only 20 php-cgi processes running. In this scenario we would expect EP count to be less or equal to process count. Is this our mistake we are using mod_hostinglimits along with mod_fcgid? We dont have any LVE specific settings for mod_fcgid.

    As per mod_hostinglimits docs: "mod_hostinglimits [...] Puts apache process used to serve that request into LVE for the user determined [...]" - what is being put in LVE: a whole apache process or a thread used to execute given request? Im asking this question because we faced an issue when heavy traffic site caused other sites to behave like they are running inside same LVE.
    When using suexec it will count EP double? I mean mod_hostinglimits increases counter and then suexec is doing the same. With mod_hosting limit disabled we saw that EP isnt counted at all.

    We are running bit old lve 1.1-0.37 and dont have a way to do update now. Im just looking for confirmation if things we see are issues already fixed in next versions or they are not lve issues and we should fix our config.

    Regards,

    PawelP

  • #2
    Pawel,

    The EP decreases, even with mod_fcgid, as we tie it to httpd serving the request, and not PHP process.

    Comment


    • #3
      How to explain situation when we have less running processes than entry procs? When hit the limit site stops responding but by the same time not all php-cgi processes are busy. This might be an impression only as I can really check what mod_fcgid is doing.

      Will it be enough to run mod_fcgi with suexec to put php into LVE and cage? If we would not want to count EP and rely only on mod_fcgid MaxProcessesPerClass limit can we stop using mod_hostinglimits?

      Comment


      • #4
        You will always have at least one running process per EP.
        You can see them using lveps -p

        Comment


        • #5
          lveps -p looks nice.
          Can I assume in lveps -p view EP should be less or equal to PNO? Is this possible to have EP>PNO?

          Comment


          • #6
            oh man, I see it now. EP include httpd.worker threads and thats why I have more EP than php-cgi processes running. If all php-cgis are busy apache will hold new connections and wait until one of php-cgis get free.

            Comment


            • #7
              Yes, that is correct behavior, and the main purpose of EP is to prevent apache slots from being overfilled -- this is exactly what happens in this case.

              Comment

              Working...
              X