Błąd alokacji pamięci nodejs v8

Question

Próbuję profilować pamięć nodejs v8 za pomocą serwera do zrobienia niczego. Użyłem node-memwatch, aby uzyskać różnicę sterty. Zbieram informacje o sterty przed połączeniem i po zakończeniu połączenia. Użyłem węzła-memwatch. Próbowałem 200 równoczesnych połączeń od strony klienta.

Oto ślad gc po odłożeniu połączenia.

może ktoś mi pomóc zrozumieć:

1.why są pamięć rośnie? po zerwaniu połączenia serwer absolutnie nie robi nic. czy nie powinien on zawsze upuszczać w miarę zbierania garbages?
2. co to jest awaria alokacji? Jak mogę naprawdę zinterpretować ślad tutaj?

15802 ms: Mark-sweep 8.9 (45.0) -> 8.1 (45.0) MB, 58 ms [allocation failure] [GC in old space forced by flags]. 
16144 ms: Mark-sweep 9.2 (45.0) -> 8.4 (45.0) MB, 53 ms [allocation failure] [GC in old space forced by flags]. 
16495 ms: Mark-sweep 9.5 (45.0) -> 8.7 (46.0) MB, 60 ms [allocation failure] [GC in old space forced by flags]. 
16837 ms: Mark-sweep 9.8 (46.0) -> 9.0 (46.0) MB, 56 ms [allocation failure] [GC in old space forced by flags]. 
17197 ms: Mark-sweep 10.1 (46.0) -> 9.4 (46.0) MB, 62 ms [allocation failure] [GC in old space forced by flags]. 
17905 ms: Mark-sweep 11.5 (46.0) -> 10.0 (47.0) MB, 74 ms [Runtime::PerformGC] [GC in old space forced by flags].                
18596 ms: Mark-sweep 12.2 (47.0) -> 10.7 (47.0) MB, 75 ms [Runtime::PerformGC] [GC in old space forced by flags]. 
19315 ms: Mark-sweep 12.8 (47.0) -> 11.3 (48.0) MB, 83 ms [allocation failure] [GC in old space forced by flags]. 
20035 ms: Mark-sweep 13.4 (48.0) -> 12.0 (49.0) MB, 90 ms [Runtime::PerformGC] [GC in old space forced by flags]. 
21487 ms: Mark-sweep 16.0 (49.0) -> 13.2 (50.0) MB, 96 ms [Runtime::PerformGC] [GC in old space forced by flags]. 
22950 ms: Mark-sweep 17.3 (50.0) -> 14.5 (52.0) MB, 116 ms [Runtime::PerformGC] [GC in old space forced by flags]. 
24376 ms: Mark-sweep 18.8 (52.0) -> 15.9 (53.0) MB, 114 ms [allocation failure] [GC in old space forced by flags]. 
25849 ms: Mark-sweep 19.9 (53.0) -> 17.2 (54.0) MB, 129 ms [Runtime::PerformGC] [GC in old space forced by flags]. 
28773 ms: Mark-sweep 25.2 (54.0) -> 19.7 (57.0) MB, 149 ms [allocation failure] [GC in old space forced by flags]. 
31725 ms: Mark-sweep 27.7 (57.0) -> 22.2 (59.0) MB, 172 ms [Runtime::PerformGC] [GC in old space forced by flags]. 
34678 ms: Mark-sweep 30.2 (59.0) -> 24.7 (61.0) MB, 190 ms [Runtime::PerformGC] [GC in old space forced by flags]. 
44045 ms: Mark-sweep 28.4 (61.0) -> 25.8 (63.0) MB, 180 ms [idle notification] [GC in old space forced by flags]. 
44216 ms: Mark-sweep 25.8 (63.0) -> 25.8 (63.0) MB, 170 ms [idle notification] [GC in old space requested]. 
57471 ms: Mark-sweep 26.9 (63.0) -> 25.8 (62.0) MB, 167 ms [Runtime::PerformGC] [GC in old space forced by flags]. 
57651 ms: Mark-sweep 26.8 (62.0) -> 25.5 (62.0) MB, 160 ms [Runtime::PerformGC] [GC in old space forced by flags]. 
57828 ms: Mark-sweep 26.5 (62.0) -> 25.5 (62.0) MB, 159 ms [Runtime::PerformGC] [GC in old space forced by flags]. 

Dzięki

Answer 1

Według kodu:

PrintF("%s %.1f (%.1f) -> %.1f (%.1f) MB, ", 
     CollectorString(), 
     static_cast<double>(start_object_size_)/MB,                      
     static_cast<double>(start_memory_size_)/MB, 
     SizeOfHeapObjects(), 
     end_memory_size_mb); 

Każda linia jest jednym GC, kiedy GC rozpoczęła,

start_object_size_ = heap_->SizeOfObjects(); 

Podsumowując GW:

PrintF("total_size_before=%" V8_PTR_PREFIX "d ", start_object_size_);                 
PrintF("total_size_after=%" V8_PTR_PREFIX "d ", heap_->SizeOfObjects()); 

As dlaczego start_object_size_ zwiększa się w czasie, gdy moja aplikacja jest bezczynna, zgaduję, może podczas gc, niektóre obiekty zostały pro przeniesiono do starej przestrzeni i zwiększono rozmiar obiektu w starej przestrzeni.

Answer 2

"awaria przydział" brzmi bardzo dramatyczne, ale nie ma prawdziwej awarii zaangażowany. Oznacza to tyle, że przydzieliliśmy tyle pamięci, że nadszedł czas, aby zrobić GC, aby sprawdzić, czy możemy zebrać trochę pamięci.

Wygląda na to, że używasz flagi -gc-global ("GC wymuszone przez flagi"). To kiepski pomysł na produkcję, chociaż może to być dobre dla zawężenia problemu podczas debugowania.

Nie mogę powiedzieć, dlaczego proces jest nieszczelny. Możesz znaleźć profiler sterty jako użyteczny. Zobacz https://github.com/felixge/node-memory-leak-tutorial