Optymalna liczba procesów jednorożca na procesor

Korzystamy z aplikacji internetowej Ruby on Rails pod Unicorn. Nasza aplikacja nie jest ściśle związana z procesorem (mamy podwójny system Xeon E5645 z 12 rdzeniami, a średnia wartość obciążenia szczytowego wynosi około 6). Zaczęliśmy od 40 pracowników Unicorn, ale z czasem zwiększyło się zużycie pamięci aplikacji. Tak więc teraz musimy zmniejszyć liczbę procesów roboczych. Myślałem, że standardowa formuła (liczba rdzeni procesora + 1) dotyczy również Unicorn, ale mój kolega próbował mnie przekonać, że powinniśmy zarezerwować więcej instancji Unicorn na procesor i podał ten link . Jednak nie jestem do końca pewien, dlaczego musimy poświęcać tyle pamięci na bezczynne procesy Unicorn.

Moje pytanie brzmi: jaki jest powód posiadania więcej niż jednej instancji Unicorn na rdzeń procesora? Czy jest to spowodowane jakąś osobliwością architektoniczną Jednorożca? Wiem, że zajęte procesy Unicorn nie mogą akceptować nowych połączeń (używamy gniazd domeny UNIX do komunikacji z instancjami Unicorn BTW), ale myślałem, że zaległości zostały wprowadzone właśnie w celu rozwiązania tego problemu. Czy można mimo to pokonać 2 do 8 instancji Unicorn na regułę procesora?

Dobra, w końcu znalazłem odpowiedź. Optymalna liczba pracowników Unicorn nie jest bezpośrednio związana z liczbą rdzeni procesora, zależy to od obciążenia i wewnętrznej struktury / reakcji aplikacji. Zasadniczo używamy profilowania próbkowania do określania stanu pracowników, staramy się utrzymać pracowników w 70% bezczynności i 30% w rzeczywistej pracy. Tak więc 70% próbek powinno „czekać na wywołanie select (), aby otrzymać żądanie z serwera frontonu”. Nasze badania wykazały, że istnieją tylko 3 skuteczne stany pracowników: 0-30% próbek jest bezczynnych, 30-50% próbek jest bezczynnych, a 50-70% próbek jest bezczynnych (tak, możemy uzyskać więcej bezczynnych próbek, ale tam nie ma w tym sensu, ponieważ czas reakcji aplikacji nie zmienia się znacząco) Uważamy 0-30% sytuacji za „strefę czerwoną”, a 30-50% sytuacji za „strefę żółtą”.

Masz rację co do N + 1 dla zadań związanych z procesorem.

Z drugiej strony jednorożec nie używa nici, więc każde IO op. blokuje proces, a inny proces może uruchamiać i analizować nagłówki HTTP, łączyć łańcuchy i wykonywać wszystkie zadania wymagające dużej mocy obliczeniowej, aby obsłużyć użytkownika (robienie tego wcześniej, aby zmniejszyć opóźnienie żądania).

I możesz chcieć mieć więcej wątków / procesów niż rdzeni. Wyobraź sobie następującą sytuację: wym. A zajmuje dziesięć razy więcej niż wymagania. B, masz kilka współbieżnych żądań A, a szybkie żądanie B jest właśnie kolejkowane w oczekiwaniu na zakończenie żądania A-req. Jeśli więc potrafisz przewidzieć liczbę ciężkich żądań, możesz użyć tego numeru jako innej wytycznej do dostrojenia systemu.