Answers:
我敢打赌,该系统实际上并没有“冻结”(就内核挂起而言),而是反应迟钝。可能是交换非常困难,导致交互性能和系统吞吐量下降得很困难。
您可以关闭交换,但这只会将问题从性能下降变为OOM终止的进程(以及所有带来的乐趣),并且由于可用磁盘缓存较少而导致性能下降。
或者,您可以使用每个进程的资源限制(通常称为rlimit
和/或ulimit
)来消除单个进程占用大量内存并导致交换的可能性,但是这只会使您进入娱乐性的领域,而该进程死于不方便的时刻,因为他们想要的内存比系统愿意提供的内存多一点。
如果您知道要执行可能导致大量内存使用的操作,则可以编写一个包装程序,该程序mlockall()
先执行an 然后执行外壳程序;这样可以将其保存在内存中,并且很可能是您保持“响应式内核”的最接近的方式(因为问题不在于CPU使用率过高)。
我个人赞成资源控制的“不要做愚蠢的事情”方法。如果您已经扎根,则可能会对系统造成各种损害,因此,做任何您可能不知道的可能结果都是危险的业务。
ulimit
如今,甚至cgroup,如果您是时髦的年轻人,也可以很好地完成工作。如果要在生产环境中对查询进行更改而不在非关键环境中验证查询的效果,那么这就是根本原因。
这是自2007年以来已知的错误-请参阅由于高内存使用而导致系统冻结。
在这种情况下,Windows将显示一个对话框,警告用户关闭一个或多个应用程序。
如果您想重新编译内核,可以尝试以下问题的部分进行修补EDIT
:https : //stackoverflow.com/q/52067753/10239615
它不会Active(file)
在内存压力很大时逐出页面,因此它可以使OOM杀手kill之所以能够立即触发,是因为内核不再需要花费几分钟的时间从磁盘上重新读取每个进程的可执行代码页,从而导致操作系统死机。
这是特别难以防止的事情。这是因为内核开始交换。一种解决方案是关闭交换。当系统内存不足,而不是开始交换时,内核将终止某些进程。通常它会选择正确的进程来杀死,但是总而言之,杀死一个随机进程要比没有响应的系统更好。
对于服务器而言,这可能是一个特别好的解决方案,因为服务器通常具有足够的RAM,并且当它们开始使用交换空间时,无论如何这都意味着有问题。但是,台式机通常需要交换空间,因此我认为台式机没有很好的解决方案。我经常关闭服务器中的交换空间,尤其是当怀疑有内存泄漏时。