Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > pl.comp.os.linux.programowanie > #2074

Re:Jak szukać problemów wydajnościowych w aplikacji wielowątkowej C/C++?

From Karol <news@linko.pl>
Newsgroups pl.comp.os.linux.programowanie
Subject Re:Jak szukać problemów wydajnościowych w aplikacji wielowątkowej C/C++?
Date 2016-04-13 14:26 +0200
Organization news.atman.pl
Message-ID <neldtv$j0c$1@node2.news.atman.pl> (permalink)
References <2cfcd79b-1d0b-4a5a-8f9d-13080d46ebb8@googlegroups.com>

Show all headers | View raw


Radosław Korzeniewski <radoslaw@korzeniewski.net> Wrote in message:
> Witam szanowną grupę,
> 
> Mam ciekawy problem wydajnościowy i poszukuję wskazówek co ugryźć aby dowiedzieć się o co chodzi.
> W ogólności mam aplikację sieciową klient/server. Klient jednowątkowy. Serwer wielowątkowy. Klient otwiera do serwera dwa połączenia: połączenie kontrolne i połączenie danych. Klient głównie wysyła dane do serwera, czasami coś odczytuje. Klient czyta dane z dysku. Serwer otrzymane dane zazwyczaj zapisuje na dysk. Po stronie serwera mam dwa wątki. Jak do tej pory maksymalną przepustowość jaką osiągnąłem to 1,5MB/s-2MB/s na sieci Gbit/s. Dotychczasowe śledztwo wykazało, że spowolnienie w transmisji spowodowane jest opóźnieniem w przesłaniu ACK z serwera do klienta na przesłane dane ale tylko co kilkadziesiąt pakietów. Zazwyczaj RTT dla ACK wynosi poniżej 1mS lecz co jakiś czas skacze do 20mS-40mS. Z powstałego opóźnienia wynika ograniczenie przepustowości. Dla mnie ewidentnie problem po stronie odbiorcy danych. Serwer jednak nie wykazuje żadnych oznak problemu. Procesor obciążony w 1%, dysk zapisuje te 1,5-2MB/s. Sprawdzam więc interakcję aplikacji serwera z systemem operacyjnym i znalazłem zagwozdkę. Jedno z przełączeń kontekstu trwało mniej więcej tyle co opóźnienie w ACK, w przykładzie poniżej: przełączenie z pid:4689 na pid:7931 trwa ok. 30mS. Takie opóźnienie powtarza się dla każdej kolejnej iteracji praktycznie w tym samym miejscu.
> 
> W tym momencie nie bardzo wiem jak to dalej drążyć. Może ktoś ma jakiś pomysł?
> 
> 7931  11:27:41.364036 read(1819, "G\f.\266\30\231\252]F\270\226\205\236\324\4\v8j\340\334\20e\217\16o\200\322AV\221\341K"..., 380) = 380 <0.000022>
> ----8<-------
> 7931  11:27:41.364152 pwrite64(156, "DS1\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1"..., 512, 373568000 <unfinished ...>
> 4689  11:27:41.364268 <... read resumed> "\0\0\0004", 4) = 4 <0.057966>
> ----8<-------
> 4689  11:27:41.364312 read(1818, "\0\0\0\1\0\1\0\0\0\1\0\0\0\0\0\0\1\314\0\0\353\251\313o\273z8\230G\20\307c"..., 52) = 52 <0.000013>
> 4689  11:27:41.364400 write(10, "dsevol0283\0", 11) = 11 <0.000019>
> 4689  11:27:41.364469 write(10, "\0\0\1\0", 4) = 4 <0.000012>
> 4689  11:27:41.364530 write(10, "\353\251\313o\273z8\230G\20\307c6IA\307&\226wY\333\207\365\207\236\r\205\261\366\0\"\322", 32) = 32 <0.000013>
> ----8<------- from
> 4689  11:27:41.364608 read(1818,  <unfinished ...>
> 7931  11:27:41.394933 <... pwrite64 resumed> ) = 512 <0.030725>
> ----8<------- to
> 7931  11:27:41.394969 pwrite64(156, "o\340EP\364r;5\270\350\r\211\262o\327)\350p3\247\372\22/R\0109z\207\3~ \370"..., 65536, 373568512) = 65536 <0.000288>
> 
> pozdrawiam
> -- 
> Radosław Korzeniewski
> 

Wygląda na problem zwązany z tcp nagle's algorithm.

Przy otwieraniu socketa trzeba użyć opcji TCP_NODELAY aby go wyłączyć. 

Pozdrawiam,
Karol

-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

Back to pl.comp.os.linux.programowanie | Previous | Next | Find similar


Thread

Re:Jak szukać problemów wydajnościowych w aplikacji wielowątkowej C/C++? Karol <news@linko.pl> - 2016-04-13 14:26 +0200

csiph-web