Witam,
założyłem Na OVH serwer VPS 4gb ramu 3 proce itd. Zainstalowałem CENTOSA i panel zpanelcp wg.:

https://www.nazwa.pl/pomoc/produkty-i-uslug...anel-na-centos/

ale wait time jest ogromny sięga od 1s do nawet 6s:
http://tools.pingdom.com/fpt/#!/bSQRtf...ittlethings.pl/

my.cnf

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
innodb_buffer_pool_size = 32M

sort_buffer_size = 1M
join_buffer_size = 8M
read_buffer_size = 8M
max_connections = 100
wait_timeout = 100
table_definition_cache = 800


thread_cache_size = 16
table_open_cache = 1K
innodb_force_recovery = 0
query_cache_size = 32M
query_cache_limit =1M

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
long_query_time=1
log-slow-queries=/var/log/mysql/log-slow-queries.log
log-queries-not-using-indexes


<IfModule prefork.c>
StartServers 8
MinSpareServers 5
MaxSpareServers 20
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 4000
</IfModule>
a oto wynik skryptu który miał pokazać ile zużywa apache

# sh ap.sh
Apache Memory Usage (MB): 0
awk: (FILENAME=- FNR=1) fatalny błąd: próba dzielenia przez zero


Powiem szczerze jestem załamany i nie mam pojęcia co mam z tym fantem zrobić i co jest nie tak

poka lepiej jakie zapytania Ci system robi do bazy

o cache slyszal? mozesz postawic varnisha, ewentualnie na szybko jezeli masz na vps php apc/apcu: https://github.com/cepa/kickasscache

umiesc KickAssCacheApc.php w katalogu gdzie jest index.php i na samym poczatku index.php doklej:

require 'KickAssCacheApc.php';
$cache = new KickAssCacheApc();
$cache->capturePage();

nie wyeliminuje problemu, ale obejdzie go i da Ci czas na rozwiazanie bo pewnie masz waskie gardlo w bazie danych.

Pierwsza sprawa, https://raw.githubusercontent.com/major/MyS...r/mysqltuner.pl - sugeruj się wynikami (czasem lubi ciągle się poprawiać) + optymalizacja ręczna wg zaleceń.
Kolejna sprawa, tak jak @cepa napisał, cache (nawet zwykły memcache, zawsze pomoże)

Projekt własny? Czy na jakimś frameworku? No i główne pytanie, co powoduje czkawki, tzn który skrypt/klasa/itp?

btw. do zajętości ramu przez procesy polecam https://raw.githubusercontent.com/pixelb/ps...aster/ps_mem.py

apc cache i dodatkowo moduł page speed od wujka googla dawno załadowane mysqltuner oraz tuning-primer także stosuje zalecenia a generalnie zasobów pamięci nigdy nie przekroczyłem 50% tak samo z procesorem więc zasobów nie brakuje mimo wszytko nie działa tak jak bym chciał

Siedzę nad tym prawie dwa tygodnie na serwerze jest tylko jedna strona oparta o prestashop i zpanelcp generalnie, jeżeli wejdziecie na stronę to zauważycie, że strona sama w sobie ma przymulenie na początku po czym szybko się pojawia to przymulenie to wait time pokazywany na testach a reszta jak widać na teście ładuje się szybko.

Odnośnie optymalizacji kodu strony to mam wystarczające doświadczenie by ta strona ładowała się w oka mgnieniu ale z serwerami nie miałem do tej pory do czynienia i nie mam pojęcia dlaczego serwer tak długo odpowiada na zapytanie.

A już całkowicie mnie dziwi ZEROWE zużycie ramu dla Apache

to masz pewnie tylko wlaczony opcode cache dla php i nic wiecej, michodzi o cachowanie statycznego kontentu zeby apka w ogole nie dzialala kiedy nie musi.



Uzyles mpm prefork wiec dziala dokladnie tak jak powinno, tworzy osobne procesy pehapa ktore obsluguja request, apache nie ma nic do roboty poza kolejkowaniem requestow i przekazywaniem danych w jedna i w druga strone. Pehap bedzie obciazony zaleznie od ciezkosci projektu, jak masz tam mase kodu z tylu albo jakis duzy flejmłolk, to pewnie zobaczysz wzrost zuzycia ramu i cpu przy pikach.

Tak jak napisal kolega wyzej mysql tuner do optymalizacji konfiguracji i PRZEDEWSZYSTKIM zdebuguj zapytania do sql, bo dam sobie leb urwac ze sie laduje dlugo bo czeka az mysql przemieli baze.

Na kilku testach pokazało że ok 3s. to DNS, na innych nic nie pokazało, organoleptycznie pokazało mi że strona śmiga u mnie. Google twierdzi że jest OK.

Dokleiłem twoją twórczość ale nie widzę żadnej różnicy, chyba że coś źle robię ale dokleiłem w index.php na początku a to nie należy do trudnych rzeczy

a jak puściłem

ab -n 100000 -c 200 http://littlethings.pl/

to zabiło mi serwer musiałem restartować


Jak mam zdebugować zapytania konkretnie bym prosił czyli krok po kroku BARDZO PROSŻĘ


PS. Po restarcie tak jakby szybciej chodzi ale że zapchałem pingdom to nie mogę sprawdzić

pokaz co wywala:
php -i | grep apc

apc (apcu) powinno byc wlaczone

co do wydajnosci, w chwili pisania tego posta:
ab -kc 10 -n 100 "http://littlethings.pl/"
masz miedzy 2 a 5 req / sec

Napisales ze masz ok 4GB ramu, zwieksz parametry mpm_prefork, StartServers i SpareServers podnies na jakies 64...128 powinno zrownoleglic requesty w kolejce i lockowane mutexem.
Nastepnie sproboj odpalic jeszcze raz z tym kawalkiem kodu tylko stopniuj sobie parametr -c zeby ustalic jaka masz wydajnosc, 10..20..50..100 itd, ta klasa powinna byc odpalona zanim cokolwiek innego poleci w twojej apce, cachuje wyjscie output bufora, robi mutex i ot cala filozofia. Jakby nie pomoglo to pisz, lub wklej wyniki z ab A i po kazdej zmianie w kodzie restartuj apacha zeby procesy pehapa nie uzywaly scachowanego kodu.

Osobiscie preferuje setup z nginxem i php-fpm bo subiektywnie wydaje mi sie ze dziala bardziej stabilnie: http://lukasz.cepowski.com/devlog/43,high-...inx-and-php-fpm

Co do mysql, panie na guglu masz wszystko: lmgtfu: http://stackoverflow.com/questions/303994/...ueries-in-mysql

Wydajnosc mierzona ab jest ogolnie o kantu dypy potluc, ale daje ci wstepne wyobrazenia o systemie, na powaznie jmeter.

wywaliło mi to

PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/module s/php_mcrypt.dll' - /usr/lib64/php/modules/php_mcrypt.dll: cannot open shared ob ject file: No such file or directory in Unknown on line 0
PHP Warning: Module 'mcrypt' already loaded in Unknown on line 0
PHP Warning: Module 'PDO' already loaded in Unknown on line 0
PHP Warning: Module 'pdo_mysql' already loaded in Unknown on line 0
Additional .ini files parsed => /etc/php.d/apc.ini,
apc
apc.cache_by_default => On => On
apc.canonicalize => On => On
apc.coredump_unmap => Off => Off
apc.enable_cli => Off => Off
apc.enabled => On => On
apc.file_md5 => Off => Off
apc.file_update_protection => 2 => 2
apc.filters => no value => no value
apc.gc_ttl => 3600 => 3600
apc.include_once_override => Off => Off
apc.lazy_classes => Off => Off
apc.lazy_functions => Off => Off
apc.max_file_size => 1M => 1M
apc.mmap_file_mask => no value => no value
apc.num_files_hint => 1000 => 1000
apc.preload_path => no value => no value
apc.report_autofilter => Off => Off
apc.rfc1867 => Off => Off
apc.rfc1867_freq => 0 => 0
apc.rfc1867_name => APC_UPLOAD_PROGRESS => APC_UPLOAD_PROGRESS
apc.rfc1867_prefix => upload_ => upload_
apc.rfc1867_ttl => 3600 => 3600
apc.serializer => default => default
apc.shm_segments => 1 => 1
apc.shm_size => 32M => 32M
apc.slam_defense => On => On
apc.stat => On => On
apc.stat_ctime => Off => Off
apc.ttl => 0 => 0
apc.use_request_time => On => On
apc.user_entries_hint => 4096 => 4096
apc.user_ttl => 0 => 0
apc.write_lock => On => On
suhosin.apc_bug_workaround => Off => Off





Zauważyłem jeszcze jedną rzeczy otóż wzrasta zużycie dysku twardego (tak mi się wydaje) w sensie pojemności i to dość sporo bo po 100 mb dziennie czy mogą to być jakieś logi które tak zajmują dysk aktualnie jest 2.26 GB zobaczymy ile będzie jutro

cd /var/log
du -h | sort -h

4,0K ./httpd/fcgidsock
4,0K ./mysql
4,0K ./proftpd
8,0K ./audit
8,0K ./mail
608K ./pagespeed
21M ./httpd
42M .


zmieniłem httpd.conf na


<IfModule prefork.c>
StartServers 64
MinSpareServers 64
MaxSpareServers 128
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 4000
</IfModule>

Zużycie ramu bliskie 100%

zużycie dysku 2.29 GB

No juz widać, ze cos ruszyłes:

ab -kc 10 -n 1000 "http://littlethings.pl/"
Requests per second: 11.18 [#/sec] (mean)

To, że ram zajety to akurat dobrze, requesty sa po prostu przetwarzane przez wieksza ilosc workerów.

Mam prośbę, mógłbyś dodać taki kawałek kodu na początku index.php twojej aplikacji:

[PHP] pobierz, plaintext 
require 'KickAssCacheApc.php';
$cache = new KickAssCacheApc();
$cache->setTtl(3600);
$cache->setRandomFactor(2);
$cache->capturePage();
[PHP] pobierz, plaintext 

Chciałbym zobaczyć czy cokolwiek przyśpieszy, podejrzewam, że twoja apka zwraca wynik po ponad 5 sekundach dlatego mutex mogl sie wylaczac zanim cos trafi do cache i byc moze dlatego nie bylo roznicy w dzialaniu.

Co do pozostałej konfiguracji, to mysql jest mocno ograniczony, mozesz skopiowac ustawienia sysctl i limits z http://lukasz.cepowski.com/devlog/43,high-...inx-and-php-fpm - wymaga restartu serwera. Ogolnei chodzi oto ze masz domyslny limit na ilosc otwartych deskryptorow plikow na 1024 a wszystko w twoim systemie z nich korzysta, mysql, php, apache itp, wiec bardzo szybko sie zapcha. Co do mysql to sproboj zwiekszyc jego bufory, ale nie przesadzaj zeby serwer nie zaczal swapowac, sproboj uzyc mysqltuner.

Niesamowite jestem w SZOKU Ddodałem twój kod na początku strony i po prostu WOW JESTEŚ WIELKI

Dobra a jak zrobić beż użycia twego magicznego kodu??

odnośnie tego:

http://lukasz.cepowski.com/devlog/43,high-...inx-and-php-fpm

czy te wartości dadzą rade u mnie, czy nie stanie przypadkiem serwer ?

No cos tam jest lepiej, ale na moje oko da sie jeszcze szybciej Z mojego serwera ab wyszlo w granicach 100..120 req / sec.

Czy serwer stanie czy nie, nie wiem, po to jest monitoring zeby obserwowac jak sie produkcja zachowuje jak bedzie sie zblizalo do limitow to trzeba obnizyc i juz.

Wartosci sysctl.conf mozesz w sumie skopiowac, one zwiekszaja przepustowosc serwera, limity nofiles pozwalaja na alokacje wiekszej ilosci deskryptorow plikow, a wiec wiecej polaczen, uchwytow itp itd. Nastepnie podnies parametry mysql, poczytaj na googlu co oznaczaja konkretne parametry: przykladowo mozesz zaczac od tych:

max_connections = 1000
table_cache = 2000
key_buffer = 256M
query_cache_limit = 4MB
query_cache_size = 128MB
thread_stack = 192K
thread_cache_size = 64

Monitoruj zuzycie ramu, jak cos zacznie swapowac to obniz wartosci.

Na koniec zostaje ci optymalizacja zapytan, i cachowanie ich wynikow, ale to najpewniej musisz juz zrobic w samej aplikacji gdzies w warstwie komunikacji z baza danych.