为什么垃圾收集在网络应用程序？

考虑在平台上构建Web应用程序，每个请求由用户级线程（ULT）（绿色线程/ erlang进程/ goroutine/...任何轻量级线程）处理。假设每个请求都是无状态的，并且在应用程序启动时获得数据库连接等资源，并在这些线程之间共享。这些线程中垃圾收集的需求是什么？为什么垃圾收集在网络应用程序？

通常，这样的线程运行时间很短（几毫秒），如果设计良好的话不会使用超过几个（KB或MB）的内存。如果线程中分配的资源的垃圾收集在线程的出口处完成并且独立于其他线程，则即使第98或第99百分位的请求也不会发生GC暂停。所有请求都会在可预测的时间内回答。

这样的模型有什么问题，为什么它没有被广泛使用？

来源

2015-01-15 Sacheendra Talluri

也许是因为这些假设在现实世界的应用程序中没有实现？ – Volker

erlang每个erlang进程都有GC（绿色线程），所以如果每个请求都在一个没有重用的进程上处理，您可以调整GC设置（每个进程），这样除非进程使用了大量的GC的记忆。首先要看的设置是min_heap_size和full_sweep_after。说任何erlang GC都不是世界的停止，所以只会影响该进程的请求延迟。 –

我知道这可以在erlang中完成，但我想知道为什么这样做不流行，并且有没有这样做的负面影响。 –

您的假设可能并非如此。

如果精心设计不使用的内存超过

数（KB或MB）更多想象的功能在其在Web应用程序中使用的文本文件字数统计。一些天真的实现可能是，

def count_words(text): 
    words = text.split() 
    count = {} 
    for w in words: 
     if w in count: 
      count[w] += 1 
     else: 
      count[w] = 1 
    return count

它分配比文本更大的内存。

来源

2015-01-15 08:56:15 woodings

大多数面向Web应用程序的用户通常会收到请求，从数据库中检索或写入数据库，返回响应并完成请求。这个假设对于这样一个应用程序是有效的，而我上面建议的模型只会对延迟敏感的应用程序有利。我无法想象每个请求执行大量处理的应用程序对延迟敏感，因此不会受益于此模型。 –

@SacheendraTalluri的确如此。然而，有一个天真的标志和扫描GC不会伤害。如果最大堆大小大于工作负载大小，gc将不会启动。否则，如果未提供gc，程序必须停止。 – woodings

为什么垃圾收集在网络应用程序？

回答

相关问题