[Slack9] Onverklaarbaar traag...

[duderuud]

Pas heb ik een nieuwe server gebouwd die moet gaan fungeren als webserver.
Deze server had ik toen geinstalleerd met Slack 9.0, ging best aardig eigenlijk:)
Server werkte ook goed, alleen PHP werd vreselijk traag geserveerd.

Server weer meegenomen uit datacenter, staat nu weer thuis. De server heb ik helemaal gecontroleerd (op hardwareniveau met diagtools), geen enkel probleem.

Nou ja, server maar helemaal opnieuw installeren....en jep! Alles weer snel!
Ik heb wat lopen klooien...dus weer opnieuw geïnstalleerd om 'm klaar te maken voor productie. Ja hoor, weer niet vooruit te branden...NOG een keer opnieuw geinstalleerd...nog steeds hetzelfde.

Ik gebruik als leidraad het tooltje perf...download die hier.
Dit tooltje stelt niet veel voor, maar het is voor mij voldoende.

Normale waardes: 4, 5, 7
Waardes op bovenstaande server: 5, 7, 40 (string manipulation)

De 'string manipulation' is dus een factor 5-6 trager, en het lijkt aan de installatie van Slack te liggen...

Iemand enig idee wat dit kan zijn?
Mocht je meer info willen, post het, ik zal het topic regelmatig bekijken.

Specificaties server:
P4 1,7Ghz
512mb PC2700 (Kingston)
WD 40gig 7200rpm schijf (8mb cache)
onboard Intel lan
Intel Pro 1000

Slack 9.0 met Apache 1.3.27 en PHP 4.3.1 (allemaal standaard nog dus)

[Wilke]

String manipulation, dat klinkt als een CPU-bound iets, toch?

Is er misschien iets mis met het geheugen? Een paar uur memtest86 draaien kan nooit kwaad bij zo'n server.

DMA op de harddisk staat ook aan? Niet dat ik denk dat dit invloed zou hebben op een string manipulation test, tenzij hij de strings van disk leest natuurlijk.

Wat zegt 'free' op het moment dat het systeem zo traag is? En als je tijdens de benchmark 'vmstat 1' laat draaien, zijn er dan ook regelmatig processen blocked for input of output (de kolom 'bi/bo'), of wordt er geswapped (si/so)?

Zijn er misschien IRQ conflicten (tja..je zou denken dat het niet meer voorkomt vandaag de dag) waardoor bv. de netwerkkaart als een anker aan de CPU hangt? Dat soort dingen zouden wel meldingen moeten veroorzaken in /var/log/messages, staat daar nog iets interessants in?

[duderuud]

Ik heb het geheugen uitvoerig gecontroleerd, geen problemen. Geheugen zat ook eerst in een andere server waar het prima werkte.

DMA moet ik controleren, zou niet weten hoe je dat onder Linux moet checken eigenlijk...ga ik mee aan de slag.
Free ed zal ik eens uitvoeren, kijken wat er gebeurd...

Free geeft goede waardes.

Het gekke is dus, dat er na één install wel goede waardes gegenereerd werden.
Ik zit dus haast te denken aan een bepaalde package ofzo die ik niet geïnstalleerd heb en die voor een hoop snelheid kan zorgen.
De server is dus in totaal 4 keer geïnstalleerd, waarvan 'ie één keer wel gewoon snel was...

[ Voor 37% gewijzigd door duderuud op 27-08-2003 10:31 ]

[Verwijderd]

Heb je toevallig een MSI moederbord in die bak zitten met een 845 chipset?

[ Voor 16% gewijzigd door Verwijderd op 27-08-2003 11:21 ]

[DeMoN]

Aangezien je niet weet hoe je DMA moet checken, zal je ook niet het programma hdparm kennen.

Ook al zal het niet de aard van je probleem zijn, het zal je hardeschijf misschien wel iets sneller maken.. lees dit eens:

http://linux.oreillynet.c...ux/2000/06/29/hdparm.html

[Kippenijzer]

Als je pc zo traag is, kan het dan zijn dat er nogal veel "zombie" processen van apache/php draaien, in zoverre dat misschien de php die je erop draait gewoon nogal crap gecode is? Dan gaat dat idd steeds voor meer traagheid zorgen...

[duderuud]

Verwijderd schreef op 27 August 2003 @ 11:20:
Heb je toevallig een MSI moederbord in die bak zitten met een 845 chipset?

Ja, inderdaad! Een MSI-845 GE MAX-L!

http://www.msi.com.tw/pro...ro_mbd_detail.php?UID=426

[Verwijderd]

Ow wat je dan moet doen is:

Bios flashen met laatste versie en daarna rebooten en in de bios het maximaale aantal mb aan je videokaart geven. Dit loste het op bij mij. Succes!

Edit:

Hmmz is ander type dan waar mee ik gewerkt heb... maar misschien toch een biosinstelling?

[ Voor 23% gewijzigd door Verwijderd op 27-08-2003 15:13 ]

[duderuud]

Laatse versie van de bios heb ik ook al geprobeerd.

Ik zal eens proberen de videokaart meer mb's te geven, staat nu op 1mb als ik het goed heb.

[duderuud]

apt-get thx man! Het verhogen van het videomem van 1mb naar 8mb was de oplossing!

Stringmanipulation-time is van 40 seconde naar 3,5 seconde gegaan

[Wilke]

Woei

Waarom zo weinig mem voor de videokaart, sowieso? Het is niet alsof je vandaag de dag die 64 MB AGP Aperture Size (ik neem aan dat het daar over gaat?) niet kunt missen...

Wel raar trouwens dat het iets uitmaakt, maargoed

[imdos]

Wilke schreef op 27 August 2003 @ 20:03:
Woei

Waarom zo weinig mem voor de videokaart, sowieso? Het is niet alsof je vandaag de dag die 64 MB AGP Aperture Size (ik neem aan dat het daar over gaat?) niet kunt missen...

Wel raar trouwens dat het iets uitmaakt, maargoed

Volgens mij gaat dit over een interne videokaart die het "normale" geheugen aanspreekt als buffer

[Verwijderd]

Klopt, die vga kaart zit intern volgens mij en spreekt dus gewoon het aantal mb van je repen aan. Alleen is het systeem bagger traag als je de minimum waarde toewijst aan het geheugen

[ Voor 32% gewijzigd door Verwijderd op 28-08-2003 11:12 ]

[Verwijderd]

Duderuud schreef op 27 August 2003 @ 19:55:
apt-get thx man! Het verhogen van het videomem van 1mb naar 8mb was de oplossing!

Stringmanipulation-time is van 40 seconde naar 3,5 seconde gegaan

[Slack9]Onverklaarbaar traag.. >> [Slack9]Onverklaarbaar snel

[Verwijderd]

Waarom is het systeem traag als je weinig MB's aan het video geheugen toewijst?
Echt logisch is dat niet...

[duderuud]

Ik snap er ook echt geen bal van. Ik dacht logisch te redeneren: Webserver->videokaart niet spannend->zo min mogelijk geheugen toewijzen aan de interne videokaart.

Zo blijkt maar weer, logisch beredeneren is soms niet verstandig op pc/servergebied