GHC cho mỗi chủ đề Chiến lược GC

Question

Tôi có máy chủ api Scotty tạo cấu hình truy vấn Elasticsearch, tìm nạp kết quả từ ES và hiển thị json.

So với các máy chủ khác như Phoenix và Gin, tôi nhận được sử dụng CPU cao và thông lượng phục vụ ES phản ứng bằng cách sử dụng BloodHound nhưng Gin và Phoenix là độ lớn hơn Scotty hiệu quả bộ nhớ.

Thống kê cho 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 

Những số liệu thống kê được trên máy Mac của tôi có GHC 7.10.1 cài đặt

thông tin Processor 2.5GHx i5
Memory info 8GB 1600Mhz DDR3

tôi khá ấn tượng bởi sự đồng thời dựa trên chủ đề nhẹ của GHC nhưng hiệu quả bộ nhớ vẫn là một mối quan tâm lớn.

Profiling sử dụng bộ nhớ mang lại cho tôi những số liệu thống kê sau

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 không bao giờ mất hơn 150 MB, trong khi Gin mất trí nhớ thấp hơn nhiều.

Tôi tin rằng GHC sử dụng chiến lược đánh dấu và quét cho GC. Tôi cũng tin rằng nó sẽ được tốt hơn để sử dụng cho mỗi chiến lược GC gia tăng thread giống như Erlang VM cho hiệu quả bộ nhớ tốt hơn.

Và bằng cách giải thích câu trả lời của Don Stewart thành related question, phải có một số cách để thay đổi chiến lược GC trong GHC.

Tôi cũng lưu ý rằng việc sử dụng bộ nhớ vẫn ổn định và khá thấp khi mức độ tương tranh thấp, vì vậy tôi nghĩ việc sử dụng bộ nhớ chỉ tăng lên khi đồng thời là khá cao.

Bất kỳ ý tưởng/con trỏ nào để giải quyết vấn đề này.

Answer 1

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

giấy này bởi Simon Marlow mô tả mỗi sợi đống địa phương, và tuyên bố rằng điều này đã được thực hiện trong GHC. Đó là ngày năm 2011. Tôi không thể chắc chắn nếu đây là những gì phiên bản hiện tại của GHC thực sự (ví dụ, đã làm điều này đi vào phiên bản phát hành của GHC, nó vẫn là hiện trạng, vv), nhưng có vẻ như của tôi hồi ức không hoàn toàn được tạo thành.

Tôi cũng sẽ chỉ ra những phần của cuốn cẩm nang GHC giải thích các thiết lập, bạn có thể quay vòng để điều chỉnh thu gom rác:

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

Đặc biệt, theo mặc định GHC sử dụng một nhà sưu tập 2-không gian, nhưng thêm tùy chọn RTS -c làm cho nó sử dụng bộ thu 1 không gian hơi chậm hơn, nên ăn ít RAM hơn. (Tôi hoàn toàn không rõ (các) thông tin này áp dụng cho.)

Tôi có ấn tượng Simon Marlow là người làm hầu hết các công cụ RTS (bao gồm cả bộ thu gom rác), vì vậy nếu bạn có thể tìm thấy anh ta trên IRC, anh ấy là người hỏi bạn có muốn sự thật trực tiếp không ...