【问题标题】:How to monitor slow PHP processes?如何监控缓慢的 PHP 进程?
【发布时间】:2012-01-23 12:56:01
【问题描述】:

我使用 Nginx 运行 PHP-FPM。我的服务器上有各种不同的脚本。有时,PHP 代码存在问题,并且该过程花费的时间太长。这会消耗所有可用的 PHP-FPM 子代;因此,阻碍了其他 php 脚本。

如何设置 PHP-FPM 日志来记录缓慢的 php 进程,因为我们监控缓慢的 mysql 查询,以检测哪个脚本导致了问题?

【问题讨论】:

标签: performance logging php


【解决方案1】:

这是我今天第二次推荐RPM

这是一个应用程序性能监控工具。最初,它是 Rails 的杀手级应用,但后来他们开始支持 PHP。

它可以监控你的脚本,跟踪慢的,显示各种图表。

它还可以处理慢速 SQL(您甚至可以从该工具中查看解释计划!)

你一定要看看。

【讨论】:

  • 相当不错,但我倾向于避免每月的许可费用。对于 0 美元和几行代码,我觉得定制解决方案在灵活性方面具有优势。通过几行自定义代码,您可以分析任何脚本、后端或前端、Linux 或 Windows、本地主机或生产服务器。我所做的大多数分析,我的脚本函数调用的 Flash 动画图表都是多余的。
  • 嗯,当然,这一切都取决于。如果您要托管您的主页,则可以推出自己的解决方案并在此过程中获得乐趣。但如果你想经营一家企业,你可能不想把时间和金钱花在已经很好实施的事情上。一切都与成本和利润有关。
  • 没错。成本和利润。我工作的大多数客户都是中型或小型公司,管理员通常会尽量减少每月的运营成本。 cactimunin 是我以前使用过的 2 个免费监控解决方案,效果很好,但随着时间的推移,我发现它是多余的。 3行代码,你可以分析任何东西。在任何地方免费使用和重复使用的速度、效率和灵活性。我不想暗示您发布的应用程序不好,只是有些人喜欢图表(+ 付费支持),有些人不喜欢。
  • 在这里我有点不同意你的观点。 3行代码足以将一段代码置于秒表之下。但是您必须将这些基准测试结果存储在某个地方,管理该数据库,使用图表构建您自己的管理页面等。“3 行代码”过于简单化了。
  • 我承认我的 3 行代码不存储数据,它们是更多的分析和基准测试工具。我确实过度简化了一点,因为它实际上是 7 行。 ;) 嘿,我确实为你发布的那个应用添加了书签!晚安,我的朋友
【解决方案2】:

我一直在使用this class 来分析和监控我自己的实用程序脚本。如果您对 Pear 课程没有任何反对意见,它可以正常工作。

您可以在代码中设置不同的计时器,并根据这些计时器返回的值进行操作。作为奖励,您可以获得每个计时器运行所需时间的文本或 html 分析输出。

See the docs for more info.

希望有帮助,祝你好运。

【讨论】:

    【解决方案3】:

    如何设置 PHP-FPM 日志

    没有。使用nginx log_format 以毫秒精度记录每个 HTTP 请求的持续时间。

    当我们监控缓慢的 mysql 查询时

    所以您已经根据频率和经过时间的乘积去除文字值并确定优先级?

    【讨论】:

    • 使用 Web 服务器的强大功能非常巧妙的想法。实际上,我认为我可能错过了 php-fpm log 的功能。我更喜欢使用原生网络服务器,而不是使用额外的监控系统。
    【解决方案4】:

    php-fpm 支持 php 脚本的慢速记录功能

    在你的 php-fpm.conf 中你需要添加 2 个变量

    request_slowlog_timeout 和慢日志

    根据 php-fpm wiki

    ;服务单个请求的超时时间,之后 PHP 回溯将是 ;转储到“慢日志”文件。值“0s”表示“关闭”。 ;可用单位:s(econds)(默认)、m(intutes)、h(ours) 或 d(ays) ;默认值:0

    request_slowlog_timeout = 30
    

    ;慢请求的日志文件 ;默认值:未设置 ;注意:如果设置了 request_slowlog_timeout,slowlog 是强制性的

    slowlog = log/$pool.log.slow
    

    为了监控 mysql 查询,我使用此查询来获取正在我的机器上运行的查询列表

    show full processlist;
    

    【讨论】:

    • MySQL 长期以来一直有记录慢查询的选项——以前的值“0”表示禁用日志文件——但开发人员意识到能够记录 所有查询以了解性能问题。如果您花一些时间处理性能问题,那么原因就很明显了。在 PHP-FPM 中,值为 0 会禁用该功能。鉴于此选项的行为,它应该被用作处理性能问题的最后尝试——而不是首先尝试。
    【解决方案5】:

    Appgati 在这里可能会有所帮助。

    这不是解决您的问题的彻底解决方案,但可以提供一些有用的见解,以了解引入滞后的位置。您可能会丢失数据,或者在生成 DOM 时浪费时间。该脚本提供了潜在关注区域的天空视图,然后可以专门针对这些区域。

    它还可以方便地查找脚本中特定函数的性能。

    示例输出:

    Array
    (
    [Clock time in seconds] => 1.9502429962158
    [Time taken in User Mode in seconds] => 0.632039
    [Time taken in System Mode in seconds] => 0.024001
    [Total time taken in Kernel in seconds] => 0.65604
    [Memory limit in MB] => 128
    [Memory usage in MB] => 18.237907409668
    [Peak memory usage in MB] => 19.579357147217
    [Average server load in last minute] => 0.47
    [Maximum resident shared size in KB] => 44900
    [Integral shared memory size] => 0
    [Integral unshared data size] => 0
    [Integral unshared stack size] => 
    [Number of page reclaims] => 12102
    [Number of page faults] => 6
    [Number of block input operations] => 192
    [Number of block output operations] => 
    [Number of messages sent] => 0
    [Number of messages received] => 0
    [Number of signals received] => 0
    [Number of voluntary context switches] => 606
    [Number of involuntary context switches] => 99
    

    )

    【讨论】:

    • 有趣的事情!很高兴知道。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-03-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多