Duże Obciążenie Vps'a

[Gamsiu 1]

Witajcie,

 

Pewien skrypt dość wolno działał na risp.pl więc postanowiłęm go przenieść na VPS'a. Wybór padł na strato.de(najniższy plan - 128MB ram do 512MB) za pośrednictwem xxl-web.

 

Po odpaleniu skryptu oto obciążenie w szczycie:

top - 05:31:45 up 1:05, 1 user, load average: 1.42, 0.97, 0.93

Tasks: 44 total, 1 running, 43 sleeping, 0 stopped, 0 zombie

Cpu(s): 33.1% us, 23.7% sy, 0.0% ni, 43.1% id, 0.1% wa, 0.0% hi, 0.0% si

 

Zapytań do bazy jest średnio 37 na sekunde

Teraz widze, że load podskoczył na 2,15, 1,81, 1,32 :/ Czasami też spada do 0,59, 0,88, 0,95

 

Planowałem wrzucić na tego vpsa jeszcze kilka stronek ale w takim wypadku nie wiemczy to go całkowicie nie zamuli. W związku z tym mam Was kilka pytań:

- Powyżej jakiej wartości load daje się odczuć powolne działanie stron?

- Czy 37 zapytań do bazy na sekundę to bardzo dużo jak na małego vpsa? Sam domyślam się, że dużo. Risp ma wchwili obecjej 113,23/s no ale mogę się mylić

- Czy przeniesienie na wyższy plan w strato coś pomoże? Obecnie mój vps jest na maszynie z Pentium® 4 CPU 2.40GHz

 

PS. Dziwie się, że risp.pl mnie nie wyrzucił za generowanie takiego obciążenia

[pleple 0]

- Powyżej jakiej wartości load daje się odczuć powolne działanie stron?

Load avarage jest na prawdę mało miarodajnym parametrem. Ponieważ tak często pojawia się tutaj ten temat pozwolę sobie przybliżyć trochę sposób w jaki ten parametr jest liczony. W linuksie makro, które się tym zajmuje zdefiniowane jest w pliku nagłówkowym jądra (include/linux/sched.h):

#define CALC_LOAD(load,exp,n) \

load *= exp; \

load += n*(FIXED_1-exp); \

load >>= FSHIFT

 

Odpowiada to równianiu:

load(t) = load(t - 1) exp + n (1 - exp)

gdzie exp jest pewną stałą dla danego odcinka czasu (jest zdefiniowana jako e^(-5/60m), gdzie m jest parametrem oznaczającym czas dla którego mierzony jest load - 1,5,15 minut )

 

Ok, a tutaj mamy funkcję z pliku kernel/timer.c gdzie to makro jest wykorzystywane:

/*

* calc_load - given tick count, update the avenrun load estimates.

* This is called while holding a write_lock on xtime_lock.

*/

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);

CALC_LOAD(avenrun[1], EXP_5, active_tasks);

CALC_LOAD(avenrun[2], EXP_15, active_tasks);

count += LOAD_FREQ;

} while (count < 0);

}

}

 

Jak więc widać, za n podstawiana jest wartość active_tasks, wyliczane przez funkcję zdefiniowaną w tym samym pliku:

static unsigned long count_active_tasks(void)

{

return nr_active() * FIXED_1;

}

 

Żeby już nie zanudzać napiszę iż funkcja nr_active() jest zdefiniowana w pliku kernel/sched.c i sumuje ona wszystkie procesy działające oraz te "uninterruptible" na wszystkich aktywnych procesorach. Procesy uśpione, czekające na I/O itp. nie są liczone.

 

KONKLUZJA: Load avarage jest parametrem uśrednionym w pewnych odcinkach czasu, z charakterystyką eksponencjalną (przy wzroście lub spadku), zależną od ilości działających w systemie procesów.

 

 

 

- Czy 37 zapytań do bazy na sekundę to bardzo dużo jak na małego vpsa? Sam domyślam się, że dużo. Risp ma wchwili obecjej 113,23/s no ale mogę się mylić

Również ilość zapytań do bazy to żaden wyznacznik. Musisz zbadać jakie to zapytania. Prosty SELECT z indeksowanej tabeli może zająć nawet tysięczne części sekundy. 37 takich zapytań zajmie na prawdę mało czasu i przez ogromną większość czasu silnik bazy danych będzie się nudził.

Źle zaprojektowane zapytania do bazy danych potrafią jednak trwać dużo dłużej, nawet kilkanaście sekund. Wtedy wykonanie takich 37 zapytań na sekundę jest nawet nie możliwe.

Podsumowując - musisz raczej zbadać jakie zapytania są wykonywane i ile czasu zajmuje ich wykonanie. Może część z nich da się zoptymalizować a może nawet nie jest to potrzebne. Najprawdopodobniej jednak 37 zapytań na sekundę wykonanych na sprzęcie z małą ilością zasobów to dość sporo.

 

 

- Czy przeniesienie na wyższy plan w strato coś pomoże? Obecnie mój vps jest na maszynie z Pentium® 4 CPU 2.40GHz

To na jakiej maszynie jest nie jest tak istotne. Ważniejsze jest raczej to jak duża część zasobów jest przydzielona Tobie. Za zwyczaj na wyższym planie masz również więcej zasobów więc w takim wypadku odpowiedź będzie "raczej pomoże ale nie wiadomo jak bardzo".

[malu 460]

Load 2 i chcesz nowa maszynke ^^ powiem ci ze na 200 % Risp.pl ma loady w granicy 4-5 .

[Gamsiu 1]

Load avarage jest na prawdę mało miarodajnym parametrem. Ponieważ tak często pojawia się tutaj ten temat pozwolę sobie przybliżyć trochę sposób w jaki ten parametr jest liczony.

 

Dzięki za wyjasnienie.

 

 

Również ilość zapytań do bazy to żaden wyznacznik. Musisz zbadać jakie to zapytania.

 

set option 49,78 %

change db 24,89 %

select 11,96 %

update 10,81 %

insert 2,47 %

 

 

 

To na jakiej maszynie jest nie jest tak istotne. Ważniejsze jest raczej to jak duża część zasobów jest przydzielona Tobie. Za zwyczaj na wyższym planie masz również więcej zasobów więc w takim wypadku odpowiedź będzie "raczej pomoże ale nie wiadomo jak bardzo".

 

Strato nie pisze nigdzie o tym ile CPU przypada na jeden VPS

 

Load 2 i chcesz nowa maszynke ^^ powiem ci ze na 200 % Risp.pl ma loady w granicy 4-5 .

 

Tak, chce zmieniać bo skoro przy jednym tylko zużywanych przezemnie skryptów load dochodzi do 2 to co będzie jak wrzuce tam jeszcze kilka rzeczy? Gdyby miał tam działać tylko ten jeden skrypt to nie miałbym nic przeciwko;)

[Linux 0]

Zacznij się martwić jak load zacznie dochodzić do 8

 

/Edit - Skoro nie pisze to znaczy że masz shared cpu jak w wszystkich najtańszych vpsach dlatego coś takiego nazywam shitem

[Tomi 0]

set option 49,78 %

change db 24,89 %

select 11,96 %

update 10,81 %

insert 2,47 %

 

Tego typu zapytań nawet dobrze nie da się cashować. Częściej zmieniasz samą bazę danych niż ją odczytujesz czy zapisujesz do niej? To znaczy, że skrypt jest do wymiany bo autor nie zrozumiał idei operowania na bazie danych.

 

Raczej przejście na większy pakiet tylko cię ratuje. Ewentualnie zmiana standardowego Apache na coś szybszego. Chociaż sqlowi to nie ulży zbytnio. Proponuje też wycieczkę od strato.de do hosteurope.de Powinno pomóc.

[pleple 0]

set option 49,78 %

change db 24,89 %

select 11,96 %

update 10,81 %

insert 2,47 %

Jest to procent czego? Ilości zapytań czy czasu spędzonego na danych zapytaniach?

 

Tak, chce zmieniać bo skoro przy jednym tylko zużywanych przezemnie skryptów load dochodzi do 2 to co będzie jak wrzuce tam jeszcze kilka rzeczy? Gdyby miał tam działać tylko ten jeden skrypt to nie miałbym nic przeciwko;)

Masz setki tysięcy hitów dziennie czy po prostu do bani skrypt? Raczej nad tym bym się zastanowił bardziej..

 

 

Zacznij się martwić jak load zacznie dochodzić do 8

Nie obraź się ale to bzdura (tak, zauważyłem ten "języczek" ale uważam iż autor wątku potrzebuje raczej konkretnych opinii niż bezsensownych wypowiedzi). Zasadniczo load sam w sobie nie daje wyznacznika tego czy system jest przeciążony czy też nie. Fakt jest jednak taki iż optymalny load jest w przybliżeniu równy ilości dostępnych procesorów (czy rdzeni). Oznacza to iż procesy zasadniczo nie kolejkują się w oczekiwaniu na zasoby procesora. W żadnym wypadku jednak load wyższy niż to nie jest problemem o ile widoczna responsywność aplikacji nie jest zaburzona. Za zwyczaj takie opóźnienia pojawiają się jednak kiedy load zaczyna wzrastać powyżej 3 (przy jednym procesorze).

 

 

Ewentualnie zmiana standardowego Apache na coś szybszego.

Prościej byłoby pewnie przejść na lżejsze MPM (np. worker) w Apache co wpłynęłoby bardzo podobnie na wydajność jak zmiana samego serwera (ponieważ większość z tych serwerów szybszych niż Apache po prostu używa domyślnie wątków podczas kiedy Apache nadal (dla kompatybilności z kiepskimi modułami jak mod_php) używa MPM prefork. Jednak to czy różnica będzie zauważalna zależy głównie od charakteru stron serwowanych przez dany serwer.