Haskell适合长期运行的应用程序吗？

Question

我认为Haskell是一种优美的语言,从基准测试来看,它的实现可以生成快速的代码.

但是,我想知道它是否适用于长期运行的应用程序,或者是否会追逐所有潜在的懒惰引发的泄漏,人们可能会在短期应用程序中忽略这些泄漏,这会让人感到沮丧吗？

这个Reddit评论回应了我的担忧:

只要有多个函数递归调用自身,堆配置文件就会停止为您提供任何帮助,以确定泄漏发生的位置.

(整个讨论似乎很有洞察力和坦率)

我个人对高性能计算感兴趣,但我想服务器和HPC有这个共同的要求.

如果Haskell适用于此类应用程序,是否有任何证明这一点的示例,即应用程序

1. 需要运行数天或数周,因此需要消除所有相关的泄漏(程序花费睡眠或等待某些底层C库返回的时间显然不计算在内)
2. 非平凡(如果应用程序很简单,开发人员可能只是猜测泄漏的来源并尝试各种修复.但是,我不相信这种方法可以很好地扩展.堆配置文件在识别源代码时的帮助性.具有多个[相互]递归函数的泄漏似乎特别令人担忧,如上面的Reddit讨论所述)

如果Haskell不适合这样的应用程序,为什么呢？

更新:作为示例提出的Haskell的Yesod Web服务器框架可能存在内存问题.我想知道是否有人在连续几天提出请求后测试其内存使用情况.

Answer 1

"空间泄漏"在语义上与任何语言中的任何其他类型的资源使用问题相同.在严格的语言中,GC倾向于分配和保留过多的数据(因为结构是严格的).

无论你使用什么语言,你都应该"烧入"以寻找资源使用情况,而Haskell也不例外.

例如xmonad,一次运行数月或数年.它是一个Haskell应用程序,具有很小的堆使用,我通过运行数周或数月进行分析,以分析堆模式.这让我相信资源使用是稳定的.

最终,懒惰在这里是一个红色的鲱鱼.使用资源监视工具和测试来测量和验证您的资源期望.

Answer 2

warp Web服务器证明Haskell适用于长时间运行的应用程序.

当Haskell应用程序有空间泄漏时,可能很难找到原因,但一旦知道原因通常很容易解决(我必须使用的最难的解决方案是应用于zip [1..]列表并从中获取长度最后一个元素而不是使用length函数).但是在Haskell程序中,空间泄漏实际上是非常罕见的.故意造成空间泄漏通常比修复意外泄漏更困难.

Answer 3

大多数长期运行的应用都是请求驱动的.例如,HTTP服务器将所有瞬态数据与HTTP请求相关联.请求结束后,数据将被丢弃.因此,至少对于那些长期运行的应用程序,任何语言都不会有空间泄漏.在单个请求的上下文中泄漏您想要的所有内容.只要您不为每个请求数据创建全局引用,就不会泄漏.

如果你改变全球状态,所有的赌注都会被取消.由于许多原因,应该避免这种情况,并且在这样的应用程序中这种情况并不常见.

Answer 4

它是.有两种可能的空间泄漏:

堆上的数据.这种情况与使用GC的其他语言没有什么不同.(对于没有这种情况通常更糟糕的情况 - 如果出现错误,而不是增加内存使用量,过程可能会触及释放的内存,反之亦然,只是严重崩溃.)

未评估的thunk.不可否认,人们可以在脚下射击,当然必须避免产生像大笨蛋一样的众所周知的情况foldl (+) 0.但是要防止这种情况并不难,而且对于其他泄漏事件,我会说,当你习惯它时,它实际上比其他语言更容易.

您可以使用长时间运行的繁重计算,也可以使用响应请求的服务.如果你有一个长时间运行的计算,你通常需要在计算时立即得到结果,这会强制进行评估.

如果你有一个服务,它的状态通常都很好,所以很容易确保它总是在请求结束时进行评估.实际上,与其他语言相比,Haskell使这更容易:在Haskell中,您不能让程序的组件保持其自己的内部状态.应用程序的全局状态要么在某种主循环中作为参数进行线程化,要么使用存储IO.由于Haskell应用程序的良好设计限制并IO尽可能地进行本地化,因此它再次使状态易于控制.

另一个例子是Ganeti项目(我是开发人员)使用了几个Haskell长期运行的守护进程.

根据我们的经验,内存泄漏已经非常罕见,如果我们遇到问题,通常会使用其他资源(如文件描述符).我记得的唯一一个近期案例是监控守护程序在极少数情况下将内存泄漏为收集数据,但是没有人看过它们(这将迫使他们进行评估).该修复是相当简单的.