[Debian] 2 dezelfde servers - verschillende performance

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

  • MAX3400
  • Registratie: Mei 2003
  • Laatst online: 27-09 22:07

MAX3400

XBL: OctagonQontrol

Topicstarter
Mijn eerste topic in NOS; hopelijk maak ik er wat van want ben nog niet zo enorm thuis in de terminologie.

Goed, ik heb 2 servers draaien met Debian 64-bit. De ene server is qua hardware aanzienlijk minder bedeeld dan de andere (2-core vs. 6-core en 2GB RAM vs. 16GB RAM). Verder zijn de servers beiden voorzien van 2 SATA-disks die in RAID0 draaien. Beiden hebben lighttpd draaien, standaard installatie zonder SSL, met dezelfde inhoud voor /var/www. Ook draait pure-ftpd, met SSL, en nog wat andere zaken.

Op verschillende vlakken kom ik, eigenlijk direct na de installatie, al verschillen tegen in de performance waarbij het op dit moment voornamelijk op gevoel is dan dat ik daadwerkelijk "kan" meten.
  • SSH input/output is gelijk; geen lag of andere zaken die vertraagd zijn.
  • FTP over SSL gaat ook gelijk; transfer-snelheden zowel bij up- als download zijn gelijk tot ongeveer 9MB/s.
  • wget commando's geven op de grotere server toch lagere snelheden; gemiddeld 20% lager dan de kleine server bij hetzelfde aantal wget's.
  • Lighttpd is ongelijk; de server met minste resource serveert alles het snelste af, zeker als het om dynamische content gaat (zoals grafiekjes van vnstat-frontend)
  • Disk I/O is ook in het voordeel van de kleinste server. Een test met rtorrent, 100GB aan data (in verschillende mappen, RAR-sizes etc), levert een snellere rehash op op de kleine server dan de grote server; het scheelt ongeveer 3MB per seconde lezen/hashen (geconstateerd via screen -x rtorrent).
Om bepaalde zaken te meten of uit te sluiten, ben ik al heel hard op zoek om lighttpd een eigen memory-space te geven, memcaching aan/uit te zetten en compressies wel/niet aan te zetten etc. Voor wat betreft de NICs ga ik IPv6 in ieder geval uitschakelen en controleren (waar?) of de sent/receive buffers wel correct zijn.

Maar in essentie heb ik toch het gevoel dat mogelijk de grootste verbetering in de disks zit; alleen geen idee hoe ik dit ga meten, en belangrijker, na een meting een zinnige aanpassing maak in een bepaalde conf of iets dergelijks.

Enige hulp wordt erg op prijs gesteld... :)

Mijn advertenties!!! | Mijn antwoorden zijn vaak niet snowflake-proof


Acties:
  • 0 Henk 'm!

  • H!GHGuY
  • Registratie: December 2002
  • Niet online

H!GHGuY

Try and take over the world...

Meten is weten. Tijd dus om te benchmarken.

Eens je resultaten hebt kunnen suggesties gegeven worden over wat mogelijke oorzaken zijn, maar tot dan zet ik mijn glazen bol niet aan voor zo'n futiliteit.

ASSUME makes an ASS out of U and ME


Acties:
  • 0 Henk 'm!

  • Kees
  • Registratie: Juni 1999
  • Laatst online: 21:46

Kees

Serveradmin / BOFH / DoC
wat zijn de kloksnelheden van de verschillende core's?

"Een serveradmin, voluit een serveradministrator, is dan weer een slavenbeheerder oftewel een slavendrijver" - Rataplan


Acties:
  • 0 Henk 'm!

  • Rainmaker
  • Registratie: Augustus 2000
  • Laatst online: 14-07-2024

Rainmaker

RHCDS

Aangezien je vooral op disk I/O blijkbaar verschil ziet zou het zomaar kunnen dat je tegen ZCAV aanloopt.

Draai eens bonnie++, of zcav.

"Defragmenteren" (repacken, in de linux wereld) zou dan moeten helpen.

Check ook of het dezelfde SATA disken zijn in beide servers, en vergelijk de BIOS'sen een keer.

We are pentium of borg. Division is futile. You will be approximated.


Acties:
  • 0 Henk 'm!

  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 13:38

deadinspace

The what goes where now?

MAX3400 schreef op dinsdag 09 november 2010 @ 11:27:
Goed, ik heb 2 servers draaien met Debian 64-bit. De ene server is qua hardware aanzienlijk minder bedeeld dan de andere (2-core vs. 6-core en 2GB RAM vs. 16GB RAM).
Ze draaien allebei ook daadwerkelijk amd64 Debian? Bij i386 kunnen grote hoeveelheden geheugen (met name >4GB) aanzienlijk trager zijn.
FTP over SSL gaat ook gelijk; transfer-snelheden zowel bij up- als download zijn gelijk tot ongeveer 9MB/s.
Over wat voor verbinding gaat dat? Ik vind 9 MB/s eigenlijk traag, ervanuitgaande dat dat over een lokaal 100 MBit ethernet netwerk is. 11 MB/s zou toch makkelijk te halen moeten zijn.
wget commando's geven op de grotere server toch lagere snelheden; gemiddeld 20% lager dan de kleine server bij hetzelfde aantal wget's.
Nogmaals, vanaf waar? Over wat voor verbinding? Hangen beide servers bij elkaar, of hangen ze aan verschillende verbindingen?
Lighttpd is ongelijk; de server met minste resource serveert alles het snelste af, zeker als het om dynamische content gaat (zoals grafiekjes van vnstat-frontend)
Benchmark je dat vanaf een andere machine? Zo ja, benchmark dan eens vanaf de server zelf, dan sluit je netwerk throughput uit.

Heeft die machine het verder nog druk met andere dingen? Kijk eens naar top, iotop, ps auxf, etc.
Disk I/O is ook in het voordeel van de kleinste server. Een test met rtorrent, 100GB aan data (in verschillende mappen, RAR-sizes etc), levert een snellere rehash op op de kleine server dan de grote server; het scheelt ongeveer 3MB per seconde lezen/hashen (geconstateerd via screen -x rtorrent).
RAID-0 schrijf je, maar wat voor RAID-0? Wat voor schijven?

En 3 MB/s op hoeveel? Hebben we het over 90 vs 93 MB/s, of 3 vs 6?
Om bepaalde zaken te meten of uit te sluiten, ben ik al heel hard op zoek om lighttpd een eigen memory-space te geven
Een wat? :P

Acties:
  • 0 Henk 'm!

  • Thc_Nbl
  • Registratie: Juli 2001
  • Laatst online: 21-05 22:24
2-core vs. 6-core?

appels en peren kan je toch ook niet vergelijken.
Zijn de CPU snelheden gelijk.
stel de 2core = 3Ghz
en de 6 core = 2.4 Ghz.

Dan is de 2core sneller dan de 6 core.
ook met je IO e.d. heeft het aantal Hz invloed.
Dat heeft op alles invloed.

[ Voor 5% gewijzigd door Thc_Nbl op 10-11-2010 11:24 ]

ehhh.. noppes

Pagina: 1