Load

[Linux 0]

Witam, czy load 3 to już dużo jeżeli chodzi o serwer? Nie mówię tutaj o serwerze który jest głównie używany do usług WWW tylko do gier (maszyna słaba )

 

Cpu skacze od 15 do 25%

Ram stabilnie - 60% wolnego.

 

Load jednak skacze od 1.5 do 3.0

 

Jest się czym martwić?

 

Jaka jest górna granica loadu przy której będzie się trudno zalogować na serwer?

 

p.s wielkie dzięki za pomoc.

 

///edit myślę że już przy loadzie 20 (stałym a nie chwilowym będzie nie możliwe zalogowanie na ssh (czyt będzie trwało dłuugo )

 

Aktualnie nie boje się że dostane load 20 bo panuje nad serwerem tylko chciałem się zorientować jak to wygląda ( jakie średnie itp )

[patryk 451]

A jaki masz procesor? Linux, *BSD? Kernel z paczki czy self made? Generalnie load 3.0 to nic _aż tak_ strasznego. Dobrze skonfigurowany system pozwoli się na siebie wbić nawet przy loadzie rzędu 100, potrwa to jedynie dłużej niż zazwyczaj..

[MasterNETpl 100]

Przy lodzie na poziomie 3.00 nie masz się jeszcze aż tak co martwić... gorzej jak już będzie dochodzić do dychy nie mówiąc oczywiście o loadzie generowanym przez iowait'a

 

Obserwuj po prostu co najbardziej generuje load i dopiero wtedy możesz podejmować odpowiednie kroki.

[T 6]

Witam, czy load 3 to już dużo jeżeli chodzi o serwer? Nie mówię tutaj o serwerze który jest głównie używany do usług WWW tylko do gier (maszyna słaba )

 

Cpu skacze od 15 do 25%

Ram stabilnie - 60% wolnego.

 

Load jednak skacze od 1.5 do 3.0

Generalnie taki load nie jest niczym strasznym. Ale odpal `top` i popatrz na "%wa" (waiting for i/o). Jeśli jest sporo, to zazwyczaj dyski nie wyrabiają. Wtedy moze pomóc np. zwiększenie cache w pamieci operacyjnej którejś z uruchomionych usług.

[pleple 0]

///edit myślę że już przy loadzie 20 (stałym a nie chwilowym będzie nie możliwe zalogowanie na ssh (czyt będzie trwało dłuugo )

To dość dziwne. Pamiętam, że raz na serwerze pocztowym, który debugowałem zrobiło się niezłe wąskie gardło i load przez kilkadziesiat minut utzymywał się na poziomi kilkuset. Nie miałem problemu z połączeniem się przez SSH. Serwer nie był zbyt świetny ale też nie za słaby (1 GB RAM, procesor jednordzeniowy). O, mam nawet zapisane konkretne wartości jakie były:

load average: 1001.19, 646.91, 302.05

 

Było to zmierzone z poziomu SSH. Taki load jest oczywiście zły ale nie trzeba się raczej martwić o brak łączności z maszyną. Oczywiście zależy to też od tego co powoduje ten load...

[Linux 0]

Odpowiadam na pytania

 

733MHZ

256RAM

10GB

(Serwer z ND )

 

Ale właśnie będę im wysyłał maila z pytaniem czy jest możliwy uprg do większego planu bo niedługo skończą mi się zasoby

 

Linux Debian - Kernel nie kompilowany przeze mnie.

 

Teraz load utrzymuje się poniżej 1dnego (skacze max do 1,5)

 

T, używam htopa ale on nic groźnego nie widzi

Dysk raczej jest ok bo praktycznie nie używany a z większych operacji to zapisuje logi z systemu i serwerów gier ^^

 

Danke for help

[jarek 4]

a jaka gra ? ;]

[Linux 0]

Wysłałem na PM z pewnych powodów

[malu 460]

Jak na serwer gier to jest dobry normalny load

[Linux 0]

Ciii...- dziś miałem 16 xD ale się ustabilizowało. Spoko - to nie typowy serwer gier zjadający 50mhz na slot (gry typu CS) - jest tam wiele serwerów gier i jeden ts

Po-za-tym problem nie aktualny bo pod koniec miesiąca przenoszę się na 60% lepszy serwer ;]

 

/PS - Dane z pierwszego postu nie aktualne - aktualnie cpu 80-90 (dlatego zmieniam serwer)

[webadmin 0]

sa hostingi z loadem 30-40 i sobie radza ;d

[malu 460]

^^ np. yoyo.pl , jednak przepraszam za offtop !

[Linux 0]

Haha! Spamerzy! Pokaże ten temat adminowi jojo i będziecie mieli lipe! Przeczyści Wam tak mózgi jak gamepad czyści codziennie swoje serwery zbędnej pamięci ram

[Linux 0]

Odświeżam z 2ma pytaniami:

 

Czy jeżeli mam większość procesów (90%) uruchomione na jednym userze to wpływa to znacząco na load?

 

Czy jakość sprzętu (cache w procesorze,dysku,taktowanie pamięci itp.. ) znacząco wpływa na loadavg?

[pleple 0]

Czy jeżeli mam większość procesów (90%) uruchomione na jednym userze to wpływa to znacząco na load?

Nie. Load jest parametrem globalnym dla całego systemu.

 

Czy jakość sprzętu (cache w procesorze,dysku,taktowanie pamięci itp.. ) znacząco wpływa na loadavg?

W pewnym sensie loadavg jest funkcją zależną od "jakości sprzętu". To właśnie ona decyduje o tym jak szybko może dany proces zakończyć swoje działanie a im dłużej ten działa tym większy loadavg generuje.

 

Zobacz mój post w tym temacie żeby dowiedzieć się czym dokładnie jest load avarage:

http://www.webhostingtalk.pl/index.php?showtopic=9526

[alien 345]

Na loadavg (czyli czynnik zalezny od ilosci procesow, ktore Z ROZMAITYCH POWODOW czekaja na czas procesora) nie ma znaczenia to kto uruchomil dany proces, ale charakter tych procesow - jaka jest ich zasobozernosc, z jaka intensywnoscia korzystaja z procesora, a w jakim z dyskow lub innych zasobow, jak dlugotrwale jest obciazenie. Im wiecej procesow i im wyzsza ich zapotrzebowanie na procesor, tym loadavg wyzszy. Nie ma prost znaczenia kto jest wlascicielem procesow, poza oczywiscie ewentualnym wplywem wlasciciela na priorytetyzowanie procesow.

 

Oczywiscie jakosc sprzetu ma wplyw na loadavg, przy czym parametr ten dotyczy wprost procesora, czyli scislej to szybkosc procesora (ktora jest wypadkowa czynnikow takich jak taktowanie, cache, szybkosc cache) ma wplyw na parametr loadavg. Im lepszy procesor, tym loadavg przy tych samych procesach nizszy.

 

Choc loadavg bedzie sie tez podnosic przy innego rodzaju "hamulcowych" w systemie (np. dyski), jednak w tym przypadku wzrostem loadavg nie nalezy sie przejmowac jako takim, a szukac innych parametrow opisujacych podejrzewane czynniki i to na nich koncentrowac uwage.

[pleple 0]

scislej to szybkosc procesora (ktora jest wypadkowa czynnikow takich jak taktowanie, cache, szybkosc cache) ma wplyw na parametr loadavg.

To tylko jedna ze składowych. Istotna jest też szybkość pamięci, szybkość magistrali itp (należy też zauważyć, że szybkość działania poszczególnych komponentów jest ze sobą powiązana). Load avarage jest takim dziwnym wskaźnikiem, który w prost zależy od długości kolejki procesów planisty. Mówiąc prościej, load avarage jest tym niższy im więcej czasu procesy śpią.

[alien 345]

@pleple No tak, ale pamiec i magistrala to czynniki wplywajace wprost na szybkosc procesora, poprzez wydajnosc systemu ogolna. Zauwaz, ze tu zaczynamy przekraczac plynna granice tego gdzie mowimy o szybkosci procesora jako takiego, a gdzie o wydajnosci systemu. Generalnie jesli procesor relatywnie zbyt czesto korzysta z pamieci operacyjnej (kwestia wzgledna, zalezna od wykonywanych operacji), to nalezy zastanowic sie czy jest to procesor z odpowiednio duzym cache L1, L2. RAM nie powinien stanowic bezposredniego wsparcia dla procesora.

 

Oczywiscie szybkosc dzialania systemu ogolnie tez ma wplyw na loadavg, o czym pisalem w ostatnim akapicie.

 

Co do ostatniego zdania. Jestes pewien, ze im wiecej spi, tym nizszy loadavg? AFAIK procesy spiace takze doliczaja sie do loadavg, poniewaz loadavg dotyczy nie tylko kolejki procesow aktywnych, ale takze spiacych, np. czekajacych na otrzymanie okreslonego zasobu, czekajacych w kolejce dla okreslonych semaforow. W tym aspekcie procesy spiace sa wliczane do loadavg i wplywaja na jego wzrost. Ale przyznam, ze nie wgryzalem sie nigdy w przedstawiony algorytm z sched.c, jak zwykle wiec zastrzegam sobie prawo do bledu ;-).

[pleple 0]

@pleple No tak, ale pamiec i magistrala to czynniki wplywajace wprost na szybkosc procesora, poprzez wydajnosc systemu ogolna.

Według mnie nie zupełnie. Przy stałej szybkości magistrali oraz pamięci, procesor może być szybszy lub wolniejszy. Przyspieszenie działania pamięci bądź magistrali nie przyspieszy znów działania procesora. Kiedy trzeba współpracować, wtedy oczywiście (jak wspomniałem i ja i Ty) wszystkie współpracujące części mają wpływ na szybkość działania systemu (ale nie jest to wpływ wprost).

 

 

Tu zaczynamy przekraczac plynna granice tego gdzie mowimy o szybkosci procesora jako takiego, a gdzie o wydajnosci systemu. Generalnie jesli procesor relatywnie zbyt czesto korzysta z pamieci operacyjnej, to nalezy zastanowic sie czy jest to procesor z odpowiednio duzym cache L1, L2. RAM nie powinien stanowic bezposredniego wsparcia dla procesora.

W dzisiejszych czasach żaden procesor (przynajmniej z takich dostępnych śmiertelnikom) nie ma odpowiednio dużego cache, według Twojej definicji:) Cache opiera się na zasadzie lokalności (czasowej i przestrzennej) zasobów, ma ograniczyć odwołania do pamięci z podobnego obszaru w ciągu pewnego (niezbyt długiego) okresu czasu (żeby np móc przechować w cache kontekst procesu i najważniejsze dane z jakich korzysta podczas jego działania). W przypadku systemów wielozadaniowych ogólnego przeznaczenia nie da się jednak uniknąć ciągłego skakania po obszarach pamięci a ilość cache jaką posiadamy jest średnio 100-1000 razy większa niż ilość pamięci operacyjnej jaka jest używana przez system. Tak więc procesor zasadniczo mamy o dwa rzędy wielkości za mało cache, żeby procesor mógł relatywnie rzadko odwoływać się do pamięci i żeby pamięć ta nie była bezpośrednim wsparciem dla procesora Inna sprawa, że to kłóciłoby się z zasadą działania cache...

 

Oczywiscie szybkosc dzialania systemu ogolnie tez ma wplyw na loadavg, o czym pisalem w ostatnim akapicie.

Ale chyba dopiero po wyedytowaniu więc przed tym jak ja zacząłem odpowiadać.

 

Co do ostatniego zdania. Jestes pewien, ze im wiecej spi, tym nizszy loadavg?

Tak. To jest makro liczące:

 

#define CALC_LOAD(load,exp,n) \
load *= exp; \
load += n*(FIXED_1-exp); \
load >>= FSHIFT

 

A tak jest używane:

static inline void calc_load(unsigned long ticks)
{
unsigned long active_tasks; /* fixed-point */
static int count = LOAD_FREQ;

count -= ticks;
if (unlikely(count < 0)) {
active_tasks = count_active_tasks();
do {
CALC_LOAD(avenrun[0], EXP_1, active_tasks);
....

 

Tutaj jest definicja count_active_tasks() (z kernel/timer.c):

static unsigned long count_active_tasks(void)
{
	 return nr_active() * FIXED_1;
}

 

FIXED_1 to po prostu 1.0 w IEE754, a nr_active jest zdefiniowane w kernel/sched.c:

unsigned long nr_active(void)
{
	 unsigned long i, running = 0, uninterruptible = 0;

	 for_each_online_cpu(i) {
			running += cpu_rq(i)->nr_running;
			uninterruptible += cpu_rq(i)->nr_uninterruptible;
	 }

	 if (unlikely((long)uninterruptible < 0))
			uninterruptible = 0;

	 return running + uninterruptible;
}

 

Tak więc wliczają się tylko aktywne i nieprzerywalne. Jakbyś miał wątpliwości to w kernel/sched.c jest zdefiniowanych trochę innych niż nr_uninterupatble i nr_running (jest np nr_iowait czy nr_context_switches, które jak widać nie są wliczane.

[alien 345]

Według mnie nie zupełnie. Przy stałej szybkości magistrali oraz pamięci, procesor może być szybszy lub wolniejszy. Przyspieszenie działania pamięci bądź magistrali nie przyspieszy znów działania procesora. Kiedy trzeba współpracować, wtedy oczywiście (jak wspomniałem i ja i Ty) wszystkie współpracujące części mają wpływ na szybkość działania systemu (ale nie jest to wpływ wprost).

OK, okreslenie "wprost" bylo na wyrost, z reszta to raczej przypadkowy wtret :-). Ale co do meritum sie zgadzamy.

W dzisiejszych czasach żaden procesor (przynajmniej z takich dostępnych śmiertelnikom) nie ma odpowiednio dużego cache, według Twojej definicji:) Cache opiera się na zasadzie lokalności (czasowej i przestrzennej) zasobów, ma ograniczyć odwołania do pamięci z podobnego obszaru w ciągu pewnego (niezbyt długiego) okresu czasu (żeby np móc przechować w cache kontekst procesu i najważniejsze dane z jakich korzysta podczas jego działania). W przypadku systemów wielozadaniowych ogólnego przeznaczenia nie da się jednak uniknąć ciągłego skakania po obszarach pamięci a ilość cache jaką posiadamy jest średnio 100-1000 razy większa niż ilość pamięci operacyjnej jaka jest używana przez system.

100-1000 razy mniejsza oczywiscie :-)

Tak więc procesor zasadniczo mamy o dwa rzędy wielkości za mało cache, żeby procesor mógł relatywnie rzadko odwoływać się do pamięci i żeby pamięć ta nie była bezpośrednim wsparciem dla procesora Inna sprawa, że to kłóciłoby się z zasadą działania cache...

No tak, ja tam dopisalem jeszcze nawias odnosnie ilosci operacji. Generalnie chodzi mi o to, ze inna sytuacja jest w przypadku intensywnego przetwarzania duzych struktur danych, gdzie istotnie bedziemy sie odwolywac do RAM, co jest naturalne, wystarczy sie zastanowic jaki rzad wielkosci jakich struktur zmiesci sie do cache. Jednak bardziej chodzilo mi o to, aby przy okreslonej ilosci procesow zadbac o to, by podstawowe dane wymagane do ciaglosci i sprawnosci dzialania watku plus wspomniany przez Ciebie kontekst byly "pod reka". Operacje na strukturach danych to oczywiscie inna sprawa. Z reszta jesli wchodzic juz w detale, to analizujac oczekiwanie procesora nalezaloby jeszcze uwzglednic technologie pokroju HyperThreading, ktore maja przeciez na celu zminimalizowanie sytuacji, gdy czekamy na dostarczenie danych do watku.

Ale chyba dopiero po wyedytowaniu więc przed tym jak ja zacząłem odpowiadać.

Tak, mam tendencje poprawiania, a szczegolnie dopisywania czasem roznych rzeczy bezposrednio po ich dodaniu. Tym bardziej, ze nie widzialem Cie wsrod osob przegladajacych watek.Tak wiec w temacie dopisywania ;-) W ostatnim poscie doszedl jeszcze jeden ciekawy akapit :-).

static inline void calc_load(unsigned long ticks){unsigned long active_tasks; /* fixed-point */static int count = LOAD_FREQ;count -= ticks;if (unlikely(count < 0)) {active_tasks = count_active_tasks();do {CALC_LOAD(avenrun[0], EXP_1, active_tasks);....

Ok, to wszystko co podales wiele wyjasnia. Rzeczywiscie w gre wchodzi tylko kolejka aktywna.Ciekawe, do schedulera robilem juz troche podchodow, poki co z mniejszymi poprawkami, mam w planach do tego siasc kiedys, przegryzc i sobie dograc pare rzeczy. Ale coz, to jedna z tych rzeczy, ktore czekaja na dogodny moment ;-).Dzieki za podrzucenie kodu.Pozdrawiam!

[pleple 0]

Ciekawe, do schedulera robilem juz troche podchodow, poki co z mniejszymi poprawkami, mam w planach do tego siasc kiedys, przegryzc i sobie dograc pare rzeczy. Ale coz, to jedna z tych rzeczy, ktore czekaja na dogodny moment ;-).Dzieki za podrzucenie kodu.Pozdrawiam!

To poczekaj może jeszcze troszkę bo właśnie jest w końcowej fazie opracowywania nowy sheduler w jądze Linuksa - CFS. Bardzo prawdopodobne, że zostanie włączony już do 2.6.24.

[alien 345]

Czytalem. Poczekam, zobacze. Ale calkiem mozliwe, ze te zmiany i tak bede robic na wczesniejszych jadrach.

[Linux 0]

Ok dzięki za odpowiedzi, oczywiście dyskusje o loadzie można kontynuować w tym temacie