我们的临时服务器，AWS 上的 t2.micro 实例不断出现故障。在调查中，我们发现当 manage.py migrate 运行时，CPU 使用率高达 99%。它很容易在本地机器上重现。我们正在运行 Django 1.9 和 postgresql 数据库。我现在不确定，是我们做错了什么，还是本该如此。我们在项目中有大约 18 个应用程序，但运行 migrate app_name 也会导致相同的行为。附上CPU使用情况截图。
另外，我分析了迁移功能，这是一个图表:
最佳答案
您是否依赖 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(给进程)来提高它。
关于Django "migrate"消耗过多 CPU，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/36303147/