Jak zoptymalizować program golang, który spędza najwięcej czasu w runtime.osyield i runtime.usleep

Question

Pracuję nad optymalizacją kodu, który analizuje dane z wykresów społecznych (z dużą pomocą od https://blog.golang.org/profiling-go-programs) i udało mi się przerobić wiele powolny kod.

Wszystkie dane są ładowane do pamięci z db pierwszy, a analiza danych z pojawia CPU związany (max zużycie pamięci < 10MB, CPU1 @ 100%)

Ale teraz większość czasu mój program wydaje się być w runtime.osyield i runtime.usleep. W jaki sposób temu zapobiec?

Ustawiłem GOMAXPROCS = 1, a kod nie odradza żadnych goroutines (innych niż te, które mogą wywoływać biblioteki golang).

To moje wyjście top10 z pprof

(pprof) top10 
62550ms of 72360ms total (86.44%) 
Dropped 208 nodes (cum <= 361.80ms) 
Showing top 10 nodes out of 77 (cum >= 1040ms) 
     flat flat% sum%  cum cum% 
    20760ms 28.69% 28.69% 20850ms 28.81% runtime.osyield 
    14070ms 19.44% 48.13% 14080ms 19.46% runtime.usleep 
    11740ms 16.22% 64.36% 23100ms 31.92% _/C_/code/sc_proto/cloudgraph.(*Graph).LeafProb 
    6170ms 8.53% 72.89%  6170ms 8.53% runtime.memmove 
    4740ms 6.55% 79.44% 10660ms 14.73% runtime.typedslicecopy 
    2040ms 2.82% 82.26%  2040ms 2.82% _/C_/code/sc_proto.mAvg 
    890ms 1.23% 83.49%  1590ms 2.20% runtime.scanobject 
    770ms 1.06% 84.55%  1420ms 1.96% runtime.mallocgc 
    760ms 1.05% 85.60%  760ms 1.05% runtime.heapBitsForObject 
    610ms 0.84% 86.44%  1040ms 1.44% _/C_/code/sc_proto/cloudgraph.(*Node).DeepestChildren 
(pprof) 

W _/C_/code/sc_proto/* funkcje mojego kodu.

a wyjście z sieci:

(lepsza wersja SVG wykresu tutaj: https://goo.gl/Tyc6X4)

Answer 1

znaleźć odpowiedź sam, więc jestem delegowania to tutaj dla każdego, kto jest posiadanie podobny problem. Specjalne podziękowania dla @ Jimb za wysłanie mnie właściwą drogą.

Jak widać na wykresie, ścieżki prowadzące do osyield i usleep są procedurami czyszczenia pamięci. Ten program korzystał z połączonej listy, która generowała dużo wskaźników, co spowodowało wiele pracy dla gc, co czasami blokowało wykonywanie mojego kodu, podczas gdy ja sprzątał mój bałagan.

Ostatecznie rozwiązanie tego problemu pochodzi z https://software.intel.com/en-us/blogs/2014/05/10/debugging-performance-issues-in-go-programs (co było niesamowitym źródłem Btw). Postępowałem zgodnie z instrukcjami dotyczącymi profilera pamięci; a zalecenie zastąpienia kolekcji wskaźników za pomocą plasterków wyjaśniło moje problemy ze zbieraniem śmieci, a mój kod jest teraz znacznie szybszy!