Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!

Ogłoszenie

Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.

#1  2017-04-25 13:06:34

  xseverus - Nowy użytkownik

xseverus
Nowy użytkownik
Zarejestrowany: 2017-04-25

cgroups, burst resources

Cześć,

Jest jakiś łatwy sposób, aby tymczasowo podnieść zasoby z cgroup (burst)? Powiedzmy, że proces ma ograniczone 20% CPU i ma możliwość zrobienia bursta na powiedzmy 30 sekund, aby mógł użyć 100%.

Ewentualnie czy jest jakaś funkcja / opcja, która informowałaby mnie że proces zużywa wszystkie zasoby? Wtedy po prostu przeniósłbym go do innej cgroupy na te 30 sekund, która ma dozwolone zużycie 100%, a po tym czasie przeniósł bym proces z powrotem.

Offline

 

#2  2017-04-25 15:01:38

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: cgroups, burst resources

Tak robi przecież, z tym, że nie przez 30s ale do momentu, aż inny proces będzie chciał swoją działkę. Niewykorzystany procek się marnuje.

Offline

 

#3  2017-04-26 13:47:40

  xseverus - Nowy użytkownik

xseverus
Nowy użytkownik
Zarejestrowany: 2017-04-25

Re: cgroups, burst resources

Chodzi mi o to, aby ograniczyć zużycie CPU na powiedzmy 20% per proces, a nie per grupa. Bo per grupa ograniczamy powiedzmy 20% jednego CPU w ten sposób:

echo 10000 > cpu.cfs.quota_us
echo 50000 > cpu.cfs_period_us

I wtedy jak "nie ma konkurencji" to jeden proces może zająć całe 20%, ale kiedy powiedzmy odpalimy drugi to wtedy oba rozdzielone są po 10%.

A mi chodzi o to, aby ustawić limit 20% per proces, ale jeśli jest taka możliwość to aby osiągnął w burście np 100%. Czyli jeśli jest możliwość niech sobie skacze na 100, ale kiedy inne procesy zaczynają mocniej pracować to aby wszystko było rozłożone na 20%. Chodzi, aby jeden proces nie zająć całego CPU dłużej niż na jakiś krótki burst.

Offline

 

#4  2017-04-26 15:47:01

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: cgroups, burst resources

A jak nie ma konkurencji to co powstrzymuje cię przed daniem temu procesowi nawet 100% zasobów proca?

Offline

 

#5  2017-04-27 10:05:53

  xseverus - Nowy użytkownik

xseverus
Nowy użytkownik
Zarejestrowany: 2017-04-25

Re: cgroups, burst resources

Okej, powiedzmy, że tych procesów będzie bardzo, bardzo dużo. Chciałbym, aby żaden z nich nie zajął zbyt wielu zasobów na dłużej niż powiedzmy te 30 sekund.

Czyli każdy proces ma do dyspozycji stale powiedzmy 20%. Ale ja mu umożliwiam burst (albo stały, że jak inne procesy zużywają mało to on niech sobie pracuje na ile chce, albo "wymuszony" przeze mnie na te 30 sekund).

Chyba nie do końca wiem jak to zrobić, bo jak ustawię w cgroupie tak jak pokazałem powyżej 1CPU na 20% to wtedy wszystkie procesy mają dostęp tylko do tych 20%. A ja chciałbym ustawić te 20% per proces z możliwością burstu.

Mam nadzieję, że teraz mnie rozumiesz :) (dzięki za to, że pomagasz! )

Offline

 

#6  2017-04-27 11:55:08

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: cgroups, burst resources

[quote=xseverus]Okej, powiedzmy, że tych procesów będzie bardzo, bardzo dużo. Chciałbym, aby żaden z nich nie zajął zbyt wielu zasobów na dłużej niż powiedzmy te 30 sekund.[/quote]
Widzę, że się nie rozumiemy. xD Jeśli masz tych procesów bardzo dużo i mają one ustalony przydział, to w ramach polityki, zasoby będą im rozdzielane w zależności jak to sobie skonfigurujesz ale pod warunkiem, że procek będzie operował na 100% i jego zasoby będą na wyczerpaniu. Jeśli teraz procek będzie miał powiedzmy 30% zużycia, to co ty też tutaj jeszcze ograniczać, skoro system ma dość mocy by wszystkie procesy utylizowały tyle zasobów ile każdy z nich potrzebuje? xD Więc jeśli jeden proces z tej całej masy będzie chciał 90% procka w danej chwili, a wszystkie pozostałe zamkną się w 5%, to ten żarłoczny proces naturalnie pociągnie te 90% mimo, że ma ustawiony przydział powiedzmy 20%. Natomiast jak te pozostałe procesy zaczną mieć większy apetyt na procesor, to automatycznie ten główny żarłok zostanie przycięty do 80...50...30 i 20% i poniżej tego progu nie spadnie, bo polityka na to nie zezwoli. Oczywiście to jest bardzo duże uproszenie ale obrazowo to tak wygląda.

Offline

 

#7  2017-04-27 12:24:45

  xseverus - Nowy użytkownik

xseverus
Nowy użytkownik
Zarejestrowany: 2017-04-25

Re: cgroups, burst resources

Czyli wystarczy, że ustawię w cgroupie wszystkie rdzenie i 100% CPU i wtedy zasoby będą równo rozdzielane? Jak to w takim razie zrobić?

Ostatnio edytowany przez xseverus (2017-04-27 12:38:00)

Offline

 

#8  2017-04-27 12:56:07

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: cgroups, burst resources

Ale co znaczy równo? Pokażę ci to na przykładzie. Masz Apache2 vs jakiś skrypt i obie te rzeczy konkurują o dostęp do procka, a sam procek działa na 100% mocy. Powiedzmy, że priorytetem jest wykonywanie się skryptu.

Przy braku limitowania via cgroups, Apache2 zdusi prawdopodobnie ten skrypt, bo proces Apache2 ma całą masę wątków, które będą jednakowo konkurować o dostęp do proca, podobnie jak to będzie robił sam skrypt. W efekcie będziesz miał np. 99 wątków Apache2 i 1 wątek skryptu, przez co prawie cały przydział procesora zostanie przeznaczony dla Apache2, a nie dla tego skryptu, który chcemy, by się jak najszybciej wykonał -- takie rozwiązanie ssie i po to się stosuje cgroups.

Limitując zasoby proca via cgroups możesz sobie zdefiniować dajmy na to proporcje 50:50 dla Apache2 i dla skryptu. I ile procesora w takim przypadku dostanie skrypt a ile Apache2? No 50% max pójdzie na Apache2 bez względu ile on sobie tam wątków odpali oraz 50% pójdzie na skrypt mimo, że ma on tylko jeden wątek. I tu jest właśnie zauważany boost.

Oczywiście jak skrypt się wykona i zużycie proca za jego sprawą spadnie do 0, to Apache dostanie te wolne 50% i będzie mógł wykorzystać 100% do czasu aż znów skrypt się uruchomi i będzie chciał swój przydział. I tak w kółko. Pomijam tu celowo pozostałe procesy.

Idąc dalej tam są jeszcze wagi do określenia, czyli gdy masz bardziej złożoną politykę przydziału (wiele różnych procesów) to rzadko się zdarzy tak, że wszystkie z tych procesów będą aktywne w tym samym czasie i część mocy proca zawsze będzie wolna. I tę wolną moc można rozdzielić w proporcjach, np. by 80% wolnej mocy proca poszło na jeden proces, itp. oczywiście znów przy założeniu, że ten proces chce wykorzystywać zasoby ponad swój limit.

Ostatnio edytowany przez morfik (2017-04-27 12:58:09)

Offline

 

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
Nas ludzie lubią po prostu, a nie klikając w przyciski ;-)

[ Generated in 0.010 seconds, 11 queries executed ]

Informacje debugowania

Time (s) Query
0.00009 SET CHARSET latin2
0.00004 SET NAMES latin2
0.00118 SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.116.85.204' WHERE u.id=1
0.00071 REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '18.116.85.204', 1732813072)
0.00065 SELECT * FROM punbb_online WHERE logged<1732812772
0.00055 SELECT topic_id FROM punbb_posts WHERE id=310401
0.00138 SELECT id FROM punbb_posts WHERE topic_id=29527 ORDER BY posted
0.00080 SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=29527 AND t.moved_to IS NULL
0.00017 SELECT search_for, replace_with FROM punbb_censoring
0.00134 SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=29527 ORDER BY p.id LIMIT 0,25
0.00092 UPDATE punbb_topics SET num_views=num_views+1 WHERE id=29527
Total query time: 0.00783 s