多線程的haskell程序的內存分析

我有一個Snap Web應用程序，它服務於一些JS文件和1像素圖像（它的主要任務是寧可快速工作，然後服務於大量的HTML /媒體內容）。 HAProxy後面有幾臺服務器。多線程的haskell程序的內存分析

我將它從GHC 7.6升級到7.8，同時升級了一些庫。升級後，應用程序開始一點一點地泄漏（在所有服務器上），最後在8GB RAM機器上每隔15分鐘結束一次OOM（在16Gb上更長），然後重新啓動。

問題是，如果我編譯應用程序進行性能分析並運行應用程序一段時間，我看不到任何內存泄漏。它只消耗1個CPU，並且在不斷的小內存中工作。

所以我想問一些關於如何找到這樣一個瓶頸的一般性建議，如果在分析中運行沒有多大幫助。

更新：我發現玩過一個應用程序後，如果我刪除-A100M運行時選項它沒有OOM那麼快，但默認值HAProxy的「會話」達到它的限制（所以，基本上它扼流圈）。我現在正在使用不同的RTS選項，希望有些人能夠幫助獲得兼顧性能和長時間的內存消耗。

更新2：只是爲了記錄，我發現與-A30 rts選項應用程序，雖然是飢餓的內存，生活相當不錯。 8Gb機器的OOM殺應用程序，但16Gb一個看起來像這樣：http://i.imgur.com/3W9KpFS.png（綠線是「RAM可用」，你可以看到部署程序重新啓動應用程序的圖形）。我對結果很滿意，但很高興知道任何技術來分析多線程應用程序的內存。

更新3：我投票結束這個問題「太寬泛」。一般來說，如果能夠讓你簡化內存配置的通用工具集會更加簡單，那麼他們肯定會在wiki等其他地方被記錄下來。

來源

2014-09-03 Kostiantyn Rybnikov

你意識到這篇文章缺少大量重要信息？什麼應用？什麼庫涉及？什麼OS？什麼CPU？源代碼在哪裏？檔案在哪裏？你使用了哪些運行時選項？什麼性能分析工具（threadscope）？你研究過哪些文獻（如http://chimera.labs.oreilly.com/books/1230000000929/ch15.html#sec_concuning）？這可能是從ghc-7.6到7.8的迴歸，但是你檢查了他們的錯誤跟蹤器（https://ghc.haskell.org/trac/ghc/wiki/ReportABug）。 – d8d0d65b3f7cf42 2014-09-03 11:14:06

@ d8d0d65b3f7cf42我提供了我認爲當時唯一相關的信息。你的大部分問題都不足以回答（比如「什麼應用？」）。我嘗試了不同的運行時選項（也分析了一些）。 threadscope如何與內存分析相關？我過去使用過它，但我認爲這裏沒有關係。我沒有讀過這本書，但是又一次，它有關於內存分析的章節嗎？我不知道這是否迴歸。爲了說明這一點 - 我們首先需要以某種方式針對問題。 – 2014-09-03 11:36:27

@ d8d0d65b3f7cf42因此，我很樂意回答任何具體的問題，這些問題會給出一些有助於更接近解決方案的結果。隨意問！ – 2014-09-03 11:37:16

我從來沒有用過它，但也許ticky-ticky profiling可以提供幫助嗎？它應該不受普通分析引起的優化變化的影響，但代價是難以解釋。

基本上編譯和相關模塊與-ticky和-rtsopts標誌聯繫起來，並與+RTS -rfoo.ticky標誌運行時獲得的數據堆在foo.ticky。

來源

2014-09-03 16:32:58

多線程的haskell程序的內存分析

回答

相關問題