Похоже, что для моей операции очистки отметки сервера требуются секунды, чтобы остановить мир:
Oct 17 08:26:27 s3 u[30843]: [30843:0x26671a0] 63025059 ms: Mark-sweep 2492.7 (3285.6) -> 2317.6 (2945.0) MB, 84.9 / 0.1 ms (+ 3223.4 ms in 3877 steps since start of marking, biggest step 731.7 ms, walltime since start of marking 3315 ms) finalize incremental marking via task GC in old space requested
Oct 17 08:26:27 s3 u[30843]: Execution blocked for 3273 ms
.
Oct 17 08:28:15 s3 u[30843]: [30843:0x26671a0] 63133051 ms: Mark-sweep 2499.8 (3298.4) -> 2313.4 (2947.1) MB, 160.2 / 0.1 ms (+ 3691.7 ms in 3679 steps since start of marking, biggest step 1073.4 ms, walltime since start of marking 3859 ms) finalize incremental marking via task GC in old space requested
Oct 17 08:28:15 s3 u[30843]: Execution blocked for 3791 ms
.
Это поведение аналогично описанному в https://github.com/nodejs/help/issues/947,, это выглядит несколькосвязано с потреблением памяти и со временем ухудшается.
Проблема существовала в узле 7, но была едва заметна.Теперь с узлом 8.12 он достигает 5-секундного блока в течение 24 ч.
Я подозревал, что это может быть связано с неортодоксальным способом хранения данных в больших объектах, пытался реконструировать один объект размером 2 ГБ в меньшие объекты, сокращая егодо 1 ГБ, но очевидного преимущества нет.Однако эти объекты очень просты, хотя и велики.
Вопросы:
Существует ли опция V8, чтобы сделать разметку, чтобы смягчить эту проблему?Реже, меньшие шаги, пропустить некоторые оптимизации, что-нибудь?
Я не мог найти приличную документацию о вариантах V8 - есть?
Как помочь mark-sweep в более эффективном выполнении этой задачи?
Существуют ли распространенные случаи, которых следует избегать, когда Mark-Sweep может бороться?
Какие-нибудь отчаянные хаки, которые я мог бы попробовать?