The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Reduce FastCGI memory usage via WHM

Discussion in 'Workarounds and Optimization' started by Duplika, May 9, 2012.

  1. Duplika

    Duplika Well-Known Member

    Joined:
    Feb 26, 2005
    Messages:
    56
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Buenos Aires, Argentina
    cPanel Access Level:
    Root Administrator
    Twitter:
    After reading a couple of threads about PHP handlers, we thought FastCGI is the best alternative in a shared hosting enviroment considering security and performance.

    Yet, FastCGI seems to be RAM hungry so I'd like to know a couple of things:

    1. Do you guys suggest we make any changes at the Include Editor? Will that override any kind of improvement cPanel releases with an update regarding FastCGI configuration?
    2. Where do you suggest we add the configuration changes? In All Versions of Pre Main Include or where exactly?
    3. Will configuration changes at Apache Configuration >> Global Configuration reduce the server's memory usage? Any setting in particular that we should take into account?
     
  2. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    somewhere over the rainbow
    cPanel Access Level:
    Root Administrator
    1. I do suggest using /usr/local/apache/conf/includes/post_virtualhost_global.conf for configuration changes for FCGI. I highly doubt cPanel will ever add directives for customizing FCGI, since we do not recommend the handler in our documentation ->Apache PHP Request Handling

    2. I've made the suggestion where to add the directives above.

    3. I don't know if any changes there will reduce the memory usage, but reducing timeouts and getting rid of keep alive or reducing the timeout for it would help.

    Of note, I've been benchmarking DSO, DSO + mod_ruid2, FCGI and suPHP using gnuplot and Apache ab tool and I've found FCGI doesn't perform as well as DSO + mod_ruid2 as was expected. i'm uncertain why anyone would use it at this point. Once I have the full benchmarking completed, I will post a thread on it. I'm just saying, we recommend people not to use it in our documentation. It's had numerous issues properly handling graceful restarts. Most people don't have the time or expertise to modify the directives to get it working properly. It doesn't handle multi-site servers well. I don't know why anyone would use it and about a year ago before all these things came to light, I used to periodically recommend it. I am no longer a proponent. Now that mod_ruid2 exists as part of EasyApache, I see little to no reason for FCGI to be utilized.
     
  3. -GR-

    -GR- Active Member

    Joined:
    May 2, 2012
    Messages:
    42
    Likes Received:
    0
    Trophy Points:
    6
    cPanel Access Level:
    Root Administrator
    Tristan,
    Have you had any issues with mod_ruid2 and mod_security in any of your testing? I have tried dso/mod_ruid2 and it does work great and you also get the benefit of being able to use an opcode cache. However when I was using it I was having issues with mod_security and the permissions to the logs for mod_security. I have seen these errors have been asked about and I guess there is a bug associated with it.

    Just curious to hear your findings with them.
     
  4. Duplika

    Duplika Well-Known Member

    Joined:
    Feb 26, 2005
    Messages:
    56
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Buenos Aires, Argentina
    cPanel Access Level:
    Root Administrator
    Twitter:
    That's pretty interesting Tristan, thanks for sharing that.

    I'm going to search the forums but if you have any link where I can see problems that might arise from switching from FastCGI to DSO / mod_ruid2 on a shared hosting server, please let me know.
     
  5. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    somewhere over the rainbow
    cPanel Access Level:
    Root Administrator
    I don't have testing for mod_security that would trigger high levels of alerts for mod_security to occur, but I've heard the same reports. mod_security having issues is less severe than the Apache graceful restart issues plaguing FCGI, though, since those issues prevent Apache from properly starting and cause it to hang, which matters quite a bit more than mod_security would for errors. While mod_security might be important, it isn't at the level of importance of Apache itself running.

    Additionally, if your server has low memory, suPHP actually uses the least amount of memory in the tests I've done. FCGI and DSO both hold onto the processes longer and have high memory usage, causing the server to use up around 2GB of memory for 1000 total requests hitting the machine at 50 concurrent requests per connection attempt using ab. suPHP didn't keep holding the connections as long and the memory footprint was far reduced. On memory constrained systems, suPHP is going to be the better choice even though it loads more slowly with slower response times. On high memory systems, DSO + mod_ruid2 is going to be the better choice, since the system could handle the memory consumption and would benefit from the speed up. Since FCGI uses approximately the same amount of memory and loads more slowly than DSO + mod_ruid2 under the default directives FCGI has, I'm at a loss as to why it would be used on a high memory, multi-site server rather than the alternative.

    Frankly, the main reason I've been performing these tests were due to what appeared to me to be invalid information being posted about memory consumption and load times for suPHP versus DSO and FCGI on the forum not that long ago. I wanted to see for myself what benchmark tests would show for load, response times and memory for each of them.
     
  6. Duplika

    Duplika Well-Known Member

    Joined:
    Feb 26, 2005
    Messages:
    56
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Buenos Aires, Argentina
    cPanel Access Level:
    Root Administrator
    Twitter:
    It would be interesting to know:

    • suPHP runs slower than DSO / FastCGI. How much slower? It indeed uses much less memory, maybe the difference is very slow and there is no reason to use FastCGI at all.
    • If memory usage is the same in DSO / mod_ruid2 vs FastCGI, then what's the real advantage? With FastCGI you can also use Worker MPM while on DSO, Prefork is the only choice.
     
  7. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    somewhere over the rainbow
    cPanel Access Level:
    Root Administrator
    I don't yet have the benchmarks completed, so I cannot show the exact differences, but suPHP was approximately half as fast for response times over DSO. DSO was faster than FCGI in the tests, but not nearly as much of a difference as suPHP. As for the advantage, mod_ruid2 runs all processes as the user versus FCGI which only runs PHP ones as the user. This means you have html pages, images, everything running as the user on the account. Also, I was comparing mod_ruid2 with /home/username/public_html chrooted, making it more secure than any other option available even suPHP. Next, I've repeatedly mentioned the fact that FCGI has bugs related to Apache graceful restarts and it hanging. Also, FCGI can cause assorted errors due to the directive settings. While they allow more fine-grained control of settings, most people don't know how to configure those options and sites can not function for coding without knowing the reason why the script if failing simply due to some FCGI setting.

    FCGI also doesn't perform well on multi-site servers due to how processes are handled.

    I could go on and on and already pretty well did above previously. Our documentation doesn't recommend it. I don't recommend it. Most other technical support staff I know wouldn't recommend it. If the above numerous reasons why haven't already explained it, then I really don't have anything else that could further sway someone from using it.
     
  8. -GR-

    -GR- Active Member

    Joined:
    May 2, 2012
    Messages:
    42
    Likes Received:
    0
    Trophy Points:
    6
    cPanel Access Level:
    Root Administrator
    Can I make a request of having php-fpm thrown into the benchmark testing as well? I know it currently isn't supported in EA but there was talk of supporting it once PHP 5.4 was released and then a matter of time till it would be added.
     
  9. Duplika

    Duplika Well-Known Member

    Joined:
    Feb 26, 2005
    Messages:
    56
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Buenos Aires, Argentina
    cPanel Access Level:
    Root Administrator
    Twitter:
    Great Tristan, again thanks for your time and comments. I'll investigate what's the best way to make the switch to DSO + mod_ruid2.
     
  10. xanubi

    xanubi Well-Known Member

    Joined:
    Jun 28, 2006
    Messages:
    86
    Likes Received:
    1
    Trophy Points:
    8
    I've run on my cpanel/cloudlinux servers, with 200 accounts the following (the experience was made on 5 servers = 5 x 200 clients = 1000):
    1) DSO + mod_rui2 (apache mpm prefork)
    2) SuPHP (apache mpm worker)
    3) FastCGi (apache mpm worker)

    Conclusions after one 3 weeks of each configuration:

    1) DSO + mod_rui2 (apache mpm prefork)
    The first is very but very problematic, mod_security has many errors, it doesn't work correctly, and our clients (like the majority on other hosters), run scripts like wordpress, joomla, drupal, etc.. Without the protection of mod_security, the servers are a perfect target for HACKERS, aand yes we could tell our clients to update, bla bla bla, but that's even more difficult. If mod_security could work correctly with that configuration, i could say it's the best, but it's not.

    2) SuPHP (apache mpm worker)
    This one is good, but only if your clients have very but very low visits. If an hacker try to attack with a scanner, or googlebot it's a site with poor php performance, your server load will grow to levels that you'll have an heart attack, even with cloudlinux, since the problem will be the php accessing mysql.
    This is good for shared hosting, but pray for your clients don't have many visits.

    3) FastCGi (apache mpm worker)
    Until now, this one was the best. With or without many visits, this resulted in less loads, security, everything working perfectly, the only problem is the tweak of mod_fcgi values, but cloudlinux gave us a very good knowledge on that.
    A server with 8gb, xeon dualcore, and 300 clients, can use this with very good results.

    Until mod_security is FIXED to work with prefork+DSO+Ruid2, FastCGi is the best solution, in performance and security.
     
  11. ecommy

    ecommy Registered

    Joined:
    Jun 9, 2011
    Messages:
    4
    Likes Received:
    0
    Trophy Points:
    1
    Thank you for the above answer, I confirm I have the same settings with great results.
    Further more in a shared hosting environment you'll end up with clients that have old websites and require a custom php version. This is not possible with DSO.
    Tristan is right however with the fast-cgi processes hanging in memory but if you are carefoul and tweak the settings properly monitoring the situation from time to time everything is nice.
     
  12. StingRay2k01

    StingRay2k01 Active Member

    Joined:
    Jun 15, 2003
    Messages:
    31
    Likes Received:
    1
    Trophy Points:
    6
    cPanel Access Level:
    Root Administrator

    I've used mod_fcgi with Worker MPM for years in a multi-user environment, several with busy forums. my Server is a VPS running on 768K or less.

    I elected to NOT use a cache, I found it used a lot of memory for little speed improvement. However if I HAD lots of memory I would use a cache. My situation required less memory usage however.

    I've not had a lot of problems. In fact the only time it requires any time on my part is when I rebuild apache using easyapache. Then I have to remove any PHP processes that were running at the time. I rarely restart apache though so it's not a problem for me. I know others have scripts to look for processes that should be killed as well but I haven't bothered.

    It DID take a long time to find all the tweaks to make it work well, but once I had that figured out it's been fine.
    I don't understand why cpanel is scared of it, you just have a few configurations to make like most server software. It's not complicated and some official documentation would go a long way.
    They know their customer however, so I'll not criticize, I'll just say that I think any server admin that knows how to search for answers and edit config files would be fine.


    This is what I put in the Pre Virtual Host Include section (All versions)
    I also have the formula notes in there too. Hopefully this helps someone as a starting point.
    It is setup to be very aggressive in keeping memory low.


    <IfModule mod_fcgid.c>
    FcgidMaxRequestLen 15728640
    </IfModule>

    # FORMULA
    # ServerLimit >= MaxClients / ThreadsPerChild
    # ThreadLimit >= ThreadsPerChild
    # Should appear before other directives
    # Min and Max should be multiples of ThreadsPerChild
    # Try single child with 15 Threads
    # Try ThreadStackSize 65536 -- no too small, segmentation errors ensue.

    <IfModule mpm_worker_module>
    ServerLimit 256
    ThreadLimit 16
    StartServers 4
    MaxClients 256
    MinSpareThreads 4
    MaxSpareThreads 4
    ThreadsPerChild 16
    MaxRequestsPerChild 700
    ThreadStackSize 163840
    TimeOut 30
    </IfModule>


    <IfModule mod_fcgid.c>
    MaxRequestsPerProcess 500
    MaxProcessCount 14
    DefaultMaxClassProcessCount 15
    DefaultMinClassProcessCount 0
    IPCConnectTimeout 60
    IPCCommTimeout 60
    PHP_Fix_Pathinfo_Enable 1
    IdleTimeout 180
    IdleScanInterval 20
    BusyTimeout 120
    BusyScanInterval 90
    ErrorScanInterval 3
    ZombieScanInterval 3
    ProcessLifeTime 600
    </IfModule>
     
  13. luigidelgado

    luigidelgado Well-Known Member

    Joined:
    Nov 6, 2010
    Messages:
    109
    Likes Received:
    2
    Trophy Points:
    16
    Location:
    Mexico
    cPanel Access Level:
    Root Administrator
    Twitter:
    I found this thread very interestying. In the opposite side (to xanubi) I have a small server (i5 4Gb) for my own clients. We have been trying to find out how to optimize it the best. Its a very different show in using DSO or FCGI or suPHP in a big server than in a small one!!

    a. By now using suPHP has been the most stable option. Even if its the slowest, its the safest and its stable.
    b. FCGI+APC+memCached= So problematic!! Configuring it is a complex task. We have the server so unstable (tripled disk access, tripled processes, tripled loads) that we came back to suPHP after a copuple of days. Also php.ini settings would make you have some time spent...
    c. Now as Tristan says DSO+mod_ruid2 sounds an interesting option BUT said by xanubi mod_security would make things crash so we are stuck here...

    1. What is the reason this is crashing?? is it DSO or mod_ruid2? or both? or is there a solution for this?
    2. Why am I having so many problems with FCGI?? is it to little memory?
    3. Isnt there a way to make suPHP faster?


    EDIT: For Number 3. I have found a pretty good combination here: suPHP+Varnish. I Want to know if anybody has any experience with this... I have read pretty good info about Varnish results.... I will give it a try.
     
    #13 luigidelgado, Jul 15, 2012
    Last edited: Jul 15, 2012
  14. voshka

    voshka Active Member

    Joined:
    Apr 4, 2010
    Messages:
    30
    Likes Received:
    0
    Trophy Points:
    6
    FCGi is by far my Favor
    it is correct that it uses too muchmemory but it make server more stable under dos attacks and also make the server load so lees

    it is about 2 years that I have switched to this handler and easy apache compiles it very well

    for making it use less memory there is way and that is to lower the amount of time the compiled php are cached in the memory
    by default I remember it was an hour
    make it lower to 20 minutes may solve your issue

    Thanks
     
  15. Duplika

    Duplika Well-Known Member

    Joined:
    Feb 26, 2005
    Messages:
    56
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Buenos Aires, Argentina
    cPanel Access Level:
    Root Administrator
    Twitter:
    That's an awesome feedback StingRay2k01.

    Are you using the proposed cron to kill old FastCGI PHP procceses with that setup? Wonder what line exactly allow us to avoid having to use it.
     
  16. StingRay2k01

    StingRay2k01 Active Member

    Joined:
    Jun 15, 2003
    Messages:
    31
    Likes Received:
    1
    Trophy Points:
    6
    cPanel Access Level:
    Root Administrator

    I'm not sure what can prevent processes from getting orphaned with an Apache restart. But a cron job would take care of it. Like I said, I restart so little that it isn't a really both to me to kill a couple processes manually.


    Here is a line I wrote down awhile ago to kill processes, but I haven't tested it yet.
    ps auxwwwf | grep '[0-9] /usr/bin/php' | awk '{ print $2 }' | xargs kill -9


    If you do have some orphaned processes, try this first to see if it will kill the right thing :)
    ps auxwwwf | grep '[0-9] /usr/bin/php' | awk '{ print $2 }'
     
  17. ehudal

    ehudal Member

    Joined:
    Apr 20, 2003
    Messages:
    13
    Likes Received:
    0
    Trophy Points:
    1
    Tristan,

    Do you have the final benchmarks to share?
    Has there been any progress made on the mod_security issues?

    Thanks
     
  18. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    somewhere over the rainbow
    cPanel Access Level:
    Root Administrator
    Hello,

    I don't yet have the final benchmarks. I have been working on other projects in the time being such as a Tomcat guide and now an Exim Spam Tracking Techniques one currently. Once I am able to re-focus on the testing for the various handlers, I'll get that posted. The goal is to have something on each of the PHP handlers and suggestions on when to use one versus another along with the various available options.

    For mod_security, if anyone believes it's a bug we should look into, it will need to be submitted as a bug at http://go.cpanel.net/bugs area. It cannot be submitted as a normal ticket but a bug report. The server in question must be running mod_ruid2 and must be showing the errors for mod_security in the error logs.

    Thanks!
     
  19. rogerw

    rogerw Member

    Joined:
    Feb 21, 2012
    Messages:
    8
    Likes Received:
    0
    Trophy Points:
    1
    cPanel Access Level:
    Website Owner
    But in WHM's EasyApache it says mod_ruid2 is experimental.

    Also if using this, then CGI scripts will fail (as CGI is not supported by it). Worse still, all caching would fail as it's not supported either. Quote from WHM info window below:

    One other question I have... Using cPanel 11.34.0.9 - I don't see the option to use DSO anywhere. Not in EasyApache, not in "Configure PHP and suEXEC" - Gone! How do we get DSO back, do I have to downgrade cPanel?

    Thanks
     
  20. Duplika

    Duplika Well-Known Member

    Joined:
    Feb 26, 2005
    Messages:
    56
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Buenos Aires, Argentina
    cPanel Access Level:
    Root Administrator
    Twitter:
    It's great to have this kind of feedback, I think cPanel should have the best possible settings for the default usage of it's product, hosting multiple sites at the same server.

    Yet you guys need to work with CloudLinux and decide how to proceed, since they don't only don't support mod_ruid2 but they also advice against it.

    In words of their CEO:
    I understand you are not responsible for their product, but considering you are partners, it would be great if you added Home - PHP-FPM and provide some working default configuration via EasyApache so that we can have both products working together without any special configuration (like adding a custom cronjob to kill old PHP procceses).
     
Loading...

Share This Page