`drush cc all`命令花费的时间太长，我该怎么办？

12

在我的站点上drush cc all，运行需要4分钟以上。站点数据库只有几个GB。但是，我看不出为什么花太长时间的明确原因。我该怎么办才能找到瓶颈？

7 drush caching

— awm
source

检查第一个mysql查询日志：drupal.stackexchange.com/questions/75629/…– AgA 2014

— 17

您是否正在运行cron？

— mpdonadio

是的，我确实正在执行cron。该网站通常运行缓慢。太多的旧代码不值得重构。

— 2014年

我在这里同意@MPD，我认为这与内存无关。MySQL也是可能的原因之一。只有一种找出方法，那就是剖析它。最简单的方法是使用xhprof扩展名和devel，它也适用于drush（使用-d查看报告的链接）。我的猜测是有很多问题，如果站点对所有请求的响应速度都很慢，则通常会出现一个问题，即缺少模块，请参阅drupal.stackexchange.com/questions/724/why-is-drupal-7-so-slow。Views在缓存方面也存在一些主要的性能问题，请参阅drupal.org/node/1944674。

— 贝尔迪尔

谢谢，我认为我必须进行性能分析，但是在drupal代码库的情况下，始终很难查明瓶颈。尽管我说站点很慢，但是它并不太慢，而且所有CC都非常慢。

— 2014年

6

清除缓存本身不需要很长时间，因为它只是截断缓存表。最耗时的是在此之后重建缓存注册表。通常，它是主题注册表，它会扫描所有新的钩子以及所有Drupal文件夹中的新模板文件，系统会扫描文件中的新模块和类文件，等等。

您始终可以通过指定drush cc theme-registry或任何其他清除特定的缓存。

强烈建议您使用PHP缓存机制（例如OPCache，XCache等）来加快处理速度。并且基于内存的缓存可替代SQL表上的大量使用（例如，memcached或redis），因此清除缓存将不需要任何时间，只需刷新缓存（例如，echo flush_all > /dev/tcp/127.0.0.1/11211在Bash中）。

另外，您始终可以手动清除缓存，例如：

echo "SHOW TABLES LIKE 'cache%'" | $(drush sql-connect) | tail -n +2 | xargs -L1 -I% echo "DELETE FROM %;" | $(drush sql-connect) -v

调试

要检查最耗时的时间，您需要对其进行调试 / profile（例如XDebug，XHProf，phpdbg，dtrace）。

在OS X / Unix上，这可以通过dtrace（在运行之后drush）实现：

sudo dtrace -qn 'php*:::function-entry { printf("%Y: PHP function-entry:\t%s%s%s() in %s:%d\n", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2); }'

在Linux上，使用strace，例如

strace -e trace=sendto,recvfrom -s1000 -p $(pgrep php)

要查找某些特定内容，请尝试添加例如：strace ... 2>&1 | grep -C5 UPDATE。

— Kenorb
source

5

如果您有一个非常大的数据库，并且在未进行缓存清除时系统运行良好，则可能是您没有足够的内存来完全支持您的设置。

如果您的站点在Linux机器上运行，请运行“ top”（从您的shell），然后按shift-M键以按使用的内存对进程列表进行排序。然后，从另一个终端运行缓存清除操作。您应该看到mysql和apache上升到列表的顶部。您将能够看到这些进程中每个进程使用的总内存的百分比，以及使用了多少可用RAM。如果您有大量的虚拟空间，但是所有物理RAM都已用完，则此操作可能会导致VM内存崩溃，从而使您的执行时间减少到通常的一小部分。

有一次，我在一个没有足够内存的盒子上运行一个流量中等的Drupal网站，以支持设置。当我在一个不相关的低流量站点上运行缓存清除时，缓存的重建使系统超出了其限制，并且几乎所有内容都被锁定。因此，整个系统的行为在这里很重要。这就是为什么像“ top”这样的简单工具是一个方便的起点的原因。

— greg_1_anderson
source

谢谢，我认为根本原因是该网站存在了一段时间，数据库很大，代码非常需要重构。例如，node_delete操作大约需要3秒钟。我认为提供过多的内存可能是多余的，您同意吗？

— 2014年

我在机器上安装了它，而且速度也很慢。我将内存增加了一倍，最大达到1GB，并为它设置了“ time drush cc all”。没有什么好多了，只能更快地获得4s。

— 2014年

1

是的，如果即使有很多内存，整个站点一直都很慢，那么cc并不是问题；您将必须执行更多常规分析。

— greg_1_anderson 2014年

另外，如果该站点确实很旧并且需要刷新，请考虑使用全新的模块从头开始重建，然后使用drupal到drupal的迁移（drupal.org/project/migrate_d2d）来移动内容。

— greg_1_anderson 2014年

2

我将在某种程度上不同意@ greg_1_anderson。

如果在期间系统没有完全崩溃cc all，那么我认为您没有一般的内存问题。当LAMP服务器的内存不足时，它将命中swap。处于活动状态的服务器碰到交换将导致大量不良情况。由于系统变慢（交换使系统运行非常缓慢），httpd进程将开始堆积，这将导致使用更多交换空间，依此类推。在发生这种情况的网站上，我会看到进程负载达到100，和大量活动的httpd进程。

如果您的系统最终恢复正常，那么我认为您的调整不佳。 drush cc all将会导致大量的数据库访问，所以我认为这正显示出更多的问题。我的建议是在站点上运行mysqltuner。如果您有一个多GB数据库，我的猜测是您的innodb_buffer_pool_size远程大小甚至都不正确，并且您的MySQL实例正在崩溃。我还将研究备用的缓存后端，以尝试减小数据库的占用空间。

— mpdonadio
source

谢谢，drupal仅用于具有servie层且带有漆层的editoria用途。用户现在可以使用drupal。我只想调查发生的事情，因为我认为存在瓶颈。我认为最好的选择是打开mysql慢日志并监视数据库。然后做一些剖析与Xdebug的

— AWM

SHOW FULL PROCESSLIST会告诉您正在发生的事情，而无需使用慢速查询日志（因此无需重新启动服务器）。参见mytop的其他答案。

— 克里斯·伯吉斯

1

它可能是您的虚拟主机环境。您是指本地设置，还是共享主机或VPS /服务器上的主机？

托管环境 -如果您使用共享的Web托管，则Drupal / drush可以使用的内存量将受到限制，请参见：https ://drupal.org/node/207036
最大执行时间 -需要增加

— geekgirlweb
source

冲动通常不受限制max_execution_time。不过，您可以drush php-eval "print ini_get('max_execution_time');"仔细检查。

— mpdonadio

1

这不是一个完整的解决方案，仅是另一个工具，可帮助您确定延迟的根源。

除了top用于监视流程之外，您还可以找到mytop信息量很大的输出。（上面的其他答案都假定MySQL，但如果您使用的是另一个数据库后端，则需要将mytop换成等效的工具。）

mytop只需SHOW FULL PROCESSLIST在一个循环中执行MySQL ，并向您显示正在执行哪些查询（因此需要很多时间）。如果清除缓存需要很长时间来清理该表，那么您将在这里看到是什么原因。如果您无权安装mytop，只需在您的shell中执行一个原始版本-

while true; do mysql -e 'SHOW FULL PROCESSLIST' && sleep 5 && clear ; done

如果延迟不是源于MySQL查询，则此工具至少可以为您确认一次。

— 克里斯·伯吉斯
source

1

我发现在Drupal 7上的一篇题为“ 加快缓存清除速度”的博客文章对于准确缩小缓存清除过程的哪一部分正在减慢速度非常有帮助。它在功能模块和实体api模块中指出的问题正在影响我的站点，但是帖子中详细介绍的过程也帮助我追踪了在Drupal核心和断点模块中遇到的问题。

完成该过程需要花费一些时间，但它帮助我将缓存清除时间从数分钟减少到了不到一分钟。

— 马特五世
source