Woodcrest VEEL langzamer dan Opteron, wat gaat er mis?

[Verwijderd]

Hoi,

We hebben twee webservers::

Webserver 1: dualcore Opteron 2,00 Ghz, 2 Gb ram
Webserver 2: quadcore Xeon 2,33 Ghz, 4 Gb ram

Je zou denken dat webserver 2 wat meer capaciteit heeft maar nee, hij bleek VEEL langzamer te gaan met MySQL en dat is het voornaamste waar de servers mee bezig zijn. Ik kan het helaas niet bechmarken maar op de Opteron geen probleem en op de Xeon wordt de database heel rap unresponsive als er een paar (honderd) gebruikers tegelijkertijd iets willen weten. Wie snapt dit?

Ze draaien beide FreeBSD 6.2 (amd64) en MySQL 5.0.37.
95% procent van wat ze moeten doen is databasewerk: queries uit een database van ongeveer een 1 Gb trekken, daarbij staat ook nog eens de helft van de data in een MyISAM tabel (I know, niet optimaal maar daar kan ik nu even niks aan doen)

Precieze specs:
Webserver 1: 2 x 2,00 Ghz singlecore Opteron, 4x 512 Mb DDR ram (ik geloof @ 333 Mhz maar zou ook 400 kunnen zijn), 1 x 300 Gb 10.000 rpm SCSI
Webserver 2: 1 x 2,33 Ghz quadcore Xeon E5345, 2x 2 Gb DDR2 ram @ 667 Mhz, 1 x 150 Gb 10.000 rpm SATA

Het eerste wat ik dacht is dat het de harde schijf was, maar toen heb ik op de tweede webserver de hele database in een memory disk geladen. Dat ging sneller, maar nog steeds langzamer dan op de andere server!

MySQL als pregecompileerd package gebruikt (dat was 5.0.27), zelf gecompileerd met allerlei opties maar dat hielp niet (phthteads gaf helemaal dramatische performance maar dat is de verwachten gezien de table locks van MyISAM). Instellingen in my.cnf zoals thread concurrency en max connections deden ook niks merkbaars.

Zou het dan echt zijn dat Opteron voor deze specifieke toepassing zo veel sneller is?

[ACM]

Ik betwijfel of je quadcore langzamer is dan je opteron opstelling. Anderzijds zou ik in dit geval ook weer niet echt hogere resultaten verwachten van je 2e oplossing, maar veeel langzamer zou het zeker niet mogen zijn. Maar wij zijn tegen twee soorten beroerde schaling in MySQL aangelopen. In onze eigen benchmarks (met linux en solaris) hebben we wisselende resultaten gekregen uit de alle systemen, meer dan 4 cores maakt de performance vaak niet veel beter of soms zelfs slechter. Daarnaast neemt de performance ook behoorlijk sterk af bij meerdere concurrent clients.
De door ons geteste dual quadcore 2.66Ghz was volgens mij echter wel in alle gevallen sneller dan onze dual dualcore opteron-resultaten en ook in veel gevallen sneller dan quad dualcore opterons en de single quadcore was bijna even snel als de dual dualcore 2.66Ghz (en die was ruim sneller dan vergelijkbare opterons). Een van de belangrijkste redenen van beroerde performance (negatieve schaling in innodb locking) is ergens tussen 5.0.27 en 5.0.31 opgelost, dus ruim voor jouw versie 5.0.37.

Er zijn diverse resources nu online die suggereren dat MySQL baat kan hebben bij bepaalde patches voor freebsd, o.a. deze van een FreeBSD-devver. Maar echt gevolgd heb ik dat niet.

Er kan natuurlijk meer aan de hand zijn, het kan zijn dat je bepaalde settings sub-optimaal hebt voor de quadcore oplossing - maar welke moet je mij niet vragen, of dat myisam's full table locks, de globale locks op de query cache, etc, etc, veel grotere issues zijn geworden doordat er meer threads tegelijk aan de slag zijn.
In zowel Linux (met wat echo's naar files in /sys) als Solaris (met psradmin) is het mogelijk cpu's naar keuze voor de scheduler on-the-fly live uit te zetten, bijvoorbeeld de complete tweede core van elke socket. Zoiets kan vast in FreeBSD ook wel? Op die manier zou je kunnen nagaan of je wellicht tegen negatieve schaling in MySQL (of je webserversoftware) aan loopt. Als ie met minder cores beter werkt weet je dat je het in die hoek moet zoeken.

[ Voor 6% gewijzigd door ACM op 05-04-2007 17:59 ]

[Verwijderd]

Die patches zijn helaas nog lang niet voor de stabiele versies van FreeBSD. Volgens mij is in FreeBSD met de kern.threads.virtual_cpu sysctl variabele in te stellen hoeveel cores gebruikt worden. Ik durf daar eigenlijk niet aan te zitten op een remote server dus dat kan ik niet meteen testen.

Maar zou de MySQL thread_concurrency optie niet hetzelfde resultaat moeten geven? De andere cores kunnen dan nog steeds wel threads van andere programma's draaien maar dat maakt niet uit, het is zeker dat het probleem bij MySQL ligt. Of maak ik hier een denkfout?

Waarom gebruiken jullie trouwens MySQL als PostgreSQL zoveel beter schaalt? Pgpool-II ziet er ook veelbelovend uit. Of is het gewoon een kwestie dat er dan nog heel veel aan de software gesleuteld moet worden om het over te kunnen zetten?

[ Voor 26% gewijzigd door Verwijderd op 05-04-2007 21:29 ]

[ACM]

Verwijderd schreef op donderdag 05 april 2007 @ 21:08:
Maar zou de MySQL thread_concurrency optie niet hetzelfde resultaat moeten geven? De andere cores kunnen dan nog steeds wel threads van andere programma's draaien maar dat maakt niet uit, het is zeker dat het probleem bij MySQL ligt. Of maak ik hier een denkfout?

Ik weet niet of je een denkfout maakt, maar het is wel vreemd dat je twee 4-cpu systemen hebt waarvan de ene met vergelijkbare instellingen ineens niet goed werkt, terwijl de schaling van het Xeon-platform op zich nou niet zo veel beroerder is dan die van de opteron en de xeon zowel klok-voor-klok sneller is als meer kloktikken per seconde maakt.

Waarom gebruiken jullie trouwens MySQL als PostgreSQL zoveel beter schaalt? Pgpool-II ziet er ook veelbelovend uit. Of is het gewoon een kwestie dat er dan nog heel veel aan de software gesleuteld moet worden om het over te kunnen zetten?

Dat laatste is een heel belangrijke reden ja. Denk dat we zeker wel een maand of wat kwijt zijn voor het goed en wel draait, die benchmark van ons laat heel veel code buiten beschouwing (zoals de complete backend) en in die delen zitten aardig wat mysql-only constructies.

Bovendien is onze belasting normaliter met relatief weinig concurrent threads op de database, met als gevolg dat we eigenlijk niet eens zo veel beter af zouden zijn op pure prestaties voor het grootste deel van de tijd.