网站出现500，查看SLOWLOG日志发现如下提示： WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 8 idle, and 58 total children WARNING: [pool www] server reached pm.max_children setting (50), consider raising it 昨天晚上刚改的看来又不够用了！ 查看PHP-FPM内存占用的几个有用小命令，记录如下： 1.查看每个FPM的内存占用： ps -ylC php-fpm --sort:rss 当然，在后后面加 | wc -l可查看系统当前FPM总进程数，我的目前在45个左右。 PHP官方的建议设置值： pm.max_children = Total RAM dedicated to the web server / Max child process size 2.查看FPM在你的机子上的平均内存占用： [python] view plain copy ps --no-headers -o "rss,cmd" -C php-fpm | awk '{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,"M") }' from:http://blog.csdn.net/solmyr_biti/article/details/50525021
View Details转自：http://blog.csdn.net/zouyongjin/article/details/6642157 nginxphp-fpm配置过程中最大问题是内泄漏出问题：服务器的负载不大，但是内存占用迅速增加，很快吃掉内存接着开始吃交换分区，系统很快挂掉！ google了一天，终于发现些有用的东西，其实根据官方的介绍，php-cgi不存在内存泄漏，每个请求完成后php-cgi会回收内存，但是不会释放给操作系统，这样就会导致大量内存被php-cgi占用。 官方的解决办法是降低PHP_FCGI_MAX_REQUESTS的值，我用的是php-fpm，对应的php-fpm.conf中的就是max_requests，该值的意思是发送多少个请求后会重启该线程，我们需要适当降低这个值，用以让php-fpm自动的释放内存，不是大部分网上说的51200等等，实际上还有另一个跟它有关联的值max_children，这个是每次php-fpm会建立多少个进程，这样实际上的内存消耗是max_children*max_requests*每个请求使用内存，根据这个我们可以预估一下内存的使用情况，就不用再写脚本去kill了。 下面其实是重启脚本的过程，并不是什么很严重的事情，但是我们要小心，不是说一直重启就是好的，因为重启会导致cpu的使用率飙升，系统负载巨大，所以还是平衡上面的数据比较重要。 其他解决办法： 1.检查php进程的内存占用，杀掉内存使用超额的进程 一般情况下，如果php-cgi进程占用超过1%的内存，就得考虑一下是否要杀掉它了。因为普通情况下，php-cgi进程一般占用0.2%或以下。 这里提供一个脚本供各位使用，就是放在cron任务里，每分钟执行一次。 使用crontab -e 命令，然后添加如下调度任务 * * * * * /bin/bash /usr/local/script/kill_php_cgi.sh kill_php_cgi.sh脚本如下 #!/bin/sh # This script is used to kill php-cgi process that takes large memory size # If a php-cgi process uses 1% or more memory, then it will be killed. PIDS=ps aux|grep php-cgi|grep -v grep|awk '{if($4>=1)print $2}' for PID in $PIDS do #echo date +%F….%T >> /usr/local/php/logs/phpkill.log #echo $PID >> /usr/local/php/logs/phpkill.log kill -9 $PID done 顺便检查PHP-FPM参数 一般来说，如果设置不当，可能导致fpm出现[WARNING] fpm_children_bury(), line 215: child 20883 (pool default) exited on signal 11 SIGSEGV 之类的错误。 […]
View Detailsphp-fpm优化方法 php-fpm存在两种方式，一种是直接开启指定数量的php-fpm进程，不再增加或者减少； 另一种则是开始时开启一定数量的php-fpm进程，当请求量变大时，动态的增加php-fpm进程数到上限，当空闲时自动释放空闲的进程数到一个下限。 这两种不同的执行方式，可以根据服务器的实际需求来进行调整。 要用到的一些参数，分别是pm、pm.max_children、pm.start_servers、pm.min_spare_servers和pm.max_spare_servers。 pm表示使用那种方式，有两个值可以选择，就是static（静态）或者dynamic（动态）。 下面4个参数的意思分别为： pm.max_children：静态方式下开启的php-fpm进程数量，在动态方式下他限定php-fpm的最大进程数（这里要注意pm.max_spare_servers的值只能小于等于pm.max_children） pm.start_servers：动态方式下的起始php-fpm进程数量。 pm.min_spare_servers：动态方式空闲状态下的最小php-fpm进程数量。 pm.max_spare_servers：动态方式空闲状态下的最大php-fpm进程数量。 如果dm设置为static，那么其实只有pm.max_children这个参数生效。系统会开启设置的数量个php-fpm进程。 如果dm设置为dynamic，4个参数都生效。系统会在php-fpm运行开始时启动pm.start_servers个php-fpm进程，然后根据系统的需求动态在pm.min_spare_servers和pm.max_spare_servers之间调整php-fpm进程数。 那么，对于服务器，选择哪种执行方式比较好呢？事实上，跟Apache一样，运行的PHP程序在执行完成后，或多或少会有内存泄露的问题。这也是为什么开始时一个php-fpm进程只占用3M左右内存，运行一段时间后就会上升到20-30M的原因了。（www. 脚本学堂） 所以，动态方式因为会结束掉多余的进程，可以回收释放一些内存，所以推荐在内存较少的服务器或者VPS上使用。具体最大数量根据 内存/20M 得到。 比如说512M的VPS，建议pm.max_spare_servers设置为20（512*0.8/20）。至于pm.min_spare_servers，则建议根据服务器的负载情况来设置，比较合适的值在5~10之间。 然后对于比较大内存的服务器来说，设置为静态的话会提高效率。 因为频繁开关php-fpm进程也会有时滞，所以内存够大的情况下开静态效果会更好。数量也可以根据 内存/30M 得到。 比如说2GB内存的服务器，可以设置为50；4GB内存可以设置为100等。 比如，如果是512M的vps，设置的参数如下： 代码示例: pm=dynamic pm.max_children=20 pm.start_servers=5 pm.min_spare_servers=5 pm.max_spare_servers=20 可以最大的节省内存并提高执行效率。 from:https://www.cnblogs.com/feng18/p/6224638.html
View DetailsJetty 是一个开源的servlet容器，它为基于Java的web容器，例如JSP和servlet提供运行环境。Jetty是使用Java语言编写的，它的API以一组JAR包的形式发布。开发人员可以将Jetty容器实例化成一个对象，可以迅速为一些独立运行（stand-alone）的Java应用提供网络和web连接。 特性 易用性 易用性是 Jetty 设计的基本原则，易用性主要体现在以下几个方面： 通过 XML 或者 API 来对Jetty进行配置；默认配置可以满足大部分的需求；将 Jetty 嵌入到应用程序当中只需要非常少的代码； 可扩展性 在使用了 Ajax 的 Web 2.0 的应用程序中，每个连接需要保持更长的时间，这样线程和内存的消耗量会急剧的增加。这就使得我们担心整个程序会因为单个组件陷入瓶颈而影响整个程序的性能。但是有了 Jetty： 即使在有大量服务请求的情况下，系统的性能也能保持在一个可以接受的状态。利用 Continuation 机制来处理大量的用户请求以及时间比较长的连接。 另外 Jetty 设计了非常良好的接口，因此在 Jetty 的某种实现无法满足用户的需要时，用户可以非常方便地对 Jetty 的某些实现进行修改，使得 Jetty 适用于特殊的应用程序的需求。 易嵌入性 Jetty 设计之初就是作为一个优秀的组件来设计的，这也就意味着 Jetty 可以非常容易的嵌入到应用程序当中而不需要程序为了使用 Jetty 做修改。从某种程度上，你也可以把 Jetty 理解为一个嵌入式的Web服务器。 Jetty 可以作为嵌入式服务器使用，Jetty的运行速度较快，而且是轻量级的，可以在Java中可以从test case中控制其运行。从而可以使自动化测试不再依赖外部环境，顺利实现自动化测试。 和Tomcat的比较 原文地址:Jetty和Tomcat的选择：按场景而定[1] 1）Jetty更轻量级。这是相对Tomcat而言的。 由于Tomcat除了遵循Java Servlet规范之外，自身还扩展了大量JEE特性以满足企业级应用的需求，所以Tomcat是较重量级的，而且配置较Jetty亦复杂许多。但对于大量普通互联网应用而言，并不需要用到Tomcat其他高级特性，所以在这种情况下，使用Tomcat是很浪费资源的。这种劣势放在分布式环境下，更是明显。换成Jetty，每个应用服务器省下那几兆内存，对于大的分布式环境则是节省大量资源。而且，Jetty的轻量级也使其在处理高并发细粒度请求的场景下显得更快速高效。 2）Jetty更灵活，体现在其可插拔性和可扩展性，更易于开发者对Jetty本身进行二次开发，定制一个适合自身需求的Web Server。 相比之下，重量级的Tomcat原本便支持过多特性，要对其瘦身的成本远大于丰富Jetty的成本。用自己的理解，即增肥容易减肥难。 3）然而，当支持大规模企业级应用时，Jetty也许便需要扩展，在这场景下Tomcat便是更优的。 总结：Jetty更满足公有云的分布式环境的需求，而Tomcat更符合企业级环境。 from:https://baike.baidu.com/item/jetty/370234?fr=aladdin
View Details