Forum Debian Users Gang

Gryzon · 2009-03-04 16:02:14

Witam serdecznie,

mam dwa pytanie, dział Kernel wydaje mi się być najbardziej trafnym

1. czy jest szansa aby sprawdzić na którzy jądrze procesora działa dany proces? Jeżeli tak to w jaki sposób, jakich narzędzi użyć.
2. Jak najlepiej rozwiązać sprawę żąglowania procesami między jądrami. Wydaje mi się że właśnie ten moment powoduje u mnie problemy. Zastanawiam się w jaki sposób można statycznie definiować na którym jądrze ma działać dany proces.

Z góry bardzo dziękuje za wszelką pomoc.

bercik · 2009-03-05 00:03:06

wyswietlenie numeru procesora (rdzenie sa dal systemu widziane jako procesory) do ktorego jest przypisane i na ktorym sie wykonuje zadanie:

Kod:

ps -A -O psr,sgi_p

zobacz takze

Kod:

man 2 getcpu
man 3 sched_getcpu

Gryzon · 2009-03-05 10:52:52

Dziękuje bercik za odpowiedź, teraz już wiem jak odczytywać te informacje.

Niestety kernel przeżuca mi proces między procesorami jak szalony, a nie jest to dla mnie porządana sytuacja.

Chciałbym tak zmodyfikować kernel lub zrobić "coś" aby uruchomiony proces siedział od początku na jednym procesorze i aby nie ulegało to zmianie.

Z góry bardzo dziękuje za okazaną pomoc.

bercik · 2009-03-05 13:48:16

nie wiem czy jest jakis programik ktory to zalatwia, ale jest funkcja systemowa [tt]sched_setaffinity[/tt] (wiecej szczegulow w man) ... mozesz jej uzyc w swoim programie lub napisac jakiegos wrapperka co ja wykona i zrobi exec na wskazy program ... poczytaj tez podowiazywane strony man (np. o cpuset)

Gryzon · 2009-03-05 15:05:01

Troche inaczej sprawa teraz wygląda, niestety ustawienie procesu na odpowiednim rdzeniu nie do końca rozwiązuje mój problem.

Chciałem zmienić w pliku jądra kernel/sched.c następujące parametry:

#define MIN_TIMESLICE (10000 * HZ / 1000)
#define MAX_TIMESLICE (30000 * HZ / 1000)

#define DEF_TIMESLICE (100 * HZ / 1000)

według informacji które wyczytałem w takiej konfiguracji schedule`r powinien żadziej "żąglować" procesami, niestety po kompilacji nadaj procesu latają jak szalone między procesorami. Możliwe że pozostawienie wartości DEF_TIMESLICE na domyślnej jest problemem, za chwilę będe to testował.

Ale chętnie bym poznał opinię i wskazówki innych.

bercik · 2009-03-05 15:09:37

moze opisz dokladnie na czym polega ten problem - co to za proces jakie nieprawidlowe dzialanie jest spowodowane tym rzaglowaniem, i dlaczego ustawienie na odpowiednim rdzeniu nie rozwiazuje problemu (a wlasciwie jaki jest ten problem) ... bo na takim poziomie ogolnosci to trudno o jakies rady praktyczne jak zwalczyc ten problem ...

Gryzon · 2009-03-05 15:32:37

Więc tak, dokładnie to chodzi o serwery gier.

W momencie gdy proces jest przerzucany miedzy procesorami, na serwerze gry pojawiają się skoki pingów, co nie jest lubiane przez graczy.

Chciałbym zmniejszyć częstotliwość tych przełączeń aby te skoki były rzadsze, dlatego próbowałem zmieniać parametry w kernel/sched.c

Niestety uruchomienie na konkretnym rdzeniu nie jest rozwiązaniem ponieważ musiał bym sam pilnować obciążenia procesorów, a przy ilości procesów liczonych w dziesiątkach nie bardzo jest to możliwe.

Pisanie programów do zarządzania też mija się z celem bo musiał bym napisać nowego scheduler`a, a po co skoro jeden już jest w kernelu.

lis6502 · 2009-03-05 15:36:01

Nie jestem jakoś przekonany że akurat 'moment przerzucania' ma jakikolwiek wpływ na wydajność samego programu. Po to mamy kernel by nie musieć się martwić o takie rzeczy. Spróbuj zmniejszyć priorytet programowi gry, a najlepiej opisz co tam jeszcze chodzi na tym serwerze (jakiś apacz, ftp?)

Gryzon · 2009-03-05 15:39:57

Niestety gracze są bardzo marudnymi stworzeniami i skoki pingów o wartość kilku ms, jest dla nich już wielkim problemem.
Chodź nie zaobserwowałem aby miało to jakiś wpływ na samą gre, ale moje zdanie jest nie ważne.

Jestem niemal pewny że ma to związek z przerzucaniem między procesorami, jest to oparte na wielu obserwacjach.

Oprócz serwerów gier działa tam httpd oraz proftpd

lis6502 · 2009-03-05 15:46:36

Wiem jacy są gracze bo ja umiem o 23 zadzwonić do isp narzekając na pingi powyżej 300 xD. Gdyby na prawdę rozdzielanie obciążenia między rdzenie miało obniżać wydajność danego programu, to jaki sens byłby kupować nrdzeniowe procesory? Z doświadczenia na kimsufich wiem ,że demon ftp potrafi zeżrzeć 100% cpu, wszystko zależy od prędkości i liczby połączeń. Zaloguj się tam na roota, odpal top'a, zmień odświeżanie (przycisk 's') na jakieś krótsze, np 0.2 s i popatrz co oprócz procesu gry ma taki apetyt na moc. jest jeszcze program [b]htop[/b], tylko że on pokazuje obciążenia poszczególnych rdzeni.

bercik · 2009-03-05 15:47:11

nie napisales tez dlaczego sched_setaffinity nie rozwiazuje problemu skoro jest nim przerzucanie pomiedzy CPU

jezeli zwykle niceowanie takiego procesu nie pomaga moze sproboj dac mu priorytet czasu rzeczywistego ... w zasadzie jezeli nie jest to proces wielowatkowy to mozesz mu okreslic jedno CPU i jakis wysoki priorytet RT ... o priorytetach RT masz w http://www.opcode.eu.org/c_cpp/priorytety.c/

Gryzon · 2009-03-05 15:53:37

kimsufich :) Nie przepadam :)

Co do zakupu wielordzeniowych procesorów to oczywiście jest sens, jeżeli uruchamiane aplikacje obsługują wiele procesorów, niestety serwery niektórych gier mają już po kilka lat i nie były pisane i kompilowane pod wiele procesorów.

Dziekuje za lekcie obsługi top`a, ale sprawdzanie za pomocą tego narzędzia mam już za sobą. :)
Daemon`y oczywiście potrafią zajmować 100% rdzenia, ale nie ma to tutaj żadnego znaczenia.

W temacie nie chodzi o zbyt duże obciążenie maszyn, ale o to aby kernel rzadziej dokonywał przełączeń między rdzeniami. Dokładnie chodzi o zwiększenie kwantu czasu jaki schedul`er daje wątkowi.

BTW. top też może pokazywać obciążenia poszczególnych rdzeni :)

Time (s)	Query
0.00009	SET CHARSET latin2
0.00004	SET NAMES latin2
0.00121	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='3.147.89.50' WHERE u.id=1
0.00084	REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.147.89.50', 1732301283)
0.00052	SELECT * FROM punbb_online WHERE logged<1732300983
0.00022	SELECT topic_id FROM punbb_posts WHERE id=112927
0.00025	SELECT id FROM punbb_posts WHERE topic_id=13609 ORDER BY posted
0.00029	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=13609 AND t.moved_to IS NULL
0.00021	SELECT search_for, replace_with FROM punbb_censoring
0.00158	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=13609 ORDER BY p.id LIMIT 0,25
0.00111	UPDATE punbb_topics SET num_views=num_views+1 WHERE id=13609
Total query time: 0.00636 s

Forum Debian Users Gang

Ogłoszenie

#1 2009-03-04 16:02:14

Gryzon - Użytkownik

Na jakim jądrze działa proces

#2 2009-03-05 00:03:06

bercik - Moderator Mamut

Re: Na jakim jądrze działa proces

Kod:

Kod:

#3 2009-03-05 10:52:52

Gryzon - Użytkownik

Re: Na jakim jądrze działa proces

#4 2009-03-05 13:48:16

bercik - Moderator Mamut

Re: Na jakim jądrze działa proces

#5 2009-03-05 15:05:01

Gryzon - Użytkownik

Re: Na jakim jądrze działa proces

#6 2009-03-05 15:09:37

bercik - Moderator Mamut

Re: Na jakim jądrze działa proces

#7 2009-03-05 15:32:37

Gryzon - Użytkownik

Re: Na jakim jądrze działa proces

#8 2009-03-05 15:36:01

lis6502 - Łowca lamerów

Re: Na jakim jądrze działa proces

#9 2009-03-05 15:39:57

Gryzon - Użytkownik

Re: Na jakim jądrze działa proces

#10 2009-03-05 15:46:36

lis6502 - Łowca lamerów

Re: Na jakim jądrze działa proces

#11 2009-03-05 15:47:11

bercik - Moderator Mamut

Re: Na jakim jądrze działa proces

#12 2009-03-05 15:53:37

Gryzon - Użytkownik

Re: Na jakim jądrze działa proces

Stopka forum

Informacje debugowania