ruby-on-rails - 奇怪的 ActiveRecord 问题——比如生成无效的 SQL

Question

最近我们部署了一个新版本的应用程序，从那时起我们就发现 ActiveRecord 存在一些非常奇怪的问题。例如，这是它每天生成数百次的查询片段，通常是正确的:

`entries`.`style` AS t1_r25, `entries`.`pdf_visibility` AS       , `entries`.`web_visibility` AS t1_r27

这不是打字错误，t1_r26 不见了，虽然它应该在的地方有一个空格。但只有那一次。这也不是手写 SQL，而是 ActiveRecord 编写查询并决定所有占位符变量。它同样拙劣地破坏了其他查询，将不应该留空(甚至不应该留空)的东西留空，但只是偶尔留空一次。大多数时候都很好。

我们还看到很多实例，其中它提示 table_alias 或反射是 false:FalseClass 上的 undefined variable 或方法。没错……但是 FalseClass 应该是 ActiveRecord 模型。我们不知道这一切是如何发生的，也不知道我们怎么可能在我们的 Rails 代码中编写一个错误来完成大部分工作(尤其是上面的无效查询)。

我们在 Passenger 5.0.26 中使用 Rails 4.1.16(我们从 4.1.8 开始升级)和 Ruby 2.2.0(接下来将升级到 5.0.30)。这些错误非常零星，没有任何意义。在每天数以千计的请求中，只有一小部分(在 5 个服务器上少于 10 个)导致这些奇怪的错误之一，我们不能故意重现其中任何一个。

我的整个团队都被难住了。我们花了数小时仔细研究代码更改，但看不到任何可能导致这种情况的因素。我们甚至不知道我们可能写了什么会导致 ActiveRecord 有时以我们不应该能够影响的方式编写错误的查询。我们不知道如何开始解决此类问题。有没有人能给我们指明一些有用的方向？

更新:这是它今天早上发布的一个新消息。请注意，LibraryItem 是我们非常简单的 ActiveRecord 模型之一:

NoMethodError: undefined method `__callbacks' for #<LibraryItem:0x007f66cc5b82b0>

我……不知道。

Answer 1

为那些试图提供帮助的人和任何陷入困境的人关闭循环:我们通过升级 MRI 治愈了它。我们已经在 2.2.0 上运行了大约一年，这就是为什么我们没有立即怀疑它，也因为它是从一个特定的部署开始的。当我们看到一些关于无法分配内存的错误时，我得到了提示，当 MRI 在一台服务器上爆炸成一片弹片冰雹时(我的意思是它发生了段错误)并使 Passenger 随之倒下。

从那里我开始查看 MRI 变更日志并注意到 2.2.0 和 2.2.5 之间有吨内存和 GC 相关的错误修复。昨晚我们通过部署升级到 2.2.5，并且(祈祷)我们还没有看到这些奇怪的问题中的一个。 (以前我们每天看到 12-20 个或更多，具体取决于流量)。

那么，为什么它会在我们部署后开始发生？我不确定，但我有一个猜测:我认为我们的应用程序在内存中的大小(以字节为单位)最终达到某个临界质量，它开始触发一个或多个在 2.2 之间修复的 MRI 错误。 0 和 2.2.5。我能想到的最好。

非常感谢那些介入协助的人!