为独特的应用程序管理Heroku RAM

Question

我有一个Flask应用程序，允许用户使用SQL查询~个小数据库（2.4M行）。它类似于黑客银行，但范围更为有限。它部署在Heroku上

在测试过程中，我注意到，通过运行大型查询，我可以预料到R14错误（超出内存配额）或R15错误（大大超出内存配额）。通常导致这种情况的查询超出了普通用户可能会执行的操作，例如从某个大型表中选择*。也就是说，我担心当5、10100个用户同时进行查询时，即使是很小的查询，这些错误也会经常发生

我正在寻找一些关于如何管理这种交互式站点的内存配额的建议。以下是我到目前为止探索的内容：

• 改变gunicorn工人的工作环境。这已经产生了一些效果，但我仍然一致地命中R14和R15错误
• 基于文本或解释输出强制限制用户查询。这确实可以减少内存使用，但我担心它甚至不能扩展到一小部分用户
• 向更高层次移动。我目前使用的计划提供约512MB RAM。最大的计划约为14GB。同样，这会有所帮助，但甚至不会适度扩展，更不用说相关成本了
• 大大减少了数据库的大小。如果可能的话，我希望避免这种情况。在1.9M行变为10k或50k的表上进行餐巾纸运算，应用程序将大大减少内存需求，并具有更好的扩展性，但仍有一些适度的最大使用限制

正如您所看到的，在内存管理方面，我充其量只是个新手。我正在寻找一些关于如何解决这个一般性问题的策略/想法，如果我需要大幅减少数据大小或为此投入大量美元，也可以

谢谢

Answer 1

根据我个人的经验，我认为有两种方法：

一,。计划it

根据您的示例，这意味着您尝试计算请求将使用的最大内存，将其乘以gunicorn工作者的数量，并使用足够大的dynos

举一个不同的例子，这可能是有效的，我认为这不适合你

二,。减少内存使用，解决方案1

使用了太多的应用程序内存这一事实使我认为，在将整个结果集返回到客户端之前，很可能在代码中将其加载到内存中（甚至可能以多种格式多次加载）

最后，您的应用程序只是从数据库获取数据并将其转换为某种输出格式（JSON/CSV？）

您可能正在搜索的是流式响应

您的Flask视图将在逐个记录的基础上工作。它将读取单个记录，将其转换为输出格式，然后返回单个记录

您的数据库客户端库和Flask都将支持此功能（在大多数数据库中，它被称为游标/迭代器）

二,。减少内存使用，解决方案2

其他服务通常使用简单的分页或限制结果集来管理服务器端内存

安全旁注

听起来用户实际上可以在API请求中定义SQL语句。这是一个安全和应用程序风险。除了执行INSERT、UPDATE或DELETE语句外，用户还可以创建一个SQL语句，它不仅会耗尽应用程序内存，还会破坏数据库