三周前我已经从Drupal 7.14切换到7.15，因此，我遇到了一系列非常复杂的内存限制错误（对我而言）。每当我尝试清除性能缓存或运行更新脚本时，都会发生这些错误。

我的托管公司已将php.ini中的内存限制增加到126 M，256 M，512 M甚至1024M。但是仍然会发生错误。我已经将网站从共享迁移到了VPS，但是仍然会出现错误。我没有办法，也不知道如何前进。

错误如下：

• 致命错误：416行/home/example/public_html/sites/all/modules/views/views.module中的536870912字节已用尽的内存大小（尝试分配30字节）

• 致命错误：在第2736行的/home/example/public_html/includes/menu.inc中，耗尽了536870912字节的允许内存大小（尝试分配108字节）

• 致命错误：第59行的/home/example/public_html/sites/all/modules/chain_menu_access/chain_menu_access.module中的536870912字节已用尽的内存大小（试图分配71字节）

• 在第93行的/home/example/public_html/sites/all/modules/views/includes/base.inc中分配64个字节）

上一次我遇到Drupal内存问题时也一直在墙上碰头。这是我收集的有关该主题的知识：

1.视图（可以）使用大量内存

我爱我一些Views（以及Panels和CTools，以及merlinofchaos用他强大的手指触摸到的所​​有东西），但是可以创建具有大量内存的多个关系的配置。如果禁用视图，并且内存问题消失了，则可能是结构不良的视图导致了该问题。

如果它是一个视图，并且您确实需要该视图才能工作，该怎么办？尝试将其放入代码中（通过批量导出器或功能；请参见下文。我已经手动编码类似Views的功能，以提高性能但收效甚微）。另一个想法是以另一种方式重做视图-如果最终要获得的是分类术语，则在创建视图时请确保该视图的类型为分类视图；请勿创建使用关系获取分类术语的内容视图。

在这里还值得一提的是，Panels还应该使用很多内存-我尚未对其进行基准测试，因此无法确认。

2.将资料从数据库转移到代码中是一种很好的做法

我花了几个Drupal站点来实现这一点，但是将通过UI创建的所有内容（特别是视图和面板配置）保留在数据库中是Drupal的最差做法。为什么？它增加了数据库的负载，并且无法进行版本控制。第一点在内存使用方面尤其成问题-站点不仅必须从数据库中的View加载内容，而且还必须加载View组件本身。Drupal如何使用表会加剧这种情况：通过将所有内容抽象到第n级，Drupal功能的每一位都会使用一个新表，从而导致一些请求将一个兆兆表连接在一起。这给计算机科学界的人们带来了烦恼（注意：链接很愚蠢），但是像Drupal那样模块化和用户友好的软件是无法避免的。

解决方案？使用批量导出程序（CTools附带）或功能部件可以将数据库中当前驻留的部分代码打包为模块代码。

3.主题也可以吃掉记忆

您的主题是否有很多模板文件（即，主题名称/ templates /中的文件）？如果是这样，则每次加载其中一个文件时都会消耗内存。如果要专门创建模板来抑制显示Drupal的位，请尝试以下任一方法：

1. 更改权限，以使特定的非管理员用户角色不会显示该权限。
2. 使用CSS隐藏元素。

显然，第一个选择是您要为影响安全性的事情做些什么-您不想使用CSS为某些用户隐藏“编辑”按钮，只是让他们随后通过Firebug或其他方法取消隐藏。

4.不要在contrib模块上落伍

虽然有时一个站点需要很多contrib模块，但不要太过分。每个启用的（注：已启用。禁用的模块不使用任何内存）模块都使用内存。这是显而易见的，但值得注意的是。

5. VPS（有时）是一个谎言

以我的经验，一些不道德的托管公司喜欢尝试将Drupal网站推送到VPS服务器-它们更昂贵，并且可以为更多的WordPress网站释放共享托管空间。由于Web主机通常不通告（或什至乐意告诉您）共享主机的最大内存限制，这一事实使情况更加恶化。

las，通常情况下，如果一个站点的通信量不大并且仍然崩溃，那么问题可能与Drupal的配置有关。将用户推向VPS只会使人感到困惑，并增加了要处理的变量（是Web服务器配置？PHP配置？VPS来宾配置？甚至是VPS主机配置）。

6.当所有其他方法均失败时，克隆到localhost并用木棍击败它

这是人们使用带有版本控制功能的dev-staging-production方法的重要原因-当所有其他方法都失败时，您可以执行数据库转储，将站点克隆到本地测试服务器，然后在站点上将站点弄乱。测试服务器而不必担心实际破坏生产服务器上的任何东西。

对于内存问题，这通常意味着逐个禁用模块，直到暴露导致问题的模块为止。它还可能指向与虚拟主机相关的问题-如果该站点在本地安装上运行得很好，并且内存设置为合理的128MB，那么您知道您的虚拟主机已经崩溃。

tl; dr

我的直觉是导致问题的原因是chain_menu_access。尝试禁用它并清除缓存，看看它是否有效。

当我想到要尝试的其他方法时，我还将添加此答案。

您可以尝试将PHP探查器（例如XHProf或Xdebug的内置探查器）放入请求中，以检查正在发生的情况。

视图是一个记忆猪。Drupal的缓存可以提供帮助。Drupal仅在模块创建表或具有其他可悬空对象的情况下才激活模块。仅卸载将删除大多数工件。我们使用drupal的授权/权限，并在其中编写自己的模块。不是最好的，但性能要好得多，更容易调整。我们也对WP做同样的事情。

我的情况是内存限制问题是由缓存系统（Boost和Boost Expire模块）生成的。这给了我更新模块或视图的问题。禁用Boost模块后，所有模块都可以正常工作。