/u/911/tux-extreme2.png?f=community)
We hebben hier een aantal vrij goedkope, kleine diskless Celerons staan die we gebruiken voor klanten die een eigen server willen maar geen enorm zware applicaties/sites gaan draaien. Werkte tot nu toe allemaal erg goed. Ding boot via netwerk, start linux op door root van NFS server te mounten, allemaal erg leuk en makelijk met onderhouden.
Dit ging goed tot de server van een drukke site (www.bokt.nl) dood ging (bleek rot geheugen te zijn) en we ook ruimte nodig hadden in ons 19" rack. Server (4u) is dus verwijdered en de site is naar de NFS server gekopieerd. Of ja, de PHP files plus wat statisch spul, overgrote deel van de site staat in een database op de database server.
Ging allemaal niet echt geweldig
Die Celerons zijn geen snelheids monsters hadden meer redelijk wat meer Mhz dan de Athlon waar de site op heeft gedraait maar ik gok dat de inimienie 1st level cache van die Cellies nogal wat problemen geeft. We hebben er dus maar een extra diskless doos bijgepakt. Wat CPU betreft gaat het nu (redelijk).
Er ontstonden echter behooooorlijk wat problemen met het NFS verhaal. Performance problemen om precies te zijn. Gelukkig nog geen rare locking problemen gehad
Eerste wat we gedaan hebben is het overgrote deel van de site naar /dev/shm/ kopieeren. Probleem is dat /dev/shm/ ook van een NFS mount komt dus als Apache daar iets mee doet komt er telkens een lstat64() voor /dev/ en /dev/shm/ voorbij, iig in strace. Maar op zich lijkt het wel wat verschil te maken. Ik heb ook eens met tcpdump zitten kijken wat er nou allemaal gebeurt en je ziet vooral heeeeeeeeeel veel 'getattr' voorbij komen:
(client->server) 116 getattr fh Unknown/1 (DF) (ttl 64, id 0, len 144)
(server->client)reply ok 96 getattr DIR 41777 ids 0/0 sz 4096 (DF) (ttl 64
, id 0, len 124)
En dat heel, heel vaak. Geen idee waar dat allemaal vandaan komt zeker omdat NFS volgens de mount opties alles een redelijke tijd mag cachen. Een ander ding dat opvalt is dat er enorm veel diskverkeer is op de NFS server. Het netwerkverkeer valt op zich best mee (700KB/s waarvan 99% NFS verkeer). Op de disk is het meestal iets tussen de 3000 en 6000 KB/s van en naar de disk, afhankelijk van hoe druk het is op de site. Geen flauw idee wat dat allemaal voor een verkeer is. Volgens 'sar -b' zitten we op iets van 300 transacties/seconde op de disk (RAID1 IDE).
Is er een soort van 'tcpdump' maar dan voor de disk? Ik ben _erg_ benieuwd wat die disks nou allemaal zo druk aan het doen zijn en vooral met welke files. Dat maakt het een heel stuk eenvoudiger om te kijken waar we ons op moeten focussen om alles sneller te krijgen
Dit ging goed tot de server van een drukke site (www.bokt.nl) dood ging (bleek rot geheugen te zijn) en we ook ruimte nodig hadden in ons 19" rack. Server (4u) is dus verwijdered en de site is naar de NFS server gekopieerd. Of ja, de PHP files plus wat statisch spul, overgrote deel van de site staat in een database op de database server.
Ging allemaal niet echt geweldig
Die Celerons zijn geen snelheids monsters hadden meer redelijk wat meer Mhz dan de Athlon waar de site op heeft gedraait maar ik gok dat de inimienie 1st level cache van die Cellies nogal wat problemen geeft. We hebben er dus maar een extra diskless doos bijgepakt. Wat CPU betreft gaat het nu (redelijk).Er ontstonden echter behooooorlijk wat problemen met het NFS verhaal. Performance problemen om precies te zijn. Gelukkig nog geen rare locking problemen gehad
Eerste wat we gedaan hebben is het overgrote deel van de site naar /dev/shm/ kopieeren. Probleem is dat /dev/shm/ ook van een NFS mount komt dus als Apache daar iets mee doet komt er telkens een lstat64() voor /dev/ en /dev/shm/ voorbij, iig in strace. Maar op zich lijkt het wel wat verschil te maken. Ik heb ook eens met tcpdump zitten kijken wat er nou allemaal gebeurt en je ziet vooral heeeeeeeeeel veel 'getattr' voorbij komen:
(client->server) 116 getattr fh Unknown/1 (DF) (ttl 64, id 0, len 144)
(server->client)reply ok 96 getattr DIR 41777 ids 0/0 sz 4096 (DF) (ttl 64
, id 0, len 124)
En dat heel, heel vaak. Geen idee waar dat allemaal vandaan komt zeker omdat NFS volgens de mount opties alles een redelijke tijd mag cachen. Een ander ding dat opvalt is dat er enorm veel diskverkeer is op de NFS server. Het netwerkverkeer valt op zich best mee (700KB/s waarvan 99% NFS verkeer). Op de disk is het meestal iets tussen de 3000 en 6000 KB/s van en naar de disk, afhankelijk van hoe druk het is op de site. Geen flauw idee wat dat allemaal voor een verkeer is. Volgens 'sar -b' zitten we op iets van 300 transacties/seconde op de disk (RAID1 IDE).
Is er een soort van 'tcpdump' maar dan voor de disk? Ik ben _erg_ benieuwd wat die disks nou allemaal zo druk aan het doen zijn en vooral met welke files. Dat maakt het een heel stuk eenvoudiger om te kijken waar we ons op moeten focussen om alles sneller te krijgen
/u/36978/icon.JPG?f=community){kind=icon}
Verder werkt die oplossing natuurlijk niet op servers die geen NFS gebruiken.
Ander dingetje is dat je op die manier niet ziet hoevaak bestanden geschreven worden (maar het zou idd wel meer info geven dan we nu hebben).:strip_exif()/u/24090/hekje.gif?f=community)
/u/13471/karnemelk.png?f=community)