Verschillende prestaties op vrijwel identieke machines

[Confusion]

Ik heb twee machines die gelijk zijn qua hardware en vrijwel identiek qua software. Een Python script waarmee ik data importeer van de machine naar een MySQL database op een andere machine is op de ene machine in een uur klaar, terwijl het er op de andere machine meer dan tien keer zo lang over doet. De vraag is: waarom?

Specs die overeenkomen tussen beiden machines:
- Pentium D 3.4 Ghz
- 2 GB RAM
- Debian Etch
- Kernel 2.6.18-5-686 SMP
- Python 2.4.4
- Apache 2.2.3-4
- Tomcat 5.5.20-2
- Load onder de : 0.1 0.1 0.1
- Minimale hoeveelheden requests richting Apache/Tomcat (de een is een teserver, de andere een nog niet in gebruikgenomen productieserver)

De tragere server:
- draait een MySQL slave
- is via een firewall met de MySQL master verbonden, waar de data ook in wordt gestopt

De snellere server:
- is rechtstreeks met de MySQL server verbonden.

De respectievelijke MySQL servers staan allebei uit hun neus te vreten en de MySQL server waar de tragere server mee verbonden is, heeft, zeg maar, 2x de hardware van de ander.

Kortom: what gives?

[mOrPhie]

Heb je naar de DMA-waardes gekeken? Ik weet niet hoe de bron-data aangeleverd wordt, maar als dat FS-intensieve bewerkingen zijn, dan zou ik het aan die kant gaan zoeken.

[Confusion]

Beide machines hebben twee 500 GB SATA schijven in Raid-1 draaien. In /proc, /sys en de 3com cli is niets vinden over DMA instellingen, maar volgens mij klopt dat ook voor SATA.

De data wordt van het filesystem gelezen en ter voorbereiding worden er wat files bewerkt, maar het grote verschil in snelheid zit hem in het verwerken van de data: er wordt in een uur tijd misschien 100 MB van schijf gelezen, dus lees/schrijf traagheid kan het niet verklaren.

[Hertog]

Aangezien het enige verschil in de verbinding zelf zit, lijkt het op een netwerkprobleem. Gooit de firewall roet in het eten, of is er iets anders met die verbinding aan de hand? Kun je eenvoudig een kabeltje omzetten om te kijken of het verschil blijft, of is dat te lastig?

[Verwijderd]

Confusion schreef op woensdag 12 september 2007 @ 12:32:
De tragere server:
- draait een MySQL slave
- is via een firewall met de MySQL master verbonden, waar de data ook in wordt gestopt

De snellere server:
- is rechtstreeks met de MySQL server verbonden.

De respectievelijke MySQL servers staan allebei uit hun neus te vreten en de MySQL server waar de tragere server mee verbonden is, heeft, zeg maar, 2x de hardware van de ander.

Kortom: what gives?

Lijkt mij dat je op de tragere server meer I/O hebt omdat je daar data in je locale mysql db stopt (gezien deze tekst waar de data ook in wordt gestopt) ?
Je draait namelijk ook nog 's raid-1 (soft of hardware matig?)


Kijk eens met saidar tijdens het uitvoeren wat de schijfactiviteit en proc activitieit is op beide machines

[ Voor 11% gewijzigd door Verwijderd op 12-09-2007 13:38 ]

[Confusion]

@Hertog:
Dat is lastig; het hangt allemaal ergens ver weg in een rack .

Firewalling gebeurt middels iptables; de firewall heeft ook geen noemenswaardige load en de verbindingen tussen MySQL server en firewall, cq. import machine en firewall zijn goed (als in: scp haalt hoge doorvoersnelheden en er treden geen fouten in overgezette bestanden op).

MySQL user checking gebeurt ook op dezelfde manier: de user waaronder de data in de database gestopt wordt heeft toegang op basis van de herkomst (by IP en hostname) en de doeldatabase.

Verwijderd schreef op woensdag 12 september 2007 @ 13:36:
Lijkt mij dat je op de tragere server meer I/O hebt omdat je daar data in je locale mysql db stopt (gezien deze tekst waar de data ook in wordt gestopt) ?

Nee, daar is ook sprake van een losse database server, alleen is de configuratie daar:

internet -- 'snelle' server -- DB server

,
terwijl de andere config is:

internet -- firewall -- DB server
                 |                  
           'trage' server

Je draait namelijk ook nog 's raid-1 (soft of hardware matig?)

Hardwarematig (3Com 8006-2 controller)

[ Voor 39% gewijzigd door Confusion op 12-09-2007 13:41 ]

[Confusion]

Ik ga vandaag even een Python profiler op de code loslaten op beide machines; eens kijken wat daar uitkomt.

Edit:
Duidelijk, de bottleneck zit in de commits. Daar gebeuren er nogal wat van. Heb nu de mysql parameter
innodb_flush_log_at_ trx_commit op 2 gezet en daarmee is het geheel meteen een factor tien sneller. De live omgeving was bijna net zo snel als de dev omgeving.... tot ik daar ook
innodb_flush_log_at_ trx_commit = 2 deed. Nu is de development omgeving twee keer zo snel als de live omgeving. Het blijft mysterieus...

[ Voor 67% gewijzigd door Confusion op 13-09-2007 16:51 ]

[Confusion]

Nog een update hierop: controller cache aanzetten op de raid controller wil ook nog weleens helpen... hoewel die niet battery-backed is, dus dat een extra integriteitsrisico vormt. Dat versnelt de productieomgeving weer met een factor 2. Het verschil tussen de twee omgevingen wordt daarmee weer kleiner, maar de testomgeving is nog steeds ongeveer 20% sneller dan de productieomgeving.