Kontynuujemy nasze zmagania z przetwarzaniem zapytań. W pierwszej części zdefiniowaliśmy problem i podjęliśmy pierwsze próby implementacji rozwiązania. Szybko jednak okazało się, że istnieją lepsze metody. Dzisiaj będziemy eksperymentować z wielowątkowością. Oczywiście nie obejdzie się bez problemów…
Kod źródłowy eksperymentów można znaleźć tutaj.
Przejdźmy do rzeczy – ostanie wyniki pokazały, że nasz procesor się nudzi. Zapytania są niezależne więc wielowątkowość wydaje się być naturalnym remedium. Zróbmy więc tak jak robi wiele serwerów – każde zapytanie będzie obsługiwane przez osobny wątek.
Nasza (naiwna) implementacja będzie wyglądać mniej więcej tak:
for_each request in 100k_requests:
create_thread(RequestProcessor::Process(request))
Uruchamiamy więc nasz program:
$ ./processing_pipeline 2 Running Experiment_2_thread_per_req Experiment interrupted - exception thrown: Resource temporarily unavailable Only 32747 threads created Waited 3951.76 ms, avg 25305.2 trans/sec
Hmm… Program przerwał działanie. Widzimy, że udało się stworzyć 32 747 wątków. Prawdopodobnie nie powiodło się stworzenie kolejnego wątku. Sprawdźmy tą hipotezę:
$ gdb ./processing_pipeline ... (gdb) catch throw (gdb) run 2 ... (gdb) bt #0 0x00007ffff78c58bd in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #1 0x00007ffff78ee7fe in std::__throw_system_error(int) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #2 0x00007ffff78f0e73 in std::thread::_M_start_thread(...) #3 0x000000000040eabe in std::thread::thread<...>(...)... <...> #7 0x0000000000404705 in Experiment_2_thread_per_req () at main.cpp:92 #8 0x00000000004058ce in main (argc=2, argv=0x7fffffffdcb8) at main.cpp:294
Tak, próba stworzenia nowego obiektu std::thread nie powiodła się. Zapewne przekroczyliśmy jakiś limit. Pytanie tylko o jaki limit chodzi? Bo nie ma czegoś takiego jak limit wątków… W systemie Linux mamy kilka limitów które mogą ograniczać bezpośrednio lub pośrednio liczbę wątków i/lub procesów:
- Globalny limit procesów (wątek też liczony jako proces) zdefiniowany w
/proc/sys/kernel/threads-max. U mnie ustawiony jest na:
$ cat /proc/sys/kernel/threads-max 513640
- Górny limit wartości jaki może przyjąć deskryptor (pid) procesu (i wątku) zdefiniowany w
/proc/sys/kernel/pid_max, wartość jest obliczana przez kernel na podstawie prostej formuły: 1024 * liczba_rdzeni * liczba_wątków_per_rdzeń.
$ cat /proc/sys/kernel/pid_max 32768
- Maksymalna liczba zmapowanych obszarów pamięci w procesie (więcej tego typu limitów tutaj). Limit ten można odczytać w
/proc/sys/vm/max_map_count:
$ cat /proc/sys/vm/max_map_count 65530
A co to oznacza w praktyce? Zajrzyjmy w dokumentację:
max_map_count: This file contains the maximum number of memory map areas a process may have. Memory map areas are used as a side-effect of calling malloc, directly by mmap, mprotect, and madvise, and also when loading shared libraries. While most applications need less than a thousand maps, certain programs, particularly malloc debuggers, may consume lots of them, e.g., up to one or two maps per allocation. The default value is 65536.
W skrócie można powiedzieć, że licznik zmapowanych obszarów pamięci powiększa się kiedy np. ładujemy bibliotekę so, kiedy alokator pamięci dostaje nowy blok z kernela, bezpośrednie wywołania mmap, mprotect, madvise, i co dla nas najważniejsze – tworzenie wątku.
- RLIMIT_AS, RLIMIT_DATA – limit wielkości wirtualnej przestrzeni i limit segmentu danych dla procesu (zmienne zainicjowane, niezainicjowane, sterta (heap). Limity te mogą być zmieniane jednaj wartości domyślne łatwo odczytać (podobnie jak
ulimit -aale mamy więcej detali):
$ cat /proc/self/limits Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size 0 unlimited bytes Max resident set unlimited unlimited bytes Max processes 256820 256820 processes Max open files 1024 1048576 files Max locked memory 65536 65536 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 256820 256820 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us
- Limit wynikający z braku wirtualnej pamięci dla nowych wątków. Każdy nowy wątek dostaje stos dla którego system operacyjny przydziela pewien obszar pamięci w wirtualnej przestrzeni. Obecnie dla systemów 64 bitowych stosowany jest model kanoniczny, czyli wykorzystujemy tylko 48 bitów do adresacji. Więc cała przestrzeń to 2^64. Przestrzeń użytkownika to połowa z tego – 128 TB. Szczegóły tutaj. Z drugiej strony stos zajmuje:
$ ulimit -s 8192
Co oznacza 8192 kB * 1024 = 8388608M = 8 MB. Teoretycznie mamy miejsce w wirtualnej pamięci na 128 TB / 8 MB = 16 777 216 wątków.
- Inne limity zdefiniowane dla użytkownika jak np.
max user processes.
$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 256820 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 256820 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
Ok, uzbrojeni w pewną wiedzę teoretyczną kontynuujmy nasze śledztwo. Jak zwykle warto zobaczyć jakie funkcje systemowe zostały wywołane, ile i z jakim skutkiem:
$ strace -c ./processing_pipeline 2 Running Experiment_2_thread_per_req Experiment interrupted - exception thrown: Resource temporarily unavailable Only 32747 threads created Waited 2993.39 ms, avg 33406.9 trans/sec % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 28.10 0.000558 0 32747 clone 26.13 0.000519 0 32759 1 mprotect 24.07 0.000478 0 32748 munmap 19.18 0.000381 0 32770 mmap 1.81 0.000036 0 3806 brk 0.70 0.000014 0 291 18 futex 0.00 0.000000 0 6 read 0.00 0.000000 0 8 write 0.00 0.000000 0 7 open 0.00 0.000000 0 7 close 0.00 0.000000 0 7 fstat 0.00 0.000000 0 3 lseek 0.00 0.000000 0 2 rt_sigaction 0.00 0.000000 0 1 rt_sigprocmask 0.00 0.000000 0 7 7 access 0.00 0.000000 0 1 execve 0.00 0.000000 0 1 getrlimit 0.00 0.000000 0 1 arch_prctl 0.00 0.000000 0 1 set_tid_address 0.00 0.000000 0 1 set_robust_list ------ ----------- ----------- --------- --------- ---------------- 100.00 0.001986 135174 26 total
Widzimy, że wywołanie funkcji futex dało negatywne rezultaty aż 18 razy. Jednak sama funkcja została wywołana tylko 291 razy co nie odpowiada ilości stworzonych wątków. Za to ciekawy trop daje nam funkcja systemowa mprotect – wywołana została 32 759 razy czyli prawie tyle co liczba naszych wątków (32 747). Ale najciekawsze jest to, że tylko jeden raz zwróciła błąd. Sprawdźmy co to za błąd:
$ strace -e trace=mprotect ./processing_pipeline 2 2>&1| grep "= -1" mprotect(0x7fa762ba1000, 4096, PROT_NONE) = -1 ENOMEM (Cannot allocate memory)
Dokumentacja lakonicznie stwierdza:
ENOMEM Internal kernel structures could not be allocated.
Ale możemy zrobić dwie rzeczy – rzucić okiem w kod źródłowy kernela albo zaryzykować hipotezę, że limit mapowania obszarów pamięci został przekroczony (mprotect jest wymieniana jako funkcja mogąca naruszyć ten limit). Jednak aby mieć podstawy do uznania hipotezy za prawdopodobną trzeba wykazać, że ograniczenie 65530 zostało naruszone. Więc policzmy liczbę wywołań: 32759 − 1 (mprotect) + 32770 (mmap) = 65528. Różnica może wynikać z dodatkowych czynności jak ładowanie bibliotek so. Przegląd kodu kernela nie daje jednoznacznej odpowiedzi ponieważ istnieje wiele ścieżek prowadzących do ENOMEM. Najciekawsze funkcje pomocnicze to may_expand_vm, __vm_enough_memory i find_vma które sprawdzają różne limity więc trudno wskazać jednoznacznie przyczynę bez głębszej analizy.
Ale jedną rzecz łatwo zrobić – mamy już hipotezę o przekroczonym limicie mapowania pamięci, liczby potwierdzają nasze przypuszczenia – pozostał więc eksperyment do wykonania – zwiększmy ten limit i zobaczmy co się stanie:
# echo 100000 > /proc/sys/vm/max_map_count -------------------------------------------------- $ strace -c ./processing_pipeline 2 Running Experiment_2_thread_per_req Experiment interrupted - exception thrown: Resource temporarily unavailable Only 49983 threads created Waited 3990.99 ms, avg 25056.4 trans/sec % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 30.91 0.000887 0 50007 mmap 30.07 0.000863 0 49995 1 mprotect 19.06 0.000547 0 49983 clone 17.21 0.000494 0 49985 munmap 2.75 0.000079 0 5799 brk 0.00 0.000000 0 6 read 0.00 0.000000 0 8 write 0.00 0.000000 0 7 open 0.00 0.000000 0 7 close 0.00 0.000000 0 7 fstat 0.00 0.000000 0 3 lseek 0.00 0.000000 0 2 rt_sigaction 0.00 0.000000 0 1 rt_sigprocmask 0.00 0.000000 0 7 7 access 0.00 0.000000 0 1 execve 0.00 0.000000 0 1 getrlimit 0.00 0.000000 0 1 arch_prctl 0.00 0.000000 0 348 18 futex 0.00 0.000000 0 1 set_tid_address 0.00 0.000000 0 1 set_robust_list ------ ----------- ----------- --------- --------- ---------------- 100.00 0.002870 206170 26 total
Wyników chyba nie muszę komentować. Mamy przyczynę niepowodzenia. Jako ciekawostkę podam stos wywołań, który prowadzi do funkcji mprotect:
(gdb) bt #0 0x00007ffff7050777 in mprotect () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007ffff7bc24fa in allocate_stack (...) at allocatestack.c:649 #2 __pthread_create_2_1 (...) at pthread_create.c:539 #3 0x00007ffff78f0dc3 in std::thread::_M_start_thread(...) from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x000000000040eabe in std::thread::thread(...)... ... #8 0x0000000000404705 in Experiment_2_thread_per_req () at main.cpp:92 #9 0x00000000004058ce in main (argc=2, argv=0x7fffffffdcb8) at main.cpp:294
Więc co teraz? Możemy manipulować limitami ale jest to bardzo zła droga w tym przypadku. Nadmierna liczba wątków negatywnie wpływa na wydajność. Trzeba to jakoś ograniczyć programowo. Najprostsze podejście może wyglądać tak:
max_thread_limit = 100
while not done:
thread_num = 0
while thread_num < max_thread_limit:
request = 100k_requests.get_next()
create_thread(RequestProcessor::Process(request))
thread_num++
wait_for_all_threads()
Odpalmy więc nasz program i zobaczmy jakie korzyści daje nam wielowątkowość:
./processing_pipeline 3 Running Experiment_3_thread_per_req_with_throttle for 100 threads Control result: 6.49994e+10 Total sleep: 18920 ms, # yield: 49800, # requests: 100000 Waited 25767.7 ms, avg 3880.83 trans/sec
WTF??? Wynik gorszy niż w przypadku przetwarzania sekwencyjnego opisanego w poprzednim artykule! Dla przypomnienia:
$ ./processing_pipeline 1 Running Experiment_1_single_threaded Control result: 6.49994e+10 Total sleep: 18920 ms, # yield: 49800, # requests: 100000 Waited 23612.7 ms, avg 4235 trans/sec
Czyli teraz mamy ponad 25 sekund! Co z tą wielowątkowością?
Otóż powyższy przykład pokazuje jak nieumiejętne korzystanie z tego narzędzia przynosi więcej szkód niż pożytku. Celowo pokazałem jakie problemy z limitami możemy napotkać. Niestety często podczas testów możemy tych problemów nie zauważyć gdyż same limity są dość wysoko ustawione a analiza takich zdarzeń może być trudna. Jak zwykle poinformuje nas o problemach niespecjalnie szczęśliwy klient. Druga sprawa to ślepa wiara w sprawczą moc wielowątkowości. Nasze zrównoleglenie nie pomogło, a przynajmniej nie to naiwne podejście. W kolejnej części zobaczymy co poszło nie tak i gdzie jest problem. Zobaczymy też jak można usprawnić nasz algorytm aby wielowątkowość okazała się skuteczna.