Onderwerp: Performance issues

Een server van ons heeft performance problemen.

Eerst wat algemene info:

Wat server hardware:
- INTEL XEON 5110 (@1,60Ghz, Dual Core)
- 2GB RAM
- Twee HD's van 320GB in RAID 1

Software die op de server draait:
- FreeBSD 6.2
- Apache 2.2 + PHP5.2
- OpenSSH
- PureFTPD (amper in gebruik)
- Mailserver-software (af en toe eens een connectie)

Op de server draait 1 website, die is ontwikkeld in PHP (ook Smarty template engine) en gebruik maakt van een MySQL database.
De MySQL database draait op een andere machine. De server is dus bijna enkel in gebruik door een apache server. De server is verbonden met de database server via een 1gbit connectie.

De load avarages gaan soms tot historisch hoge waarden, 13.85, 13.94, 13.18 / 19.85, 19.94, 19.18 / 26.85, 24.94, 23.18 / of zelfs hoger.

We merken ook dat er heel veel httpd processen geopend worden op de server. We hebben dus meteen de apache server status bekeken en daar zien we dat de server +/- 13 requests per seconde moet verwerken.

Server uptime: 1 hour 33 minutes 54 seconds
Total accesses: 73699 - Total Traffic: 255.1 MB
CPU Usage: u254.664 s854.031 cu.046875 cs0 - 19.7% CPU load
13.1 requests/sec - 46.4 kB/second - 3630 B/request
38 requests currently being processed, 15 idle workers

Verduidelijkende screensh http://img120.imageshack.us/my.php?image=loadhi2.png

Nu is mijn vraag, is het mogelijk dat één site zo aan de performance van een server vreet? En indien ja, wat is de oorzaak hiervan? Hardware/Software/Code van de site/Queries/...? En wat kunnen we doen om dit perfect te kunnen controleren? En eventueel, wat kunnen we doen om dit op te lossen?

Queries zou me echt verwonderen aangezien de load balances van de database server zeer normaal zijn, stabiel blijven en nooit boven de 1.00, 1.00, 1.00 gaan.

Nog een verduidelijkende screensh
http://img355.imageshack.us/my.php?i...lding14pu8.png

De site trekt behoorlijk wat bezoekers (+/- 1000hits per uur), dat is te zien aan het aantal httpd processen die geopend worden. Maar wat is dan de beste oplossing, en is het aantal bezoekers weldegelijk het probleem, of is het eerder de codering van de website?

Alvast bedankt!

Vriendelijke groeten,

Guus De Graeve

1000hits per uur is nou niet iets waar je uberhaupt load van zou mogen krijgen, per minuut wordt het pas intressant

Maar ik zie best veel cpu load? Veel I/O wait? Heb je misschien lange waittimes op de dbase, dus niet goed kunnen resolven? Ik zie dat je swap gebruikt, daar kan het heel traag van worden...

Stap 1: zoek wat het probleem is? Memory te kort, teveel disk-IO activity, gewoon apache die zonder threads/processen zit?

Stap 2: bekijk wat je eraan kan doen (mem bijplaatsen, database queries optimaliseren, caching, anders tunen)

Stap 3: instant money, and all the chicks!

Oorspronkelijk geplaatst door Freezer

1000hits per uur is nou niet iets waar je uberhaupt load van zou mogen krijgen, per minuut wordt het pas intressant

Maar ik zie best veel cpu load? Veel I/O wait? Heb je misschien lange waittimes op de dbase, dus niet goed kunnen resolven? Ik zie dat je swap gebruikt, daar kan het heel traag van worden...

1000hits per uur lijkt inderdaad niet super veel. Maar voor deze website is dat weldegelijk heel wat. Als je weet dat er per hit gemiddeld +/- 50 database query's nodig zijn kan dat wel al wat veroorzaken. Het kan echter niet liggen aan het niet goed kunnen resolven, aangezien de connectie tussen de server en de mysql server dns-onafhankelijk is (via ip).

Er is inderdaad een swap partitie. Maar aan de screens te zien wordt die toch amper gebruikt (6%)? En er is nog wat ram-geheugen vrij ook. Of zit dit anders?

I/O wait is er niet, dit heb ik reeds nagetrokken.

Mem: 463M Active, 1099M Inact, 233M Wired, 72M Cache, 112M Buf, 135M Free
Swap: 4070M Total, 280M Used, 3790M Free, 6% Inuse

Wat misschien ook nog belangrijk is: de website maakt heel veel gebruik van ajax, de stats die we hier geven (1000hits/uur) komen uit een google analytics rapport en daarin zijn die ajax-hits dus niet meegeteld.

Ofwel brakke website-code (php) die veel te lang duurt om uit te voeren, ofwel wacht je php op je mysql (kan je daar even op een piekmoment een "show processlist" uitvoeren in de mysql console)?

1.0 op een losse dbserver vind ik behoorlijk hoog aangezien ik sites heb met 60-70K users per dag die continue 5-10 mbit/s van de dbserver trekken. Maar zijn load komt niet boven de 0.2 uit.
Ik zou eens goed kijken of met die db alles wel goed loopt. Installeer mytop, zet slow_query_log aan, kijk of aan het aantal locks waarop gewacht moet worden niet te groot is, of je queries misschien beter gecached kunnen worden, of je niet beter andere table indexen moet maken e.d.
Maar zoals wonko al zegt, brakke code is ook my first choice.

Oorspronkelijk geplaatst door GuusDeGraeve

1000hits per uur lijkt inderdaad niet super veel. Maar voor deze website is dat weldegelijk heel wat. Als je weet dat er per hit gemiddeld +/- 50 database query's nodig zijn kan dat wel al wat veroorzaken. Het kan echter niet liggen aan het niet goed kunnen resolven, aangezien de connectie tussen de server en de mysql server dns-onafhankelijk is (via ip).

Er is inderdaad een swap partitie. Maar aan de screens te zien wordt die toch amper gebruikt (6%)? En er is nog wat ram-geheugen vrij ook. Of zit dit anders?

I/O wait is er niet, dit heb ik reeds nagetrokken.



Wat misschien ook nog belangrijk is: de website maakt heel veel gebruik van ajax, de stats die we hier geven (1000hits/uur) komen uit een google analytics rapport en daarin zijn die ajax-hits dus niet meegeteld.

Als het php scripts zijn, probeer eens xcache te installeren. De tip van wonko zou ik zeker ook doen, als je veel waiting processen ziet, dan ook mysql starten met skip name resolve (klinkt stom, maar ik heb hier ook issue's mee gehad toen ik naar een ip connecte).

Voor de rest, 50 queries per pagina is veel, maar met jouw stats alsnog maar 13 per seconde. Swap is gewoon iets wat je niet wil gebruiken, disk is te langzaam in vergelijking met je memory, dus vermijdt het indien mogelijk.

Op hoeveel zetten jullie de long_query_time waarde in my.cnf? We hebben namelijk wel enkele uitgebreide query's waarvan het normaal is dat ze iets langer duren.

Kan je niet eerst eens de processlist plaatsen?

Oorspronkelijk geplaatst door Freezer

Kan je niet eerst eens de processlist plaatsen?

Dit is een screenshot van hoe de processlist momenteel ongeveer is. Momenteel is er echter wel niet echt een probleem, de load balances liggen niet boven 1.00. Het is dus een minder druk moment nu.

http://img372.imageshack.us/my.php?i...lding15ut9.png

Dit is een screenshot van de output van mytop op ongeveer hetzelfde moment:
http://img206.imageshack.us/my.php?i...lding16lz0.png

Als je dan zoveel tijd besteed aan het masken van de databasenaam, haal hem dan ook in de query zelf weg

Oorspronkelijk geplaatst door Xolphin

Als je dan zoveel tijd besteed aan het masken van de databasenaam, haal hem dan ook in de query zelf weg

Databasenaam is niet in de query te zien, tenzij jij een FROM op een database doet

Wellicht kun je je scripts profilen, om te zien waar 'ie nou mee bezig is.

http://www.linuxjournal.com/article/7213

Geen ervaring mee onder PHP, maar onder Java heb ik wel eens een profiler gebruikt. Je krijgt dan gewoon de top-10 van langzaamste functies, erg makkelijk.

Ik heb ondertussen xCache geinstalleerd, ik denk echter wel dat ik sowieso RAM zal moeten bijsteken, aangezien hij nu al maar 101M vrij heeft en xCache in de RAM zijn compiled php scripts cached.

Mem: 457M Active, 1094M Inact, 252M Wired, 99M Cache, 112M Buf, 101M Free

Momenteel zit er 2GB ram in, wat mij eerlijk gezegd nogal weinig lijkt. Als we nu RAM bijsteken, hoeveel raden jullie aan? En zal dit dan meteen ook het gebruik van de swap minimaliseren?

Het beste advies krijg je als je de output van 'free -m' hier plaatst.

Het hangt van je distro en eventuele custom instellingen af of je swap tot 0 af neemt. De 'swappiness' van sommige servers staan zodanig ingesteld dat ze de voorkeur geven aan meer schijfbuffering (dus meer geheugen naar swap schrijven).

Dus niet schrikken als swapgeheugengebruik niet naar 0 daalt.

Als je je RAM upgradet, even opletten dat je geheugenbankjes in identieke paren plaatst i.v.m. dual channel. http://en.wikipedia.org/wiki/Dual-channel_architecture

Als geld geen rol speelt, zoveel mogelijk plaatsen. Anders verdubbelen denk ik, rekening houdend met bovenstaande.