Webserver traag; oplossingen gezocht

[redpen]

ik zit met een probleem ik ben al een langere tijd op zoek om onze webserver sneller te maken
omdat de server zodra het wat drukker wordt begint te hikken ( lange load time etc )

wat info over de server

p4 3,2
1 gig ram
fedora core 4

mysql :
Server version 3.23.58
Protocol version 10
Connection Localhost via UNIX socket
UNIX socket /var/lib/mysql/mysql.sock
Uptime: 4 days 23 hours 31 min 41 sec

Threads: 9 Questions: 83307817 Slow queries: 37 Opens: 1300 Flush tables: 1 Open tables: 1023 Queries per second avg: 193.604

apache :
Server version: Apache/2.0.53

momenteel draaien er 5 websites op waarvan 4 sites klein en 1tje 60.000 unieke bezoekers per dag

Server uptime: 23 minutes 19 seconds
Total accesses: 31650 - Total Traffic: 599.2 MB
CPU Usage: u184.18 s24.39 cu0 cs0 - 14.9% CPU load
22.6 requests/sec - 438.6 kB/second - 19.4 kB/request
6 requests currently being processed, 12 idle workers


mijn config op dit moment is

<IfModule prefork.c>
StartServers 10
MinSpareServers 5
MaxSpareServers 15
ServerLimit 1024
MaxClients 256
MaxRequestsPerChild 0
</IfModule>

<IfModule worker.c>
StartServers 10
MaxClients 256
MinSpareThreads 5
MaxSpareThreads 15
ThreadsPerChild 5
MaxRequestsPerChild 0
</IfModule>


mysqlconfig:

[mysqld]
innodb_data_file_path=ibdata1:10M:autoextend
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock


#nieuw
set-variable = max_connections=200
set-variable = key_buffer=16M
set-variable = myisam_sort_buffer_size=64M
set-variable = join_buffer=1M
set-variable = record_buffer=2M
set-variable = sort_buffer=2M
set-variable = table_cache=1024
set-variable = thread_cache_size=64
set-variable = wait_timeout=1800
set-variable = connect_timeout=10
set-variable = max_allowed_packet=16M
set-variable = max_connect_errors=10
#nieuw

[myisamchk]
set-variable = key_buffer=64M
set-variable = sort_buffer=64M
set-variable = read_buffer=16M
set-variable = write_buffer=16M

[mysqlhotcopy]

[mysql.server]
user=mysql
basedir=/var/lib

[safe_mysqld]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

de scripts etc zijn een aantal keer al flink opgeschoond en verschillende keys die niet in de database aanwezig waren heb ik aangemaakt ( totaal scheelde dit al heel veel )

ik kom er dus niet verder mee wie kan mij advies geven welke setting wel of niet gedaan moet worden ( en voor mysql eventueel een site waar alle variabelen in staan die ingevuld kunnen worden voor geheugen gebruik etc )

[CyBeR]

PHP neem ik aan? Da's vrij zwaar voor 22 requests/sec gemiddeld op een enkele doos. Maar probeer eAccelerator eens te installeren (http://eaccelerator.net/).

[redpen]

ja php ben nu even aan het proberen die eaccelerator te installeren

[_JGC_]

Daarnaast heeft MySQL het over slow queries: zet slow query logging aan en bekijk je mysql-slow.log, optimaliseer de queries door indices te plaatsen of je query anders te formuleren. MySQL wordt compleet op zijn gat getrokken als je queries niet optimaal zijn. Een dergelijke PC moet met gemak 100 hit/s kunnen trekken.

Edit: ik zie ook dat je een _ENORM_ aantal queries op mysql afvuurt. Zijn die dingen echt allemaal nodig en kan je niet het een en ander combineren? Zorg ervoor dat mysql redelijk grote caches krijgt. Vooral de query cache kan veel uitmaken bij vaak dezelfde queries.

Dan nog de InnoDB pool size: die staat op 10MB auto-extend. Als je innodb gebruikt en veel data opslaat in dat ding, staat ie de hele tijd pooltjes van 10MB per stuk aan te maken. Als je innodb gebruikt: dump je database, zorg voor een grotere innodb pool in de configuratie en importeer de hele zwik opnieuw. Daarnaast is het aan te raden om eens naar een nieuwere MySQL te kijken, InnoDB is nogal veel geoptimaliseerd door de MySQL releases heen.

[ Voor 54% gewijzigd door _JGC_ op 12-07-2006 11:00 ]

[CyBeR]

Oh, en MySQL 3.23 is ook niet echt de snelste meer.. Kijk eens naar MySQL 4.1 of zelfs MySQL 5.0. Die zijn beide echt een stuk sneller dan 3.23. (Probeer 't wel eerst even uit op een testdoos natuurlijk.)

[Verwijderd]

Er kan wat performance winst worden behaald denk ik door het aantal max-connections op te voeren en te wait-timeout te verlagen in mysql.

Ik zie ook dat het aantal tables dat open is zijn maximum heeft bereikt dit kan je vergroten naar max-connection * (aantal gejoined tables in een query). Hiervoor moet de table_cache omhoog.

[ Voor 7% gewijzigd door Verwijderd op 12-07-2006 11:03 ]

[Spider.007]

[noodkreet]probleem met webserver preformance > Webserver traag; oplossingen gezocht *

[killercow]

je hebt maar 0.64 unieke bezoekers per seconde op die drukke site.

22 page views per seconde moet gemakkelijk te doen is voor zo'n P4.

Gooi daarnaast je mysql ram een flink omhoog, je hebt een gig, gebruik het dan ook.

Gebruik explain sql in mysql eens, ik weet zeker dat je je indexes een stuk beter kunt in stellen.

[redpen]

mysql upgrade wordt het eerste grote probleem de server die we gebruiken maakt gebruik van plesk 7.5.4

volgens het bedrijf waar wij de server huren is het niet mogelijk om mysql 4 etc erop te zetten zonder problemen te krijgen ( ze doen het daarom ook niet en ik mag het wel zelf doen maar dan zijn de reperatie kosten en alle risico`s voor mij )


slow query`s werkt volgens mij niet onder mysql 3 ? want die slow querys staat er wel in helemaal onderin de mysql config deze is alleen weg gevallen hier komt echter niets in te staan


ps.

de database is MyISAM
database is 129 mb totaal

en load van het systeem is

top - 11:19:45 up 5 days, 21 min, 3 users, load average: 0.91, 0.84, 0.97
Tasks: 181 total, 1 running, 180 sleeping, 0 stopped, 0 zombie
Cpu(s): 18.2% us, 4.8% sy, 0.0% ni, 74.3% id, 2.3% wa, 0.2% hi, 0.2% si
Mem: 1018300k total, 1003952k used, 14348k free, 8060k buffers
Swap: 2096472k total, 279344k used, 1817128k free, 85548k cached

hij maakt dus volledig gebruik van zijn geheugen ( of dat ook correct gebruikt wordt??? )


heb nu wat settings anders gezet

set-variable = max_connections=512 >> was eerst 200
set-variable = table_cache=2048 >> was eerst 1024
set-variable = wait_timeout=1000 >> was eerst 1800


Uptime: 34 Threads: 9 Questions: 6661 Slow queries: 0 Opens: 83 Flush tables: 1 Open tables: 77 Queries per second avg: 195.912


>> killercow <<

ik heb alle databases 1 voor 1 nagelopen en overal indexes op gezet waar dat nodig zou moeten zijn ( alles wat dus gebruikt wordt om de rest op te halen ( id`s , usernames , zones etc )

[ Voor 58% gewijzigd door redpen op 12-07-2006 11:23 ]

[redpen]

heb nog wat dingentjes gevonden

Copying to tmp table krijg ik om de zoveeltijd in phpmyadmin

[Spider.007]

redpen schreef op woensdag 12 juli 2006 @ 11:11:
mysql upgrade wordt het eerste grote probleem de server die we gebruiken maakt gebruik van plesk 7.5.4

volgens het bedrijf waar wij de server huren is het niet mogelijk om mysql 4 etc erop te zetten zonder problemen te krijgen ( ze doen het daarom ook niet en ik mag het wel zelf doen maar dan zijn de reperatie kosten en alle risico`s voor mij )

[...]

Laat ik je dan nog 1 keer waarschuwen. Ga het niet proberen. Plesk is dusdanig in zichzelf verweven dat je daar geen losse componenten van wilt upgraden. Ik denk aan de rest van je relaas ook te zien dat je dit niet gaat oplossen met andere software erop; je hebt gewoon geen idee waar je mee bezig bent en dan wordt het oplossen van je problemen ook al wat lastiger

Verwijderd schreef op woensdag 12 juli 2006 @ 11:03:
Er kan wat performance winst worden behaald denk ik door het aantal max-connections op te voeren en te wait-timeout te verlagen in mysql.

Ik zie ook dat het aantal tables dat open is zijn maximum heeft bereikt dit kan je vergroten naar max-connection * (aantal gejoined tables in een query). Hiervoor moet de table_cache omhoog.

Als je met 5 websites 1023 tabellen open hebt kun je denk beter aan de andere kant van het probleem beginnen; namelijk oplossen ipv een doekje tegen het bloeden

[killercow]

Spider.007 schreef op woensdag 12 juli 2006 @ 12:09:


Als je met 5 websites 1023 tabellen open hebt kun je denk beter aan de andere kant van het probleem beginnen; namelijk oplossen ipv een doekje tegen het bloeden

seccond that,

Dat je uberhaupt meer dan 20 tabellen per website hebt en gebruikt is al wat schrikbarend eigenlijk.

Wat voor informatie heb je eigenlijk opgelagen, en heb je misschien een voorbeeld query? (een naar ouw idee ingewikkelde?)

[Freezerator]

Is hij niet aan het swappen naar je geheugen?

Mem: 1018300k total, 1003952k used, 14348k free, 8060k buffers
Swap: 2096472k total, 279344k used, 1817128k free, 85548k cached

Dat kan flinke vertragingen opleveren?

[sariel]

redpen schreef op woensdag 12 juli 2006 @ 11:11:

top - 11:19:45 up 5 days, 21 min, 3 users, load average: 0.91, 0.84, 0.97
Tasks: 181 total, 1 running, 180 sleeping, 0 stopped, 0 zombie
Cpu(s): 18.2% us, 4.8% sy, 0.0% ni, 74.3% id, 2.3% wa, 0.2% hi, 0.2% si
Mem: 1018300k total, 1003952k used, 14348k free, 8060k buffers
Swap: 2096472k total, 279344k used, 1817128k free, 85548k cached

hij maakt dus volledig gebruik van zijn geheugen ( of dat ook correct gebruikt wordt??? )

Eeuhm.....280mb de swap in...kijk even wat er zo veel geheugen gebruikt, en zorg er voor dat het wat minder wordt.

Uptime: 34 Threads: 9 Questions: 6661 Slow queries: 0 Opens: 83 Flush tables: 1 Open tables: 77 Queries per second avg: 195.912

wtf? 195000 queries per seconde? FIXEN!!!!!!

En als het 195 queries per seconde is (vage andere notatie), fix ook ff. Beetje veel. Als het 22 pagina's per seconde is, dat betekend dat op iedere pagina 4-5 queries zijn. Kijk of dat misschien wat terug te brengen is.

[CyBeR]

sariel schreef op woensdag 12 juli 2006 @ 13:55:
[...]


Eeuhm.....280mb de swap in...kijk even wat er zo veel geheugen gebruikt, en zorg er voor dat het wat minder wordt.


[...]


wtf? 195000 queries per seconde? FIXEN!!!!!!

Niet bekend met niet-nederlandse notaties van getallen, zie ik? Da's dus 195 queries/sec

En als het 195 queries per seconde is (vage andere notatie), fix ook ff. Beetje veel. Als het 22 pagina's per seconde is, dat betekend dat op iedere pagina 4-5 queries zijn. Kijk of dat misschien wat terug te brengen is.

Mja. Je houdt hier geen rekening met static files, dus het daadwerkelijke aantal queries per pagina zal hoger liggen. Bovendien is 4 a 5 queries per pagina bijzonder weinig voor een serieuze website. Het CMS op m'n werk doet voor een simpele pagina al 70 queries als er niets gecached is.

[Spider.007]

sariel schreef op woensdag 12 juli 2006 @ 13:55:
[...]

Eeuhm.....280mb de swap in...kijk even wat er zo veel geheugen gebruikt, en zorg er voor dat het wat minder wordt.

Waarschijnlijk de verschillende caches die adhv tips in dit topic worden omhooggeschroeft

[...]

En als het 195 queries per seconde is (vage andere notatie),

Niet zo raar toch, in een engelstalige applicatie?

fix ook ff. Beetje veel. Als het 22 pagina's per seconde is, dat betekend dat op iedere pagina 4-5 queries zijn. Kijk of dat misschien wat terug te brengen is.

Een groot aantal queries hoeft geen hoge belasting te zijn; interessanter is om even te horen of de TS uberhaupt het beheer over deze websites voert? Daarnaast zou ik de slow_query log eens bekijken; en wat de limiet daarvan is, is ook interessant om te weten

[Arnout]

MaxRequestsPerChild heb je op nul staan.

De childs gebruiken meer geheugen naarmate ze meer requests uitgevoerd hebben, vooral bij slechte PHP code is dit het geval. Daarom zou ik hier 1000 of 200 van maken en kijken of dat scheelt. Sowieso heeft dit met een gebrek aan RAM te maken, en dat kun je hier mee beinvloeden.

[redpen]

jup ik heb de server compleet in beheer de scripts etc


ok dus MaxRequestsPerChild zet ik op 1000 of 1500 ofzo

die 1023 tabellen die open zijn hoe krijg je die naar onder ?

[webfreakz.nl]

redpen schreef op woensdag 12 juli 2006 @ 20:00:
jup ik heb de server compleet in beheer de scripts etc


ok dus MaxRequestsPerChild zet ik op 1000 of 1500 ofzo

die 1023 tabellen die open zijn hoe krijg je die naar onder ?

1023 tabellen verdeelt over 5 websites:

1023 / 5 = 204,6 tabellen per website, wat ongelooflijk veel is. Er gaat dus IMHO niet erg efficiënt om met de data én de verdeling ervan. Gebruik je een zelf geschreven pakket of een commercieel pakket (dan zou ik daar maar gelijk vanaf schrappen).? Door meer Joins te gebruiken en andere Union gedoe (ben niet meer zo thuis in website scripting laatste tijd...) kan je het aantal queries per seconde naar beneden bijschaven...

[ Voor 14% gewijzigd door webfreakz.nl op 12-07-2006 20:08 ]

[kmf]

als je die max-connections en maxrequests steeds hoger zet, dan kan je server dat nooit bijbenen qua geheugen. In plaats van "max connections reached" krijg je dan zelfs de kans dat je server crasht...

Als je kan moet je echt mysql 4 installeren. Heb je plesk echt nodig? De querycache van versie 4 scheelt een hoop.

En trouwens, zorg ervoor dat er niet geswapped wordt. Dus even 1GB er bij prikken.

copy to tmptable. Kans is groot dat hij liever een tablescan doet dan een indexscan.

killercow schreef op woensdag 12 juli 2006 @ 13:48:
[...]


seccond that,

Dat je uberhaupt meer dan 20 tabellen per website hebt en gebruikt is al wat schrikbarend eigenlijk.

Wat voor informatie heb je eigenlijk opgelagen, en heb je misschien een voorbeeld query? (een naar ouw idee ingewikkelde?)

Een beetje forum heeft al gauw 60 tabellen hoor. Zo vreemd nog niet.

webfreakz.nl schreef op woensdag 12 juli 2006 @ 20:08:
[...]


1023 tabellen verdeelt over 5 websites:

1023 / 5 = 204,6 tabellen per website, wat ongelooflijk veel is. Er gaat dus IMHO niet erg efficiënt om met de data én de verdeling ervan. Gebruik je een zelf geschreven pakket of een commercieel pakket (dan zou ik daar maar gelijk vanaf schrappen).? Door meer Joins te gebruiken en andere Union gedoe (ben niet meer zo thuis in website scripting laatste tijd...) kan je het aantal queries per seconde naar beneden bijschaven...

Ik kan je al antwoorden dat al die queries van meneer joins zijn. Mysql 3 ondersteunt geen subqueries


PS. als een van die websites coppermine host of zo. Ga dan flink Want die vuurt makkelijk 50 queries per pagina af....

[ Voor 66% gewijzigd door kmf op 12-07-2006 20:56 ]

[daft_dutch]

mischien zijn de sql queries verkeerd gescheven.
select * from a,b,c,d where foo.a = foo.b and foo2.b = foo2.c and foo3.c = foo3.d
gaat enorm veel tijd kosten als de tables een beetje groter worden
ik ben er een beetje uit dus kan niet snel een voorbeeld geven hoe het makkelijker kan
subqueries maakt het leven een stuk makkelijker

[ Voor 8% gewijzigd door daft_dutch op 12-07-2006 23:14 ]

[_JGC_]

Wat denk je van fatsoenlijke joins gebruiken en je database ontwerp te herzien? met een select uit 4 tabellen en een bak vergelijkingen om de uitvoer te limiteren maak je je queries niet echt sneller.

Verder zeg je dat je InnoDB niet gebruikt... waarom laat je dat dan aanstaan, alles eruitslopen wat niet gebruikt wordt. Op debian heb je een optie "skip-innodb" in my.cnf, ik neem aan dat dat op Fedora ook moet werken.

Verder raadde CyBeR je al aan om EAccelerator te installeren, mocht je dat inmiddels gedaan hebben: zet de compression level of ergens op 2-3, of zet het helemaal uit, en niet op 9 zoals in de handleiding staat. Op een grote profielensite konden we door deze aanpassing van 800 hits/s naar 1000hits/s met dezelfde load. Die 16MB shared memory die voor caching gebruikt wordt op die site is voldoende om alle PHP code te bevatten.

[TheBorg]

Tuning Apache and PHP for Speed on Unix

[redpen]

dat zou inderdaad kunnen er zitten een of meerdere tabellen tussen die wel groter zijn het feit is echter het zijn profielen in deze profielen zijn heel veel verschillende dingen die je kunt invoeren


eerst was alles uit 1 grote bak ( inlog en constante dingen ) nu heb ik het gesplits en met een join haal ik de gegevens op ( alle inlog gegevens en dingen die meteen nodig zijn zoals avatars etc staan in de centrale users database ) en de gegevens in de centrale users gegevens database )


ram erbij prikken zou inderdaad een hoop kunnen schelen ik denk dat ik het eens navraag hoeveel het kost om daar een reepje bij te prikken

[chem]

Een applicatie met 200 tabellen is echt niet traag. Een database met 1 miljard records is niet traag. Een database met 200q/s is niet veel.

Laten we de dingen wel in perspectief zetten; zonder kennis van het systeem maar een beetje brullen dat het "veel te veel" is, slaat echt nergens op.

Daarintegen is het voor ons ook moeilijk om je te helpen met de oplossing; er zijn wel wat truukjes die helpen, maar dat is maar symptoom bestrijding. Denk bv aan een aparte webserver voor static files (evt. als reversed proxy voor apache), meer req/child toestaan etc.
Maar de echte oplossing, als het kan, zit in research: waar gaat de tijd heen, waar wacht het proces op, wat is het profile van een gemiddeld request.

Dus zoek EERST uit waar je cpu-tijd heen gaat, voordat je allemaal randzaken erbij gaat betrekken.

[killercow]

Agrees,

Al lijkt het mij vrij duidelijk dat een website met 200 tabellen hoogstwaarschijnlijk wel wat normalisatie kan gebruiken. (oke, uitzonderingen daargelaten, maar 200 tabellen per website, x5 ) is gewoon echt wel veel.

Ik vroeg niet voor niks om een "ingewikkelde/trage" query als voorbeeld.