Jak zoptymalizować VPSa na Centosie

[bear007 0]

Witajcie,

 

Mam serwer VPS z Centosem, jako serwer WWW używam lighttpd. Oprócz tego też korzystam z bazy danych MySQL.

 

Zrobiłem testy wczoraj i strona serwowała mi się w 0,3 sekundy. Jest to zwykły plik PHP wykonujący zwykłe zapytania do MySQL (proste joiny). Dodałem indeksy które miały przyśpieszyć działanie.

 

Testy obciążenia natomiast wykazały:

 

10 klientów - 1,1 sekundy

30 klientów - 2 sekundy.

 

Dla porównania sprawdziłem na moim zwykłym hostingu i oto wyniki:

 

10 klientów - 470 ms.

30 klientów - 430 ms.

 

Mam wrażenie że coś jest cholera nie tak z moim VPSem bo mam o wiele niższe wyniki niż na "zwykłym hostingu"

 

Znalazłem w sieci porady jak zoptymalizować serwer Apache, ale nie mogę znaleźć za dużo na temat Lighttpd. Mam wrażenie że te czasy są wynikiem złej konfiguracji VPS, serwera WWW albo bazy danych. Problem polega jednak na tym, że nie wiem jak wykryć co stanowi problem. Co powoduje, że serwer jest taki wolny.

 

Czy moglibyście poradzić jakiś test? Od czego zacząć? Gdzie szukać problemów wydajności? Bo w tym momencie jestem w kropce. Znalazłem sposoby do wykonywania testów obciążenia ale nie dają one same w sobie odpowiedzi co może być przyczyną złej wydajności serwera.

 

pozdrawiam

[m.p 0]

1 - http://mysqltuner.pl/ - polecam

2 - cache?

 

poza tym wiesz, co innego porządny dedyk na którym hostowane jest wiele kont, a co innego mały vps.

[bear007 0]

Cześć,

 

Problem polega na tym, że na tym zwykłym hostingu nie korzystam z cache'a a mimo tego działa ok. A ten mysqltuner do czego jest?

 

 

1 - http://mysqltuner.pl/ - polecam

2 - cache?

 

poza tym wiesz, co innego porządny dedyk na którym hostowane jest wiele kont, a co innego mały vps.

[m.p 0]

A ten mysqltuner do czego jest?

 

podpowiada co warto zmienić w konfiguracji bazy, aby działała lepiej.

[Lapiech 0]

===========

Dla porównania sprawdziłem na moim zwykłym hostingu i oto wyniki:

 

10 klientów - 470 ms.

30 klientów - 430 ms.

=========================

 

Zobacz sam że w twoim teście na hostingu wzrost ilości klientów a czas krótszy i to jest właśnie współdzielony hosting, szybka wydajna maszynka.

 

Tylko, że jak zaczniesz ją obciążać to usłyszysz "papa" bo wtedy inni klienci nie mają dobrych rezultatów a na VPS-ie nikogo to nie obchodzi masz swój limit i tyle.

 

Prawdopodobnie gdybyś trafił na duże obciążenie hostingu to czasy by były gorsze a może i lepsze bo a nuż mniej klientów by wtedy miało "aktywne strony" ot taka huśtawka.

 

Jak testowałeś wydajność ??

[bear007 0]

Masz rację, ten zwykły hosting ma swoje granice mimo, że jego wykres jest prawie płaski.

 

Dodałem do mojego skryptu cacheowanie za pomocą memcache. Dodałem też licznik czasu który zlicza czas przy rozpoczęciu skryptu, na koniec skryptu i wyświetla wynik.

 

Bez keszowania miałem około 0,1-1 sekundę. Teraz z keszowaniem wyświetla stale 0,0003 sekundy.

 

Gdy zobaczyłem ten wynik pomyślałem, że złapałem byka za rogi. Ale kiedy testuję z zewnątrz... no właśnie.

 

Testy robię za pomocą OpenLoad (http://openwebload.sourceforge.net/) z mojego komputera i mam dla parametrów:

 

openload.exe -l 10 <adres_pliku_php_na_serwerze> 5

 

tj. 5 wątków robi requesty przez 10 sekund :

 

TPS: 4,58

Średni czas odpowiedzi: 0,733 (czyli o wiele więcej niż wyświetla mi mój licznik czasu osadzony w skrypcie PHP!!!

Liczba requestów: 46

 

Czyli skrypt zwraca mi informację, że jego wykonanie trwa 0,0003 sekundy a realnie przez Internet dostaję stronę w 0,733 sekundy. Co jest ogromną różnicą.

 

Pingi do serwera są na poziomie 17-20 ms.

 

Co jeszcze ciekawsze kiedy z VPS-a uruchomiłem AB (http://httpd.apache.org/docs/2.0/programs/ab.html) dostałem wynik średnio 300 ms na serwowanie strony przy 1000 równoczesnych wątków.

 

Także mam wrażenie że lokalnie serwer śmiga, ale coś powoduje, że na zewnątrz nie serwuje on za dobrze stron mimo dobrych pingów. Ale to są moje przypuszczenia, bo tak na prawdę nie wiem jak to interpretować.

 

Co może być tego przyczyną?

[pajter 9]

 

Czyli skrypt zwraca mi informację, że jego wykonanie trwa 0,0003 sekundy a realnie przez Internet dostaję stronę w 0,733 sekundy. Co jest ogromną różnicą.

[d.v 1409]

Serwer może mieć genialnie niski ping i wykonywać skrypty z szybkością błyskawicy, ale jeśli "wisi" na wolnym łączu, to nie masz szans otrzymać od niego pakietów z zadowalającą prędkością. Fizyki nie oszukasz, nawet traktowanie wysyłanej treści gzipem nie pomoże, jeśli strona waży kilka mega a łącze na serwerze ma szerokość pipety...

[bear007 0]

d.v

 

Rozumiem. Jak w takim razie zbadać wydajność łącza do serwera? Chciałbym porozmawiać o tym z moim dostawcą VPS-a, ale potrzebuję do tego jakieś liczby / dowody, które wykażą że to wina łącza.

[Miłosz 2311]

bieżący ruch możesz śledzić za pomocą iptraf

[bear007 0]

podpowiada co warto zmienić w konfiguracji bazy, aby działała lepiej.

 

Jak go uruchomić na Centosie?

 

bieżący ruch możesz śledzić za pomocą iptraf

 

Jak iptraf może być pomocny w znalezieniu wąskiego gardła?

[m.p 0]

Jak go uruchomić na Centosie?

 

z jakiej powłoki korzystasz? bash?

 

./mysqltuner.pl

 

lub

 

perl ./mysqltuner.pl

[bear007 0]

z jakiej powłoki korzystasz? bash?

 

./mysqltuner.pl

 

lub

 

perl ./mysqltuner.pl

 

Wkopiowałem treść do pliku mysqltuner.pl za pomocą nano. Dodałem uprawnienia do wykonywania tego skryptu. Następie odpaliłem (mam basha) za pomocą obu metod podanym i obie dają taki wynik:

 

Bareword found where operator expected at ./mysqltuner.pl line 8, near "//tools"

(Missing operator before tools?)

Unquoted string "tools" may clash with future reserved word at ./mysqltuner.pl line 8.

Unquoted string "assembla" may clash with future reserved word at ./mysqltuner.pl line 8.

Unquoted string "com" may clash with future reserved word at ./mysqltuner.pl line 8.

Unquoted string "svn" may clash with future reserved word at ./mysqltuner.pl line 8.

Unquoted string "mysqltuner" may clash with future reserved word at ./mysqltuner.pl line 8.

syntax error at ./mysqltuner.pl line 8, near "//tools"

"use" not allowed in expression at ./mysqltuner.pl line 39, at end of line

BEGIN not safe after errors--compilation aborted at ./mysqltuner.pl line 40.

 

Nie wiem co teraz zrobić?

[m.p 0]

pobierz to poprzez

wget http://mysqltuner.pl/

i wtedy odpal, coś dziwnego się zrobiło podczas kopiowania do nano

[bear007 0]

pobierz to poprzez

wget http://mysqltuner.pl/

i wtedy odpal, coś dziwnego się zrobiło podczas kopiowania do nano

 

Dzięki. Teraz już działa. Dostałem takie rady:

 

-------- General Statistics --------------------------------------------------

[--] Skipped version check for MySQLTuner script

[OK] Currently running supported MySQL version 5.0.45-log

[OK] Operating on 32-bit architecture with less than 2GB RAM

 

-------- Storage Engine Statistics -------------------------------------------

[--] Status: -Archive -BDB -Federated -InnoDB -ISAM -NDBCluster

[--] Data in MyISAM tables: 9M (Tables: 199)

[!!] Total fragmented tables: 8

 

-------- Performance Metrics -------------------------------------------------

[--] Up for: 1h 18m 3s (5K q [1.098 qps], 707 conn, TX: 6M, RX: 357K)

[--] Reads / Writes: 91% / 9%

[--] Total buffers: 26.0M global + 824.0K per thread (100 max threads)

[OK] Maximum possible memory usage: 106.5M (20% of installed RAM)

[OK] Slow queries: 0% (0/5K)

[OK] Highest usage of available connections: 4% (4/100)

[!!] Key buffer size / total MyISAM indexes: 16.0K/2.4M

[!!] Key buffer hit rate: 72.7% (3K cached / 934 reads)

[!!] Query cache is disabled

[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 198 sorts)

[OK] Temporary tables created on disk: 0% (3 on disk / 707 total)

[!!] Thread cache is disabled

[!!] Table cache hit rate: 0% (4 open / 1K opened)

[OK] Open file limit used: 0% (8/1K)

[OK] Table locks acquired immediately: 100% (2K immediate / 2K locks)

 

-------- Recommendations -----------------------------------------------------

General recommendations:

Run OPTIMIZE TABLE to defragment tables for better performance

MySQL started within last 24 hours - recommendations may be inaccurate

Set thread_cache_size to 4 as a starting value

Increase table_cache gradually to avoid file descriptor limits

Variables to adjust:

key_buffer_size (> 2.4M)

query_cache_size (>= 8M)

thread_cache_size (start at 4)

table_cache (> 4)

 

Rekomendacje podają jakieś wartości, ale powyżej te opcje z wykrzyknikami nie. Myślę żeby poeksperymentować.

Ale jak testować czy moje zmiany odniosły pozytywny skutek?

[m.p 0]

najlepiej odczekaj min 24h od startu mysqla, potem zrób ponownie ten 'test', zmień zalecane wartości, zastosuj się do podanych rad i zerkaj raz na jakiś czas ile mysql je ramu, jaka jest jego wydajność, etc.