Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: obciazenie once again
Forum PHP.pl > Forum > PHP
borec
przedmiot dyskusji: http://www.rolka.okay.pl

dane serwera:

procek: Pentium 4 2.80GHz 1 Mb cache
ram: 2Gb (+ 2Gb swap)
system: GNU/Linux
soft: Apache 2 / MySQL 4.0 / php 4.3.10

troche statow:

aktualny load average: 5.00, 5.62, 8.21 (potrafi dochodzic do 70!)

uzycie pamieci:
total: 2026 mb, used: 1882 Mb, free: 144 Mb

staty odwiedzin mojego serwisu z 1 dnia:
W sumie: 217697, max: 20580, średnio: 9070 na godzinę

staty mysql:
Threads: 11 Questions: 5206863 Slow queries: 1448 Opens: 853478 Flush tables: 1 Open tables: 64 Queries per second avg: 120.140 (aaa!!!)

problem w tym ze na tym serwerze stoi pare duzych serwisow (http://www.forum.tarnow.pl/, http://www.amnezja.org/, http://www.gg3d.com/, http://www.student.tarnow.pl/) i moj a wszystko to daje przecudne obciazenie.

i robi sie nieciekawie. chociaz prawie wszystko jest maxymalnie zcachowane - wyniki wiekszosci skryptow zapisywane sa do plikow html i php nie jest wogole zaprzegane do pracy. wyjatkiem jest strona logowania, rejestracji, edycji danych i wyszukiwania. ta ostatnia ma w statach odwiedzin 1 miejsce (ponad 50%) i podejrzewam ze to ona tak bruzdzi.

dzisiaj robilem wiekszy upgrade i chwilowo przez .htaccess wylaczylem dostep do serwisu, load spadl wtedy z 38 do 6!

strona wykorzystuje smarty i adodb (polaczenie pconnect, moze zwykle connect byloby szybsze?).

dane userow w bazie (te ktore przeszukuje wyszukiwarka) podzielone sa na 2 tabele, w jednej podstawowe dane (login, email, haslo, aktywny/nieaktywny) a w drugiej dane personalne (komunikatory itd). moze polaczenie tego w 1 tabele przyspieszylo by wyszukiwanie?

inna rzecz ktora mnie zmartwila to dodawanie fotek, skrypt ktory sie tym zajmuje (zmienia rozmiar fotki i tworzy miniaturke) plakal ze ma malo pamieci, zwiekszylem ini_setem do 128 mb a on dalej plakal! uspokoil sie dopiero gdy ustawilem memory_limit na (o zgrozo) 512 MB.

myslalem o cachowaniu wynikow zapytan sql w wyszukiwarce ale to sie chyba mija z celem bo kazdy szuka czego innego

jakies pomysly? tip: w kodzie html kazdej strony na samym dole w komentarzy jest czas generowania i data zcachowania

bede wdzieczny za wszelkie rady
behemot
Witam,

Ja zaczal bym od przegladniecia slowloga w mysql (warto zaczac logowac wolniejsze zapytania). Masz ich dosc sporo. Postaraj sie zoptymalizowac zapytania, dodac brakujace indexy (chyba ze sa stworzone wlasciwie). Zapytan do bazy nie jest wcale tak duzo jak na taki sprzet. Ja wyglada sprawa obciazenia cpu? Bo jesli cpu nie ma 100% obciazenia to waskim gardlem sa zapewne operacje dyskowe. Moze warto kupic szybszy dysk. Jakis RAID ew SCSI, ale to skolei koszty...
hwao
Po 1 nic nie napisałeś odnosnie wersji php smile.gif jezei to mozliwe nagraj php5 bo jest bardziej wydajne od php4.

Pozatym polecal bym nagrac jakis optym. do php np darmowy mmcache smile.gif

Co do bazy danych to mysle ze connect zwykly jest lepszy, pozatym jezeli to mozliwe to polecal bym przejsc na inna baze danych (szybsze sa i mniej "mecza" procesor)

To chyba tyle co mi teraz przychodzi do glowy jezeli chodzi bez $$ ... :-)
militis
Jeżeli jest to możliwe to zainstaluj zamiast MySQL naprzykład PostgreSQL.

Turck-MMCache sobie odpuść bo nie jest rozwijany od 2 lat, i jest niedopracowany do PHP5. Natomiast jeżeli możesz to zainstaluj jakis inny dobry accelerator php.

Poza tym tak sprawdź dyski hdparmem, spróbuj podnieść ich wydajność najpierw programowo, a jak nie pomoże no to nie ma innego wyjścia jak kupić Raida albo Scsi jak ktoś wcześniej już wspomniał.

Możesz także nałożyć limity na co cięższe serwisy, żeby nie obciążały tak sprzętu, albo męcz programistów, żeby zoptymalizowali swój kod.

Nic więcej na daną chwilę nie wymyślę, ale mam nadzieje, że mogłem pomóc winksmiley.jpg

Pozdro
Imperior
Cytat(militis @ 2005-06-05 10:32:26)
Turck-MMCache sobie odpuść bo nie jest rozwijany od 2 lat, i jest niedopracowany do PHP5.

eAccelerator bazuje na nim i jest rozwijany.
borec
zapomnialem dodac ze nie jest to mowj serwer winksmiley.jpg wiec nici z instalacji czegokolwiek dry.gif

wersja php to 4.3.10 (z reszta pisalem to w 1 poscie winksmiley.jpg ) i nie ma mozliwosci zmiany na php5. admini sa hm... malo doswiadczeni i zeby uzyskac glupia obsluge plikow .htaccess musialem im napisac jaka linie dodac do httpd.conf dry.gif

mam mozliwosc uzycia mmcache i nic wiecej. dysk w prawdzie moglbym dokupic ale ja raczej chcialem na tej stronie zarobic a nie stracic tongue.gif hdparm wogole nie jest zainstalowany tiredsmiley.gif

pozostaje mi chyba przegladnac slowlogi jak radzil behemot, ewentualnie pconnect -> connect no i mmcache

dzieki smile.gif gdyby ktos jeszcze na cos wpadl to chetnie poczytam smile.gif
militis
Cytat(Imperior @ 2005-06-05 13:00:11)
Cytat(militis @ 2005-06-05 10:32:26)
Turck-MMCache sobie odpuść bo nie jest rozwijany od 2 lat, i jest niedopracowany do PHP5.

eAccelerator bazuje na nim i jest rozwijany.

ALE eAccelerator !== Turck-MMCache smile.gif
Imperior
Cytat(militis @ 2005-06-05 13:57:50)
Cytat(Imperior @ 2005-06-05 13:00:11)
Cytat(militis @ 2005-06-05 10:32:26)
Turck-MMCache sobie odpuść bo nie jest rozwijany od 2 lat, i jest niedopracowany do PHP5.

eAccelerator bazuje na nim i jest rozwijany.

ALE eAccelerator !== Turck-MMCache smile.gif

1. Czy ja powiedziałem, że to jest to samo?
2. Co to zmienia? Napisałem o rozwijanym acceleratorze w przeciwieństwie do T-MM. O co Ci chodzi?
3. Jeśli już to != a nie !== Manual
ActivePlayer
Cytat
strona wykorzystuje smarty i adodb (polaczenie pconnect, moze zwykle connect byloby szybsze?).


wlacz cache smartego.
borec
Cytat(ActivePlayer @ 2005-06-05 20:04:40)
Cytat

strona wykorzystuje smarty i adodb (polaczenie pconnect, moze zwykle connect byloby szybsze?).


wlacz cache smartego.

po co?

Cytat
wyniki wiekszosci skryptow zapisywane sa do plikow html i php nie jest wogole zaprzegane do pracy.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.