GHC pro Thread GC-Strategie

Question

Ich habe einen Scotty API-Server, der eine Elasticsearch Abfrage erstellt, Ergebnisse aus ES abruft und den JSON rendert.

Im Vergleich zu anderen Servern wie Phoenix und Gin, ich bin höhere CPU-Auslastung und Durchsatz für die Bedienung ES Antworten bekommen, indem Sie BloodHound aber Gin und Phoenix waren Größen besser als Scotty in Speichereffizienz.

Stats Scotty

wrk -t30 -c100 -d30s "http://localhost:3000/filters?apid=1&hfa=true" 
Running 30s test @ http://localhost:3000/filters?apid=1&hfa=true 
    30 threads and 100 connections 
    Thread Stats Avg  Stdev  Max +/- Stdev 
    Latency 192.04ms 305.45ms 1.95s 83.06% 
    Req/Sec 133.42 118.21  1.37k 75.54% 
    68669 requests in 30.10s, 19.97MB read 
Requests/sec: 2281.51 
Transfer/sec: 679.28KB 

Diese Statistiken sind auf meinem Mac mit GHC 7.10.1

Prozessor Info 2.5GHx i5
Speicher-Info 8 GB 1600 MHz DDR3

installiert Ich bin ganz beeindruckt durch die leichte Thread-basierte Parallelität von GHC, aber die Speichereffizienz bleibt ein großes Problem.

Speichernutzung Profil lieferte mir die folgenden Statistiken

39,222,354,072 bytes allocated in the heap 
    277,239,312 bytes copied during GC 
    522,218,848 bytes maximum residency (14 sample(s)) 
     761,408 bytes maximum slop 
      1124 MB total memory in use (0 MB lost due to fragmentation) 

            Tot time (elapsed) Avg pause Max pause 
    Gen 0  373 colls, 373 par 2.802s 0.978s  0.0026s 0.0150s 
    Gen 1  14 colls, 13 par 0.534s 0.166s  0.0119s 0.0253s 

    Parallel GC work balance: 42.38% (serial 0%, perfect 100%) 

    TASKS: 18 (1 bound, 17 peak workers (17 total), using -N4) 

    SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) 

    INIT time 0.001s ( 0.008s elapsed) 
    MUT  time 31.425s (36.161s elapsed) 
    GC  time 3.337s ( 1.144s elapsed) 
    EXIT time 0.000s ( 0.001s elapsed) 
    Total time 34.765s (37.314s elapsed) 

    Alloc rate 1,248,117,604 bytes per MUT second 

    Productivity 90.4% of total user, 84.2% of total elapsed 

gc_alloc_block_sync: 27215 
whitehole_spin: 0 
gen[0].sync: 8919 
gen[1].sync: 30902 

Phoenix nie mehr als 150 MB hat, während Gin viel niedriger Speicher nahm.

Ich glaube, dass GHC Mark und Sweep-Strategie für GC verwendet. Ich glaube auch, es wäre besser gewesen, pro-thread inkrementelle GC-Strategie zu verwenden, die Erlang VM für bessere Speichereffizienz ähnlich ist.

Und durch die Interpretation von Don Stewarts Antwort auf eine related question muss es eine Möglichkeit geben, die GC-Strategie in GHC zu ändern.

Ich bemerkte auch, dass die Speichernutzung stabil und ziemlich niedrig blieb, wenn der Nebenläufigkeitsgrad niedrig war, also denke ich, dass die Speicherbelegung nur dann aufgeht, wenn die Nebenläufigkeit ziemlich hoch ist.

Alle Ideen/Hinweise, um dieses Problem zu lösen.

Answer 1

http://community.haskell.org/~simonmar/papers/local-gc.pdf

Dieser Aufsatz von Simon Marlow beschreibt pro Thread lokalen Heaps, und behauptet, dass diese in GHC umgesetzt wurde. Es ist 2011 datiert. Ich kann nicht sicher sein, ob dies tatsächlich die aktuelle Version von GHC ist (dh, ging dies in die Release-Version von GHC, ist es immer noch der aktuelle Status quo, etc.), aber es scheint meine Die Erinnerung war nicht vollständig erfunden.

Ich werde auch den Abschnitt des GHC Handbuch, das die Einstellungen erklärt, weist darauf hin, können Sie den Garbage Collector einstellen twiddle:

https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime-control.html#rts-options-gc

Insbesondere standardmäßig GHC einen 2-Raum-Sammler verwendet, aber das Hinzufügen der -c RTS-Option macht es einen etwas langsameren 1-Raum-Kollektor, der weniger RAM essen sollte. (Ich bin völlig unklar, für welche Generation (en) diese Information gilt.)

Ich habe den Eindruck, Simon Marlow ist der Typ, der die meisten RTS-Sachen (einschließlich der Müllsammler) macht, also wenn Sie ihn finden können im IRC ist er der Typ, der fragt, ob du die direkte Wahrheit willst ...