Django“迁移”消耗过多的CPU答案

【问题标题】：Django "migrate" consuming too much CPUDjango“迁移”消耗过多的CPU
【发布时间】：2016-07-18 02:54:18
【问题描述】：

我们的暂存服务器，AWS 上的一个 t2.micro 实例不断停机。在调查中，我们发现当manage.py migrate 运行时，CPU 使用率高达 99%。它很容易在本地机器上重现。我们正在运行 Django 1.9 和 postgresql 数据库。我现在不确定，是我们做错了什么还是注定要那样。我们在项目中有大约 18 个应用程序，但运行 migrate app_name 也会导致相同的行为。附上CPU使用率截图。

另外，我分析了迁移功能，这是一个图表：

【问题讨论】：

只是出于好奇，您是如何生成该图的？
@JasonEstibeiro：我使用了这个库：github.com/jrfonseca/gprof2dot
我真的很想知道您为什么要定期运行migrate（这对我来说是这样的），而不是仅在部署之后并且仅在必要时才运行。跨度>
@Risadinha：我们有fabfile 用于在服务器上部署代码的脚本。它的作用是从相应的分支中提取最新的代码——>运行迁移——>重新启动服务器（nginx，django服务器）。每当我们部署代码时，服务器使用率就会飙升，服务器会挂起。

标签： django django-migrations

【解决方案1】：

您是否依赖migrate 定期运行？因为一旦项目接近并进入生产状态，就不应该有很多迁移要运行。或者你的意思是migrate 需要这么长时间，即使migrate --list 表明没有什么可以迁移？

此外，要了解 Postgres 在做什么，您应该设置查询记录，包括查询时间。您可以过滤以仅记录运行时间较长的查询： http://www.postgresql.org/docs/9.5/static/runtime-config-logging.html

通过explain analyze sql 命令运行这些查询：

psql> EXPLAIN ANALYZE <complete query>;

http://www.postgresql.org/docs/9.5/static/using-explain.html

您需要提供从explain 获得的信息以获得进一步的帮助。

编辑：

另外，如果您有很多迁移文件，您可以尝试squash migrations。我可以想象 Django 一个一个地通过所有这些来工作。因此，如果您有许多应用程序和许多文件相互依赖，您可以想象会发生什么。 https://docs.djangoproject.com/en/1.9/topics/migrations/#squashing-migrations

编辑 2：

将此从评论移到答案中：

migrate --list 也消耗那么多 CPU 吗？如果没有，那么您可以先运行它，看看是否真的需要迁移，然后只在那些已打开迁移的应用上运行 migrate。

我认为这是最好的。如果您可以更详细地分析，您实际上可能会向 Django 社区寻求帮助。我可以想象你有一个有趣的设置来了解如何调整 Django 迁移以减少（实际上是不必要的）工作。但我不太了解迁移代码，所以我无法分辨。但这也取决于我们谈论的应用程序数量以及迁移文件的数量。如果您的应用程序少于 30 个（包括第 3 方），我认为它应该可以正常工作并且还有其他问题（恕我直言！）。

此外，您还没有显示服务器的资源使用情况。如果缓慢是由于交换/过多的 RAM 使用造成的，您确实可以通过提供更多 RAM（给进程）来提高它。

【讨论】：

是的，我一定会试试这个。第二点，python 的 CPU 使用率很高，而不是 postgresql。这是否表明该问题纯粹与 Django(Python) 而不是数据库有关。
是的，当然也更有意义。更重要的是，无论最终有多少事情要做，都需要这么长时间。 migrate --list 也消耗那么多 CPU 吗？如果没有，那么您可以先运行它，看看是否真的需要迁移并仅在那些具有开放迁移的应用上运行migrate。
我们尝试压缩迁移但没有成功。我想我们需要一个更大的盒子，因为我们面临与compress 命令相同的问题，否则我们需要做类似@Mounir 建议的事情。

【解决方案2】：

我相信迁移会消耗很多，特别是当有许多模型和许多应用程序时，更多的应用程序更多的依赖项更多的迁移复杂性。

我建议启动一个仅在此之后运行迁移和关闭的新实例。这样你的网络服务器就可以访问了。

【讨论】：

是的，我完全同意@mounir，启动另一个单独运行迁移的实例或让 postgress 服务器在它自己的实例上运行会有所帮助。

【解决方案3】：

这并没有完全解决问题陈述，而是其中的一部分。我浏览了documentation of AWS t2.micro，发现 T2.Micro 实例旨在处理合理的长间隔后发生的短间隔（~1 分钟）的CPU Burst。来自 t2.micro 文档：

CPU 积分可在一分钟内提供完整 CPU 内核的性能。传统的 Amazon EC2 实例类型提供固定的性能，而 T2 实例提供基准水平的 CPU 性能，能够突增到该基准水平之上。基准性能和突增能力由 CPU 积分控制。

鉴于此 ^，即使它消耗 100% 的 CPU，运行迁移也不应该成为问题。我们调查了更多，发现有crons在服务器上运行，这是不应该的。

【讨论】：