最近我们部署了一个新版本的应用程序，从那以后，我们发现ActiveRecord出现了一些非常奇怪的问题。例如，下面是它每天生成数百次的查询片段，通常是正确的:
`entries`.`style` AS t1_r25, `entries`.`pdf_visibility` AS , `entries`.`web_visibility` AS t1_r27
这不是打字错误，t1_r26没有出现，虽然它应该出现的地方有一个空格。但只有那一次。这也不是手工编写的SQL，而是ActiveRecord编写查询并决定所有占位符变量。它也有类似的拙劣的其他查询，留下空白的东西，不应该是空白的(甚至不应该是可能的)，但只是偶尔。大多数时候都很好。
我们也看到很多例子，它抱怨的东西，如table_alias或反射是一个未定义的变量或方法在false:FalseClass。这是真的…但FalseClass应该是一个ActiveRecord模型。我们不知道这是怎么发生的，也不知道我们怎么可能在Rails代码中写了一个bug来做这些(尤其是上面的无效查询)。
我们使用的是Rails 4.1.16(从4.1.8升级到Passenger 5.0.26)和Ruby 2.2.0(下一个版本是5.0.30)。这些错误是非常偶然的，没有一个是有意义的。在每天成千上万的请求中，只有一小部分(5个服务器上少于10个)会导致这些奇怪的错误之一，我们无法故意重现它们中的任何一个。
我整个团队都被难住了。我们花了几个小时仔细研究代码更改，却看不到任何可能导致这些变化的原因。我们甚至不知道我们可能写了什么会导致ActiveRecord有时以一种我们不应该能够影响的方式写一个糟糕的查询。我们不知道如何开始排除这种事情。有人能给我们点有用的线索吗?
更新:这是它今天早上扔的一个新的。注意，LibraryItem是我们非常简单的ActiveRecord模型之一:
NoMethodError: undefined method `__callbacks' for #<LibraryItem:0x007f66cc5b82b0>
我…不知道
总结一下，对于那些试图帮助你的人，以及那些无意中遇到这种情况的人:我们通过升级MRI治愈了它。我们已经在2.2.0上运行了大约一年，这就是为什么我们没有立即怀疑它，也因为这是从一个特定的部署开始的。当我们看到一些关于无法分配内存的错误时，我得到了提示，当MRI在一个服务器上爆炸时(我的意思是它发生了分段故障)，并导致Passenger崩溃。
从那时起，我开始查看MRI变更日志，并注意到在2.2.0和2.2.5之间有吨的内存和GC相关错误修复。昨晚我们升级到2.2.5部署，(祈祷)我们还没有看到一个奇怪的问题。(以前我们每天看到12-20个，或者更多，这取决于流量)。那么，为什么它开始发生在我们的部署之后?我不确定，但我有一个猜测:我认为我们的应用程序在内存中的字节大小最终达到了某个临界质量，它开始触发一个或多个MRI错误，这些错误在2.2.0和2.2.5之间得到了修复。这是我能想出的最好的办法。
非常感谢那些介入试图帮助的人!