Webserver wordt langzamer

[Verwijderd]

Ik heb een dedicated webserver colocated waarop windows2003 met Plesk 7.6 draait.
Ik heb geen probleem met de werking van w2k3 of Plesk zelf maar een probleem met de performance van de server.

Sinds enkele weken vind ik dat de server steeds langzamer wordt, hiermee bedoel ik vooral bij het bekijken van PHP websites. Als je een PHP website bezoekt welke is gehost is op de server dan duurt het redelijk lang voordat je de pagina te zien krijgt.
Als ik op de machine zelf kijk dan zie ik dat de cpu load ineens naar 100% gaan wat wordt veroorzaakt door php.exe, opzich is niet niet erg maar dit lijkt me niet normaal.

In de sites zelf zitten geen fouten wat kan zien, of je nu een simpele PHP site of een CMS aanspreekt het resultaat is telkens hetzelfde.

Je zou dus gaan denken de server is "te licht" voor zijn werk maar dat is ook niet zo, er draaien maar ca 20 kleinere sites op waarvan er maar 10 in PHP zijn. Deze site zijn ook niet extreem veel bezocht. De server heeft voldoende geheugen(768mb) en een CPU die dit eigenlijk zonder problemen goed af zou moeten kunnen (2GHZ cpu). De problemen zijn er langzaam ingekomen waardoor ik dus eigenlijk geen echte oorzaak kan vinden van het probleem.

In Plesk logfiles staan ook geen vreemde meldingen, ook in de event viewer wordt niets vermeld wat kan duiden op een fout.

Ik begrijp dat niemand zo een reden kan geven maar kan iemand me misschien wat tips geven waarna ik zou kunnen kijken wat dit kan veroorzaken?
Zijn er bv speciale tooltjes die ik nog niet ken waarmee ik misschien kan zien waarom de server langzaam wordt of wat de hoge cpu load veroorzaakt?

[Verwijderd]

Allemaal leuk en aardig, maar welke Webserver software draai je? IIS of Apache? Hoeveel hits krijgt deze webserver per minut, en hoelang is de gemiddelde laad(/cpu) tijd per hit? Is de PHP applicatie wel optimaal gebouwd (bv slecht DB ontwerp of slechte software)?

Er zijn voldoende factoren waardoor een server "traag" word. Op mijn werk heb ik 1 specifieke website, gemaakt in PHP, die echt ENORM slecht gebouwd is, hierdoor is de serverbelasting bij onze shared-server provicer erg "hoog". Waar ligt dit dan aan? Aan PHP, de webserver of de specifieke website en de verkeerde bouwmethode?

Windows is een traag, logt en veel te belastend OS voor een serieuze webserver. Een GUI op een server is sowieso al onzinnig, dus waarom mensen Windows op een server draaien begrijp ik niet. Of is dit van wegen het gebrek aan kennis mbt serieuze OS'en? Klik&Go heeft op webservers geen zin, daarmee kan je (moeilijk) optimale prestaties bereiken. Het gaat me dus niet om MS te bashen, maar performance matig is het gewoon niet optimaal zo.

Intern in ons bedrijf draai ik zelf ook Windows servers, dit doe ik wel met Apache en niet met IIS. Icm een gemiddelde van 7 tegelijk tijdige gebruikers, is de belasting te dragen door de server, voor onze externe webservers zweer ik echt bij Linux.

[ Voor 10% gewijzigd door Verwijderd op 29-10-2006 20:39 ]

[Verwijderd]

Dat zei ik dus al: Windows met PLESK!
Plesk is IIS en waarom windows?
Wat dacht je van asp.net , asp...........

btw:
de load van w2k3 tov Linux is te verwaarlozen, dit kon je met windows2000 nog zeggen maar dit is allang niet meer zo met w2k3. Je weet dat vrijwel alle grote en bekende websites op windows servers draaien? (als je toch zo begint)

Zoals ik dus al zei het ligt niet aan de websites zelf, er staan "maar" 10 websites op die in PHP zijn, sommige zijn uitgebreid en andere heel simpel, ook zitten er 2 kant en klare CMS bij.
Als ik alle websites uit schakel en alleen 1 site activeer welke goed in elkaar zit is de pagina laden net zo snel als dat alle sites aktief zijn.
Ook de hits etc zijn minimaal, er is maar 1 grote site die genoeg hits heeft maar als ik die uitzet en een klein sitetje aanspreek is de pagina opbouw nog steeds langzaam.

hoelang is de gemiddelde laad(/cpu) tijd per hit

Dat wil ik ook wel weten alleen geen idee hoe ik daar achterkom want dat is dus het probleem....

[ Voor 8% gewijzigd door Verwijderd op 29-10-2006 21:32 ]

[leon1e]

Verwijderd schreef op zondag 29 oktober 2006 @ 21:30:
Zoals ik dus al zei het ligt niet aan de websites zelf, er staan "maar" 10 websites op die in PHP zijn, sommige zijn uitgebreid en andere heel simpel, ook zitten er 2 kant en klare CMS bij.
Als ik alle websites uit schakel en alleen 1 site activeer welke goed in elkaar zit is de pagina laden net zo snel als dat alle sites aktief zijn.
Ook de hits etc zijn minimaal, er is maar 1 grote site die genoeg hits heeft maar als ik die uitzet en een klein sitetje aanspreek is de pagina opbouw nog steeds langzaam.


[...]

Dat wil ik ook wel weten alleen geen idee hoe ik daar achterkom want dat is dus het probleem....

Heb je al eens in de logfiles en event log gekeken (en nee, ik bedoel niet de plesk logs) of er geen rare foutmeldingen staan die op een misconfiguratie kunnen wijzen? Met een simpele start/end timer kun je heel simpel even de tijd meten hoe lang een hit duurt, volgens mij is dit ook een optie "processing time" in je logfiles van iis (not sure).

[sky-]

Verwijderd schreef op zondag 29 oktober 2006 @ 20:37:
Windows is een traag, logt en veel te belastend OS voor een serieuze webserver. Een GUI op een server is sowieso al onzinnig, dus waarom mensen Windows op een server draaien begrijp ik niet. Of is dit van wegen het gebrek aan kennis mbt serieuze OS'en? Klik&Go heeft op webservers geen zin, daarmee kan je (moeilijk) optimale prestaties bereiken. Het gaat me dus niet om MS te bashen, maar performance matig is het gewoon niet optimaal zo.

' Windows is traag '.
Nee hoor..

Ik zelf ben sinds kort van freeBSD naar Windows 2k3 overgestapt en ben een nog meer tevreden over

[paulhekje]

als een windows server traag is, ga je natuurlijk als eerste met performance monitor aan de gang om te weten welk proces welke resources vraagt en wat nu de bottleneck is.

Is het alleen cpu, en alleen php dan ga je op dat proces verder inzoomen. met process explorer van system internals kom je erachter welke thread de boosdoener is en waarschijnlijk welke website of onderdeel een probleem heeft.

[leon1e]

k8skaaay schreef op zondag 29 oktober 2006 @ 22:09:
[...]

' Windows is traag '.
Nee hoor..

Ik zelf ben sinds kort van freeBSD naar Windows 2k3 overgestapt en ben een nog meer tevreden over

De discussie Windows/Unix/Enz. hebben we al heel vaak gevoerd zullen we deze maar achterwege laten deze keer?

[Molybdenum]

Hoeveel geheugen wordt er aangesproken? Loopt je geheugen misschien vol?

[Asteroid9]

Verwijderd schreef op zondag 29 oktober 2006 @ 20:37:
Verhaal....

Ik had gehoopt dat het OS bashing in ieder geval binnen PNS achterwege kon blijven.
Meer iets voor 16-jarige Linux enthousiastelingen, niet voor serieuze vakspecialisten.

Zinloos, ongefundeerd verhaal wat niks toevoegt aan de discussie, bedankt voor je bijdrage...

[Verwijderd]

Geheugen verbruik is ca 15% dus dat is te verwaarlozen.

[Rolfie]

Ik zou toch eens gaan kijken naar de perfmon gegevens. Je hebt maar 750Mb er in zitten en dat is nu niet echt veel. Waar zit je vertraging nu precies? Is het CPU, zijn het je disken, is het je geheugen. Ga daar eerst eens mee troubnle shooten met perfmon. Want nu is het een glazenbol zoeken.

[leon1e]

Verwijderd schreef op maandag 30 oktober 2006 @ 14:36:
Geheugen verbruik is ca 15% dus dat is te verwaarlozen.

Je bent wel heel erg selectief in het beantwoorden van de vragen van ons, heb je nu al eens naar de logs gekeken en specifiek naar de processen? Zo komen we natuurlijk niet verder .

[Verwijderd]

Zoals ik al in mijn start aangaf ik heb alles al bekeken wat men vraagt.

De vertraging waar deze zit weet ik niet, dat vraag ik me nu net af
- Zit het in de cpu? disken? ik zou het echt niet weten
- Geheugen verbruik is ca 500 tot 650mb constant dus ruim voldoende onder maximum
- cpu load vliegt steeds naar 100% zodra php.exe aangeroepen wordt
- performance log geeft alleen pieken in de cpu (zoals ik al zei)
- In andere log files staat echt helemaal niets, geen enkele error
memory, Page/sec 0,000
PhysicalDisk, Avg disk Queue lenght 0,003
Processor, % Processor Time (tussen de) 1,563 en 100,00
- Of je nu een simpele of uitgebreide PHP website gebruikt maakt allemaal geen verschil, het zit hem dus niet in "slecht" gescripte websites. Ook al zet je alle websites uit en laat je er 1 draaien dan is de snelheid nog steeds te laag.

[Verwijderd]

Ik heb de oorzaak vermoedelijk gevonden.

De virusscanner scant constant alle bestanden wat dus een flinke vertaging veroozaakt, ik heb de scanner gepauseerd en warempel de sites zijn ineens een stuk sneller.

[Koffie]

Modbreak:

Gelieve de discussie van het OS en type webserver achterwege te laten, als ook de reacties daar op!

[Verwijderd]

Verwijderd schreef op maandag 30 oktober 2006 @ 21:55:
Ik heb de oorzaak vermoedelijk gevonden.

De virusscanner scant constant alle bestanden wat dus een flinke vertaging veroozaakt, ik heb de scanner gepauseerd en warempel de sites zijn ineens een stuk sneller.

Je hebt de oorzaak misschien gevonden maar ik hoop dat je het daarbij niet laat zitten. Zeker een webserver heeft naar mijn mening een virusscanner nodig.

[Asteroid9]

Een fatsoenlijke virusscanner kun je keurig inregelen op read/write acties en trusted processen instellen.
Daarmee zou je met behoud van de scanner prima performance moeten behalen.

[alt-92]

Verwijderd schreef op zondag 29 oktober 2006 @ 18:16:
Als ik op de machine zelf kijk dan zie ik dat de cpu load ineens naar 100% gaan wat wordt veroorzaakt door php.exe

Is het gebruik van php als CGI een bewuste keuze geweest?
de ISAPI is over het algemeen stukken stabieler, en ook sneller t.o.v. de CGI setup.
Zeker op Windows met IIS.

[Verwijderd]

@dycell
Ik heb een andere virusscanner (gratis versie) geïnstalleerd welke ook ondersteund wordt door Plesk, natuurlijk heeft een webserver ook een virus scanner nodig.
De geadviseerde virusscanner door Plesk was Drweb, maar om onduidelijke redenen vertraagd deze scanner zoveel dat het voor mij niet prettig is.

@Asteroid9
Dat zou je wel verwachten, deze scanner die ik gebruikte (DrWeb) is me aanbevolen door SWSOFT (makers van Plesk), Drweb zou perfect funtioneren icm met Plesk dus. Helaas kon ik in de instellingen niets vinden waarmee je de acties etc goed kon instellen. Ik had wat settings gewijzigd maar dit had geen enkel effect op de traagheid. Alleen toen ik de scanner uitschakelde was de traagheid ineens weg. Ik heb nu winclam (of clamwin) geinstalleerd, dit is een gratis scanner welke ook samenwerkt met Plesk en welke totaal geen vertraging veroorzaakt.

@BackSlash32
Achteraf bleken de php processen die ik voorbij zag komen met 100% load van scheduled tasks te komen, dus niet de PHP sessies van bezoekers van de websites. De "normale" PHP sessie draait inderdaad in ISAPI, alleen de scheduled tasks niet dus. Deze scheduled tasks vormen opzich geen problemen, nu de scanner welke het probleem veroorzaakte uitstaat zijn de loads ook geen 100% meer, de gehele load komt nu niet meer boven de 20% uit (van de gehele server).


Sinds ik de scanner heb uitgezet draait de server weer normaal en vooral snel

[Verwijderd]

Kun je niet in je virus scanner bepaalde files excluden van scan? Dat doe ik hier ook op onze interne 2003r2 IIS server met idd php processen.

Ik had dat probleem ook, bij ons was het de software die tikklokken uitlas, elke uitlees aktie was cpu load -> 100%. Na wat onderzoek, de norman onaccess scan uit gezet voor die bepaalde files en probleem verholpen. De rest van de documenten (sharepoint services) worden nu nog wel netjes gescanned.

[Verwijderd]

Ja dat kan je instellen, alleen de server werd niet langzaam van die PHP processen die 100% load hadden. Ik heb als test eerst deze schedules uitgezet echter dit had geen enkel effect op de traagheid van de server. Het is echt de viri scanner die de traagheid veroorzaakt, ook door de viri scanner kregen deze PHP schedules een load van 100%. Nu de viri uitstaat is de load van deze processen nog geen 20% meer en de server is weer normaal bereikbaar.

Ik heb diverse scan settings uitgezet in de viriscanner maar niets had enig effect op de traagheid, het enige wat dus echt effect had was het geheel uitzetten van de scanner. Dit had dus als effect dat de server weer ineens normaal "snel" werd. Met de andere viriscanner die ik nu heb geïnstalleerd heb ik dit probleem niet.

[ Voor 6% gewijzigd door Verwijderd op 31-10-2006 17:00 ]