导入 60,000 个节点答案

【问题标题】：Importing 60,000 nodes导入 60,000 个节点
【发布时间】：2010-08-03 07:39:03
【问题描述】：

我正在使用 Table Wizard + Migrate 模块将节点导入到我的 Drupal 安装中。

我需要导入大约 60,000 个问题/答案（它们都是节点），我认为这将是一件容易的事。

但是，迁移过程每分钟导入 4 个节点，完成导入大约需要 11 天。

我想知道是否可以通过直接在 mysql 中导入来使其更快。但我实际上需要创建 60,000 个节点。我猜 Drupal 会在其他表中存储额外的信息......而且它不是那么安全。

你建议我做什么？等10天？谢谢

【问题讨论】：

能否贴出你目前使用的脚本，以及如何执行？
好吧，我正在使用 Migrate 模块 (drupal.org/project/migrate)。与表向导模块一起，我创建了包含外部表内容的视图，然后将其导入 Drupal 节点（每个节点只有 2 个 CCK 字段，只有文本）。您实际上是对的，它非常慢......每分钟 4 个节点。之前是每分钟 10 个节点。您在几秒钟内完成 300 个节点的速度对我来说太棒了。
您的 IMPORT 的来源是什么。是否是您计算机上的 csv 文件。
不，是mysql表已经导入drupal数据库。表向导模块创建该表的视图并准备要导入的行。我可以为你提供更多细节。我需要加强这种该死的进口。
您是否在其他服务器或计算机上尝试过此操作？因为上次我用这个工具，导入速度挺快的。

标签： drupal import drupal-6

【解决方案1】：

表迁移应该比这快几个数量级。

你在使用 pathauto 吗？

如果是，请尝试禁用 pathauto 模块，这通常会导致导入时出现很大的性能问题。

其次，如果禁用 pathauto 不起作用，请关闭您可能正在运行的所有非必要模块 - 有些模块会做一些疯狂的事情。消除其他模块作为问题的根源。

三、MySQL db log 是否开启？这可能会对性能产生很大影响 - 不是您所说的级别，而是需要考虑的问题。

第三，安装 xdebug，跟踪你的 mysql 日志，看看到底发生了什么。

你的 PHP 内存限制是多少？

你还有足够的磁盘空间吗？

【讨论】：

你摇滚。问题确实是pathauto。现在它运行得很快：1967 个节点/分钟。导入后我将启用路径自动。非常感谢！
对用户导入的影响是一样的吗？

【解决方案2】：

如果你不做，你应该使用 drush 批量迁移节点。如果您希望它自动化，您甚至可以为它编写一个 shell 脚本。使用命令行应该可以大大减少导入节点所需的时间。使用脚本，您可以将其变成一项无需担心的自动化任务。

我要注意的一点是，每分钟 4 个节点非常低。我曾经需要从 CSV 文件导入一些节点，使用 migrate 等。我需要导入 300 个节点，包含位置，4-5 个 CCK 字段，我在几秒钟内就完成了。因此，如果您每分钟只导入 4 个节点，您要么拥有极其复杂的节点，要么发生了一些可疑的事情。

您为此使用的计算机的规格是什么？导入源在哪里？

【讨论】：

1) 我正在使用 Migrate 模块 php 脚本，如果我可以从 Drush 运行它的脚本（我不知道如何），我可以从终端使用 Drush 来完成。 2) 我使用的是 Macbook 双核（32 位），2GB 内存。 3) 导入源是同一个 Drupal 数据库中的 2 个表。

【解决方案3】：

这是一个棘手的话题，但在 Drupal 中实际上已经很好地涵盖了。我不知道来龙去脉。但要知道去哪里找。

Data Mining Drupalgroup 有一些关于在 PHP/Drupal 中处理大量数据的指针、知识和信息。
Drupal 核心具有批处理功能built in 和调用BatchAPI 在编写模块时为您服务！有关工作示例，请参阅 this tutorial on CSV import。

【讨论】：

【解决方案4】：

每分钟 4 个节点非常慢。迁移通常不会花费那么长时间。您可以通过使用 Drush 加快速度，但可能不足以获得合理的导入时间（几小时，而不是几天）。这并不能真正解决您的核心问题：您的导入本身花费的时间太长。 Migrate GUI 的开销并不大。

直接导入 MySQL 肯定会更快，但 Migrate 存在是有原因的。 Drupal 中的节点数据库存储很复杂，因此通常最好让 Drupal 自己解决，而不是试图弄清楚什么去哪里。

您是否使用 Migrate 的挂钩在每个节点上进行额外处理？我建议添加一些日志记录以查看究竟需要这么长时间。一次在 10 个节点上测试它，直到你在完成整个 60k 之前找出延迟。

【讨论】：

是的，它很慢：在 28.7 秒（4/分钟）内导入了 2 个 - 继续“导入答案”。我没有做额外的处理。只需将表的行导入特定内容类型的节点（并分配 3 个 CCK 字段）。如何添加一些日志记录？

【解决方案5】：

我们在安装 Drupal 7 时遇到了类似的问题。让它在整个周末都在导入时运行，它只导入了 1,000 行文件。

有趣的是，完全在预生产机器上进行相同的导入需要 90 分钟。

我们最终比较了源代码（确保我们在 git 中提交相同）、数据库架构（相同）、每台机器上的节点数量（不相同但相似）...

长话短说，两台机器之间唯一的显着区别是php.ini 设置文件中的max_execution_time 选项。

生产机器有max_execution_time = 30，而预生产机器有max_execution_time = 3000。看起来 migrate 模块有一种系统来处理“短”max_execution_time 不是最佳的。

结论：在php.ini 中设置max_execution_time = 3000 或更多，这对迁移模块有很大帮助。

【讨论】：

【解决方案6】：

我只是想添加一个说明，说明 pathauto disable 确实有帮助。我有超过 22k 行的导入，在禁用它之前需要 12 多个小时，并且在导入过程中会崩溃多次。禁用pathauto再运行导入后，只用了62分钟，没有崩溃过一次。

提醒一下，我创建了一个模块，在导入开始之前禁用 pathauto 模块，然后在提要完成后重新启用 pathauto 模块。以下是模块中的代码，以防有人需要此功能：

function YOURMODULENAME_feeds_before_import(FeedsSource $source) {
  $modules = array('pathauto');
  drupal_set_message(t('The ').$modules[0].t(' has been deployed and should begin to disable'), 'warning');
  module_disable($modules);
  drupal_set_message(t('The ').$modules[0].t(' module should have been disabled'), 'warning');
}

function YOURMODULENAME_feeds_after_import(FeedsSource $source) {
  $modules = array('pathauto');
  module_enable($modules);
  drupal_set_message($modules[0].t(' should be reenabled now'), 'warning');
}

【讨论】：