最近我们部署了一个新版本的应用程序，从那时起我们就看到了一些非常奇怪的ActiveRecord问题。例如，这是一个查询片段，它每天生成数百次，通常是正确的：
`entries`.`style` AS t1_r25, `entries`.`pdf_visibility` AS , `entries`.`web_visibility` AS t1_r27
这不是一个错字，t1_r26在那里缺失，尽管它应该是一个空间。但只有那一次。这也不是手工编写的SQL，即ActiveRecord编写查询并决定所有占位符变量。它有类似的拙劣的其他查询留下空白，不应该是空白（甚至不可能），但只是偶尔一次。大部分时间都很好。
我们也看到很多实例抱怨像table_alias或者反射是一个未定义的变量或者假的方法：FalseClass。这是真的......但是FalseClass应该是ActiveRecord模型。我们不知道如何发生这种情况，或者我们怎么可能在我们的Rails代码中编写一个错误来完成大部分工作（尤其是上面的无效查询）。
我们在Rails 4.1.16（我们从4.1.8时开始升级时）升级到乘客5.0.26中的Ruby 2.2.0（接下来是5.0.30）。这些错误非常零星，没有任何意义。在每天数千个请求中，只有少数几个请求（5个服务器中少于10个）导致其中一个奇怪的错误，我们不能故意重现它们中的任何一个。
我的整个团队都很难过。我们花了几个小时仔细研究代码更改，看不到任何可能导致任何此类更改的内容。我们甚至不知道我们可能编写的内容会导致ActiveRecord有时以我们不应该影响的方式编写错误的查询。我们不知道如何开始对这种事情进行故障排除。有没有人提示可能会指出我们有一些有用的方向？
更新：这是今天早上扔的一个新的。请注意，LibraryItem是我们非常简单的ActiveRecord模型之一：
NoMethodError: undefined method `__callbacks' for #<LibraryItem:0x007f66cc5b82b0>
我......不知道。
答案 0 :(得分：0)
为那些试图帮助的人和任何偶然发现的人关闭循环：我们通过升级MRI来治愈它。我们已经在2.2.0上运行了大约一年，这就是我们没有立即怀疑它的原因，也是因为这是从特定部署开始的。当我们看到一些关于无法分配内存的错误时，我被告知，当一台服务器上有一堆弹片爆炸时（我的意思是它已经被分割出来）并且让乘客失望了。
从那时起，我开始查看MRI更改日志，并注意到内存中的 ton 以及2.2.0和2.2.5之间的GC相关错误修复。昨晚我们通过部署升级到2.2.5，并且（手指交叉）我们还没有看到这些奇怪问题中的一个。 （之前我们每天看到12-20或更多，具体取决于流量）。
那么，为什么在我们部署之后就开始发生了？我不确定，但我有一个猜测：我认为我们的应用程序在内存中的字节大小最终达到一些临界质量，它开始触发一个或多个固定在2.2之间的MRI错误。 0和2.2.5。我能想出最好的。
非常感谢那些介入尝试提供帮助的人！