OS, FS, Scheduler

Linux

2.4 vs 2.6, NPTL vs LinuxThreads

U nekim slucajevima 2.4 je brzi u nekim slucajevima 2.6, razlikuje se od sistema do sistema. Nekada cak ima razlike i od distribucije do distribucije. NPTL implementacija na linuxu je jos uvek bagovita ali trenutno u vecini slucajeva radi dobro.

Neke univerzalne smernice

• Izbegnite swap
  • koristite –memlock
  • koristite O_DIRECT za InnoDB
  • setujte /proc/sys/vm/swappiness na 0
  • na nekim kernelima /proc/sys/vm/pagecache ima min/avg/max pagecache koji moze da se koristi za kontrolu swappinga
• iskljucite SELinux ako vam ne treba, to moze da dovede i do 7% ubrzanja
• podesite read-ahead ili disk IO scheduler (ls /sys/block/hda/queue/; cat /sys/block/hda/queue/scheduler). na nekim sistemima (RHAS na primer) ne mozete online da menjate scheduler vec morate to da dodate kao kernel opciju pri boot-u
• Zavisno od sistema, razlicite stvari mogu da se nasetuju na file system-u
  • iskljucivanje NOATIME flega pri mountovanju particije sa podacima u slucaju veceg broja MyISAM tabela ili file_per_table opcije InnoDB storage engine-a
  • za reiserfd i ext3 data=writeback je odlicna opcija za particiju sa InnoDB tablespace-om, za MyISAM tabele nije dobra posto dodaje „smece“ na kraj fajla
  • za reiserfs koristiti opciju NOTAIL

Solaris

Neke generalne smernice

• koriscenje tmpfs za privemenefajlove moze doneti ubrzanje ako ima dovoljno memorije posto je tmpfs u ram-u
• setiovanje „sticky bit“-a za fajlove gde su MyISAM tabele
• forcedirectio parametar za particiju gde je InnoDB table space

Windoze

Zaposlite pravog sistem administratora i instalirajte MySQL na pravi operativni sistem

Storage Engine

InnoDB

• innodb_buffer_pool_size – 70-80% ukupnog RAM-a na sistemima koji su pretezno InnoDB, manje na mix sistemima
• innodb_flush_method=O_DIRECT da bi izbegli duplo kesiranje pristupa disku
• innodb_log_file_size – 256M do 1GB. Veca vrednost povecava performanse ali drasticno usporava „recovery time“ tj. vreme koje je mysql-u potrebno da izvrsi „oporavak“ innoDB table space-a posle „nasilnog“ prekida rada. Ako koristite velike blobove, jako je bitno da ovaj parametar ima „vecu“ vednost
• innodb_log_buffer_size – 4-8M
• innodb_thread_concurrency – 2*(broj_cpu_jezgara+broj_spindlova), ili manje. Kako MySQL ima problem sa skaliranjem, u nekim slucajevima vrednost 1 ce doneti bolje performanse
• innodb_thread_sleep_delay – sa ovim treba experimentisati, nekad ce vrednost niza od default vrednosti doneti poboljsanja

MyISAM

• key_buffer_size – staviti na 25-35% od ukupne kolicine RAM-a na pretezno MyISAM sistemu
• bulk_insert_buffer – povecati na „malo vise“ od bulk inserta koji uobicajeno izvrsavate ali nikako ne na vrednost vecu od key_buffer_size
• myisam_sort_buffer_size – ovaj parametar je bitan za brzinu „repair table“ komande, vrednost ne treba da bude preko 64M
• myisam_max_sort_file_size – 8-30M
• low_priority_updates – koristiti ako postoji veliki broj dugih select-ova koji budu blokirani insertima/update-ima
• concurrent_insert – 2

Globalne varijable

• sort_buffer_size – povecavati polako ako ima previse sort_merge_passes proveravati posle svake promene da li ubrzava performanse. Vrednost od 1-8M je uglavnom idealna zavisno broja konekcija i opterecenosti. Ako je potrebna veca vrednost od 8M postavite je u konekciji, samo za tu sesiju gde je potrebna umesto globalno za ceo server
• tmp_table_size – ovaj parametar je bitan za velike „group by“ i joinove koji koriste temporary tabele. Obratiti paznju da created_tmp_disk_tables raste ne samo ako je tmp_table_size premali vec i ako se koriste blob/text kolone ili ako je ukupna velicina sloga veca od 512 bajtova, u tom slucaju MySQL koristi temporary tabele na disku bez obzira na tmp_table_size; Ako je to slucaj a imate dovoljno RAM-a, setovanje tmp file systema kao tmpfs (na ram disku) ce znatno ubrzati ovakve upite
• max_length_for_sort_data – vrlo kompleksan parametar, moze dosta da utice na performanse ali zavisno od tipa podataka i tipa upita veca ili manja vrednost ce povecati performanse
• query_cache – Obratiti paznju da se svaki put kada se radi insert/delete/update ceo sadrzaj query cache-a invalidatizuje kako bi se izbacili „outdated“ rezultati. Na sistemu koji ima veliki broj select-a i mali broj inserta/update/delete-a vrednosti do 1G mogu doneti mnogo na performansama, sa velikim brojem insert/delete/update-a moze se koristit hinting i u svakom slucaju „manji“ query cache .. 1-10M

Razno

• Memorija je bitna, sto vise memorije to bolje
• Ako imate procesor koji moze da radi u 64 bitnom modu, koristite ga u 64bitnom modu
• Hyper Threading pomaze
• SCSI i SAS je i dalje brzi od svega ostalog
• HDD kontroleri sa battery bekapom nisu skupi
• NAS ne radi kako treba
• SAN nije nista brzi od lokalnih diskova

MySQL Enterprise Monitor

Merlin (MySQL Enterprise Monitor & query analyzer) nije free, nije open source ali je BESNO DOBAR i koristan proizvod. Enterprise monitor prati real time sta se desava sa vasom bazom, kakvi upiti, kako mysql koristi indexe, bafere, kesheve … dodatno moze i da analizira vase querie… te podatke cuva i prikazuje u vidu razlitih grafikona i na sve to analizira te podatke i daje savete koji parametar i zasto da promenite da bi izbegli ovaj ili onaj problem / poboljsali performanse ovako i onako … Mnooooooooogo dobar alat, bas bas bas dobar