我正在与团队一起开发一个单页应用程序,其中有许多计时器,每秒约10个REST API调用。我们使用Chrome内存分析工具定位了所有内存泄漏--目前堆大小保持不变(即在垃圾收集之间)。然而,我们注意到应用程序运行时间越长,Chrome选项卡本身使用的内存就越多。几个小时后,我们发现选项卡内存增长到约350MB,而堆大小仍为6MB。如果运行一整夜,选项卡将消耗超过500MB,并在早上变得无法使用。
我们需要应用程序长时间运行(我们希望每周只重启一次),所以这是一个问题。
以下是一个小时内堆时间轴的截图。最后,选项卡的私有内存大小为350MB,而堆的大小保持在大约5.4MB左右。
我们在Windows 7上的Chrome 40和Chrome 38中看到了这种情况。我们已禁用缓存,在隐身模式下运行应用程序。
任何想法为什么选项卡内存大小会增长到Chrome无法使用的程度,而JS堆使用率仍然很小?
编辑:我们运行了应用程序几天,选项卡内存大小增加到800MB,堆大小仍然差不多。
编辑(6/9/15):我不确定这是否有文档记录,但似乎Chrome根据系统上的可用内存量更改将分配给选项卡的内存量。因此,如果您有大量可用内存,则选项卡将使用大量内存,而如果没有太多,则不会使用太多。这似乎与堆大小不成比例,可能只是Chrome保留的为使自己更快而存在的东西。这只是一种理论,基于对Chrome内存使用情况的监视 :)
我们需要应用程序长时间运行(我们希望每周只重启一次),所以这是一个问题。
以下是一个小时内堆时间轴的截图。最后,选项卡的私有内存大小为350MB,而堆的大小保持在大约5.4MB左右。
我们在Windows 7上的Chrome 40和Chrome 38中看到了这种情况。我们已禁用缓存,在隐身模式下运行应用程序。
任何想法为什么选项卡内存大小会增长到Chrome无法使用的程度,而JS堆使用率仍然很小?
编辑:我们运行了应用程序几天,选项卡内存大小增加到800MB,堆大小仍然差不多。
编辑(6/9/15):我不确定这是否有文档记录,但似乎Chrome根据系统上的可用内存量更改将分配给选项卡的内存量。因此,如果您有大量可用内存,则选项卡将使用大量内存,而如果没有太多,则不会使用太多。这似乎与堆大小不成比例,可能只是Chrome保留的为使自己更快而存在的东西。这只是一种理论,基于对Chrome内存使用情况的监视 :)