Kris Empfehlungen für mysql auf Solaris umgesetzt

Quicksearch

Disclaimer

The individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.

Navigation

< 100 Songs: Placebo - Running up that hill | LDOMs for T2000 >

Kris Empfehlungen für mysql auf Solaris umgesetzt

Monday, August 27. 2007

Ich habe mir mal die Anmerkungen von Kris zur Installation von mysql angeguckt und in OpenSolaris Speak umgesetzt:

zpool create mysqlpool mirror <erstes pärchen> mirror <zweites pärchen> ... log <ein mirror fuer separated log>
zfs set atime=off mysqlpool
zfs set blocksize=8k mysqlpool

root kommt in ein UFS. ZFS ist ja leider noch nicht bootfähig. Kommt noch. Über die Aufteilung der Partitionen mus man sich keine Gedanken machen. Wer das allerletzte an Performane rauskitzeln will kann noch data und log in unterschiedliche pools trennen, aber das seperated log macht das weitestgehend unnötig.

Der Hinweis mit dem Thinwidestriping ist auch für ZFS gültig. Datenbanken mögen das wirklich. Deswegen hassen DBA auch 500 GB Platten. Die sind aber garnicht so schlimm, wenn man viele davon hat. Eine X4500 "Thumper" ist daher eine sehr nette Datenbankmaschine.

Ein Hinweis für mysql und Solaris: Meiner Erfahrung nach ist libumem für mysql eine verdammt gute Idee ... also ins Startup

setenv LD_PRELOAD_64 /usr/lib/sparcv9/libumem.so

eintragen.

Posted by Joerg Moellenkamp in German at 07:22 | Comments (6) | Trackbacks (0)

Defined tags for this entry: solaris

Related entries by tags:

View as PDF: This entry | This month | Full blog

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

Was ist mit Copy-on-Write? Das sollte man bei ner Datenbank doch dringend abschalten, oder? Wie geht das?

#1 Olli on 2007-08-27 10:12 (Reply)

Wenn die Blocksize der Datenbank identisch groesser der Blocksize des Filesystems ist, dann ist genau das kein problem. Du willst sogar genau das, weil dadurch auch das entgültige Schreiben auf die Platte linearisiert werden und nicht nur die Schreibzugriffe auf das Mysql-Log

#1.1 Joerg (Homepage) on 2007-08-27 11:03 (Reply)

also der Kollege hier (http://dimitrik.free.fr/db_STRESS_BMK_Part2_ZFS.html) erreicht nach vielen Optimierungen gerade mal 100% der UFS Performance auf einem ZFS (für seine Tests) - gibts da nen aktuelleren Stand? Da es auch noch ne Menge Bugs gibt und gab (stichwort aggressive ZFS Cache allocation eating up memory) ist ja die Frage ob man das schon "produktiv" einsetzen sollte.

#2 El Burro (Homepage) on 2007-08-27 11:34 (Reply)

Ich beantworte es mal so: Eine ganze Reihe unserer Kunden hat es bereits im Einsatz.

Zu dem Benchmark: Zum einen beruecksichtigen die Benchmarks noch nicht das separated ZIL, zum anderen sind die Werte im vergleich zu direct i/o zu sehen. Da aggressive Cache allocation kann man sehr gut unter kontrolle bringen. Siehe dazu auch solarisinternals.com wiki.

#2.1 Joerg (Homepage) on 2007-08-27 13:26 (Reply)

Ich gehe mal davon aus das es sich bei den 500GB Platten um SATA handelt. Viel hilft zwar bekannt viel, aber SATA ist IMHO für den Bereich nicht wirklich ausgelegt. SATA Platten hassen kleine random I/Os, wie sie ja nun mal gerade bei DBs vorkommen, wie die Pest. Dafür sind die Dinger auch nicht ausgelegt (Arme, Köpfe, Lager, Drehzahlen usw.). SATA macht Spaß bei langen sequentiellen I/Os, wie z.B. bei Backup-2-Disk, aber bei viel random I/O würde ich immer noch SCSI bzw. SAS Platten vorziehen, vorzugsweise 2,5", 15k UPM: Dreht schneller, kleinere Platten, kürze Seektime als 3,5" und von der Lebensdauer her stehen die den großen auch ins nichts nach - vor allem keiner SATA.

Just my 2 Cent.

#3 Patrick (Homepage) on 2007-08-29 12:03 (Reply)

Also, es gibt auch SATA-Platten in vernünftiger Qualität. Die Platten in der Thumper sind nicht Consumerqualität. Wir verwenden die Maschine durchaus für Datenbanken. Vornehmlich im Datawarehousing. Aber du hast recht, schwerlast/random-i/o wuerde ich da auch nicht draufpacken ....

#3.1 Joerg (Homepage) on 2007-08-29 18:35 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	E-Mail addresses will not be displayed and will only be used for E-Mail notifications. To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above: Standard emoticons like :-) and ;-) are converted to images. Enclosing asterisks marks text as bold (word), underscore are made via _word_.
	Remember Information? Subscribe to this entry