TLS memory overflow - V8 garbage collection
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 45/100
- Issue 類型
- 缺陷
- 描述清晰度
- 基本清楚
- 活躍度
- 冷清
- 技術堆疊
- javascript, nodejs
- 領域
- backend, networking, security
研究方向
使用 npm run server 和 issue 中描述的加密 WebSocket Performance Test 設定,在 aphorio repository 中重現。觀察 V8 垃圾回收和堆積錯誤輸出,同時比較 TLS 執行與未加密執行。加密測試完成並回傳結果,且未耗盡記憶體,即表示完成。
由索引模型根據 Issue 內容生成。
描述
Version
26.7.0
Platform
Microsoft Windows NT 10.0.26200.0 x64
Subsystem
No response
What steps will reproduce the bug?
- git clone https://github.com/prettydiff/aphorio
- npm run server
- Open a web browser to localhost and the specified port number
- In the browser use the left side navigation and choose Performance Test
- Choose these experiment settings:
- WebSocket
- Encrypted
- Send Only
- Force GC Between Tests
- Location - 127.0.0.1
- Port - specified secure port
- Test Quantity - 5000000
- Number of tests - 10
- Message Body - "test"
How often does it reproduce? Is there a required condition?
50%, no required condition
What is the expected behavior? Why is that the expected behavior?
The expected behavior is the application remains executing and returns test results.
What do you see instead?
<--- Last few GCs --->
[16960:00000220C3725000] 178739 ms: Scavenge (during sweeping) 7914.8 (7952.1) -> 7887.9 (7954.4) MB, pooled: 0.0 MB, 3.29 / 0.00 ms (average mu = 0.348, current mu = 0.370) allocation failure;
[16960:00000220C3725000] 179468 ms: Incremental Mark-Compact (reduce) 7919.9 (7957.1) -> 7890.5 (7896.4) MB, pooled: 0.0 MB, 33.63 / 0.00 ms (+ 668.4 ms in 133 steps since start of marking, biggest step 5.2 ms, walltime since start of marking 720 ms) (a
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
1: 00007FF748A7641D node::OnFatalError+1325
2: 00007FF749840FB1 v8::Function::NewInstance+577
3: 00007FF749625287 SSL_CTX_set_stateless_cookie_verify_cb+504087
4: 00007FF749622E4D SSL_CTX_set_stateless_cookie_verify_cb+494813
5: 00007FF74961D511 SSL_CTX_set_stateless_cookie_verify_cb+471969
6: 00007FF749624DEA SSL_CTX_set_stateless_cookie_verify_cb+502906
7: 00007FF7493C8C8F v8::MemorySpan<v8::internal::DirectHandle<v8::internal::Map> >::operator[]+890943
8: 00007FF749665ADE v8::internal::StrongRootAllocatorBase::deallocate_impl+201886
9: 00007FF74986B73C v8::ArrayBuffer::New+172
10: 00007FF748AD2A7F node::Buffer::New+43359
11: 00000220EBD501DA
Additional information
Unencrypted tests never fail in this manner as they will run to completion as long as it takes. This problem is specific to TLS. I have been able to run experiments comprising greater than 50,000,000 WebSocket messages repeatedly without any failures.
The error messaging indicates garbage collection in V8 is the culprit, but I suspect the problem could be OpenSSL causing V8 to hang unexpectedly until all memory is consumed.
This is an aside, but it seems at maximum efficiency I can send 3,250,000 messages in 0.002 seconds but the next 0.998 seconds is spent on garbage collection. I don't know if this is a potentially untapped optimization target. Aside from the garbage collection time it seems executing WebSockets like this application does is about 2300x faster than Bun.
I had a defect in my profiler.
- 主要語言
- JavaScript
- 星號
- 122k
- 分支
- 37.4k
- 平均合併
- 4 天 2 小時
- 30 天內合併 PR
- 277
貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
nodejs/node 的其他 Issue
-
doc
難度 2/5 1-3 小時 新手友好度 65/100
-
build
難度 1/5 1 小時以內 新手友好度 88/100
-
難度 2/5 1-3 小時 新手友好度 84/100
-
難度 1/5 1 小時以內 新手友好度 90/100
-
feature request
難度 2/5 1-3 小時 新手友好度 68/100
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 70/100
-
難度 2/5 1-3 小時 新手友好度 75/100
mksglu/context-mode#1200 ·
-
難度 2/5 1-3 小時 新手友好度 75/100
neondatabase/website#5944 ·
-
module: core
難度 2/5 1-3 小時 新手友好度 75/100
bigbluebutton/bigbluebutton#25849 ·
-
難度 2/5 1-3 小時 新手友好度 75/100
jaegertracing/jaeger-ui#4506 ·