Czy używasz przypadków, w których procesor i operacje wejścia / wyjścia mają inny priorytet?


9

Procesy Linuksa mogą mieć inny priorytet procesora i IO (ładne i jonowe).

Dlaczego trzeba mieć inny priorytet procesora i IO?

Czy istnieje jakiś rzeczywisty sposób wykorzystania ich różnych?

Jakie przypadki użycia w świecie rzeczywistym wymagają innego priorytetu procesora i IO? Jak wyższy niż normalny priorytet procesora, ale niższy niż normalny priorytet We / Wy lub odwrotnie.

Odpowiedzi:


6

Domyślne zachowanie „nice” polega na dostosowywaniu priorytetu aplikacji „io” również w przypadku zmiany dobroci.

Wszystko oczywiście zależy od obciążenia pracą, ale jednym z kluczowych aspektów każdego systemu operacyjnego jest to, w jaki sposób alokuje swoje zasoby i jak radzi sobie z rywalizacją .

W rzeczywistości ważne jest, aby zrozumieć, co robi licencja, ponieważ pod obciążeniem ze strony konkurujących procesów sposób działania systemu operacyjnego może mieć wpływ na resztę obciążenia.

Spór jest miarą rywalizacji różnych aplikacji o ten sam zasób (np. Procesor).

Obsługa ładunku

Od czasu wprowadzenia całkowicie uczciwego harmonogramu, nice jest jedynie nakładką na klauzulę „waga” każdego procesu. Które można zobaczyć w proc.

$ cat /proc/self/sched
---------------------------------------------------------
...
se.load.weight                     :                 1024
...

Zmiana dobroci jedynie zmienia ciężar:

$ nice -n 5 cat /proc/self/sched 
---------------------------------------------------------
...
se.load.weight                     :                 335
...

Miarą rywalizacji procesora jest całkowicie uczciwy algorytm szeregowania. Każdej aplikacji przypisywana jest wartość „wagi”, aw przypadku rywalizującego czasu procesora czas jest dzielony pomiędzy procesami poprzez zsumowanie całego przetwarzania rywalizującego o czas procesora i przypisanie im najniższego wspólnego czasu procesorowego nominału na podstawie ich wartości wagowej.

Jeśli mam 3 aplikacje, które chcą wykorzystać czas procesora, domyślnie otrzymują 1024 jako normalną wagę. Gdybym miał jeden proces z ładnym +5 jak wyżej, wszystkie trzy wagi byłyby sumowane na 2383, w ten sposób proces nicowania otrzymałby około 15% czasu procesora w danej sekundzie, gdyby wszystkie 3 procesy prosiły o procesor w tej sekundzie .

Dlaczego trzeba mieć inny priorytet procesora i IO?

Nicość tak naprawdę bawi się tym, co zrobić, gdy system jest obciążony, to znaczy - w jaki sposób system operacyjny skraca czas między konkurującymi procesami, zgodnie z wszelkimi niezbędnymi czynnikami.

To, jak wpływa to na ciebie lub jakie jest jego znaczenie, zależy od tego, jakie priorytety dostarczania mają ze sobą różne aplikacje, a także czas dostarczenia każdej aplikacji.

Nicość naprawdę robi coś tylko wtedy, gdy twój system jest obciążony (jest więcej rzeczy, które wymagają uwagi niż procesor lub dysk mogą obsłużyć). Po prostu instruuje jądro, jak przydzielić zasoby w takich okolicznościach.

Czy istnieje jakiś rzeczywisty sposób wykorzystania ich różnych?

Jeśli masz wiele konkurencyjnych procesów lub pracę do wykonania, która jest więcej niż może być wykonana przez procesor, niceness daje ci stosunkowo stabilne gwarancje co do tego, która praca zakończy się jako pierwsza. Może to być dla Ciebie ważne, jeśli powiesz, że tworzysz raport, który powinien zostać dostarczony przed zakończeniem kolejnego raportu.

W systemie stacjonarnym uprzywilejowanie może być jeszcze ważniejsze. Niektóre aplikacje działają w czasie rzeczywistym, dzięki czemu częstsze budzenie ich podczas ładowania zapobiega przedawnieniu danych. Pulseaudio należy na przykład do tej kategorii.

Inne aplikacje mogą być wymagane do rozdzielenia pracy dla aplikacji zależnych. Na przykład wiele żądań apache, aby powiedzieć, że serwer SQL, taki jak MySQL, może blokować się przez długi czas, ponieważ SQL nie jest wystarczająco szybki, ponieważ - powiedzmy, że inny raport konkuruje o czas procesora. Tak więc SQL nie tylko utknął w martwym punkcie, ale także Apache. SQL może tu czasem zaszkodzić, ponieważ zwykle jest o wiele mniej wątków roboczych niż wątki apache konkurujące jako grupa, które są ważone przez program planujący, dzięki czemu SQL daje więcej czasu procesora na wyrównanie.

UpdateDB (program indeksujący pliki) działa późno w nocy i jest bardzo obciążony. Przydatne może być zmniejszenie priorytetu planowania we / wy, aby inne aplikacje w tym czasie miały pierwszeństwo przed czymś, co nie jest tak ważne w kolejności rzeczy.

Jakie przypadki użycia w świecie rzeczywistym wymagają innego priorytetu procesora i IO?

Bardzo mało. Uprzejmość to zbyt wiele wysiłku. Zasadniczo mniej dbam o to, jak dobrze działają aplikacje, a bardziej o to, jak źle mogą działać. Na początku może to zabrzmieć wstecz, ale mam gwarancje świadczenia usług, które są dla mnie ważniejsze.

Chcę mieć pewność, że „twoje rzeczy, nawet w zły dzień, zostaną zrobione za X okresu”. Jeśli idzie szybciej, to tylko bonus.

Zazwyczaj zacznę od wygenerowania uzgodnionych specyfikacji, takich jak:

  • Każda aplikacja internetowa gwarantuje ukończenie żądań w 0,3 sekundy.
  • Wszystkie żądania SQL w systemie są gwarantowane w 0,1 sekundy.
  • Aplikacja internetowa powinna obsłużyć nie więcej niż 50 IOPS i zapewnia 1k plików.
  • Łącznie wielkość pamięci aplikacji internetowych nie przekracza 250 Mb.

I określ wymagania, które chcesz spełnić:

  • Wszystkie żądania internetowe powinny zostać zakończone w 0,05 sekundy.
  • Wszystkie żądania SQL powinny zostać zakończone w 0,02 sekundy.
  • Powinna być wystarczająca pamięć do obsługi wszystkich żądań.
  • Wymagania IO powinny być spełnione.

Podając specyfikacje są prawdziwe, osiągam te cele bez wirtualizacji, stosując znacznie bardziej wydajne podejście grup kontrolnych.

Grupy kontrolne pozwalają mi tworzyć dość niezawodne gwarancje poziomu usług dla alokacji zasobów, pod warunkiem, że aplikacja zachowuje się w określonych granicach. Oznacza to, że nawet w systemie pod obciążeniem mogę zagwarantować dostępność zasobów dla danej aplikacji i zagwarantować miejsce dla innych aplikacji na tym samym urządzeniu!

Jeśli weźmiemy twój przykład CPU i IO. Ustawiam limity, które spełniają te wymagania:

# cd /sys/fs/cgroup/blkio/apache
# echo "253:0 100" >blkio.throttle.read_iops_device 
# echo "253:0 50" >blkio.throttle.write_iops_device 
# echo "253:0 102400" >blkio.throttle.read_bps_device

Czyli 100 000 bajtów do odczytania ze 100 Iops.

# cd /sys/fs/cgroup/cpu/apache
# echo 1000000 >cpu.cfs_period_us
# echo 60000 >cpu.cfs_quota_us 

Z 1-sekundowego przedziału czasowego daj 0,06 sekundy procesora.

# cd /sys/fs/cgroup/cpu/sql
# echo 1000000 >cpu.cfs_period_us
# echo 20000 >cpu.cfs_quota_us

Z 1-sekundowego przedziału czasowego daj 0,02 sekundy procesora.

Zapewnienie innym konkurencyjnym grupom nic niemądrego, bycie obciążonym jest mniej ważnym czynnikiem w świadczeniu usług, ponieważ wiem, jak procesor jest wyrzucany dla każdej aplikacji.

Grupy kontrolne tego rodzaju są nadal najlepszym wysiłkiem, ale oferują znacznie większą kontrolę nad tym wysiłkiem niż dobroć i jonowość.


Pytałem o potrzebę różnych priorytetów CPU i IO. Mówisz, że istnieje „bardzo niewiele” przypadków użycia, w których znalazłeś potrzebę posiadania innego priorytetu procesora i IO. Czy mógłbyś je odnieść?
Eduardo
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.