Iz naše kuhinje: Baze podataka

Svi vole da pričaju o tome kako preduzeća treba da budu “društveno odgovorna”. Uvek sam nekako bežao od te priče i trudio se da pređem pravo na dela – a jedan od najboljih načina je nešto što ovde volimo da zovemo “deljenje znanja”. IT kuća, a posebno ona koja živi od svojih korisnika, ima makar moralnu obavezu da bar deo saznanja o funkcionisanju sistema podeli sa svojim korisnicima, kao i sa celim svetom. To možda nije nešto što direktno pomaže većini korisnika, ali pomaže onima koji su u struci, a dodatno, takvim širenjem znanja pomaže stvaranju naprednijeg društva. Možda od toga nema nikakve direktne koristi, ali pomaže u stvaranju boljeg sveta za sve nas i za našu decu.

Kako se kolege na Limundo blogu već bave savetima u vezi sa PHP programiranjem, rešio sam da napišem lep “kuvar” o tome kako mi koristimo bazu podataka. Šta, kako i zašto radimo i šta je od toga korisno za sve. Moja omiljeno rešenje za serverski OS je CentOS Linux, a izbor baze je Percona. Razlog? Za razliku od standardnog (GA) MySQL-a koji Oracle deli besplatno, Percona XtraDB bolje skalira. Kada danas kupite (ili iznajmite) server na kome ćete držati bazu, on ima bar šest, a često i mnogo više jezgara. Na ovakvim platformama je InnoDB jedini razuman izbor, jer stari MyISAM engine još uvek nije u stanju da radi paralelno, tako da, ako još niste prešli – krajnje vam je vreme.

Kad smo već kod jezgara, način na koji je Linux kernel optimizovan nije najsrećniji kada se radi o radu samo jedne aplikacije. Kada je memorija na računaru podeljena između procesora, kao što jeste na svim modernim računarima (tzv. ccNUMA arhitektura), Linux pokušava da svaku aplikaciju zadrži na jednom delu memorije – i time na jednom procesoru. To, kada zamolite Linux da vam opiše izgled memorije, izgleda ovako:

# numactl –hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 12 13 14 15 16 17
node 0 size: 49124 MB
node 0 free: 47241 MB
node 1 cpus: 6 7 8 9 10 11 18 19 20 21 22 23
node 1 size: 49152 MB
node 1 free: 47311 MB
node distances:
node 0 1
0: 10 20
1: 20 10

Iako ovo ima smisla kada pokrećete više aplikacije u okruženju kada koristite samo jednu aplikaciju (bazu), dolazite do situacije da umesto da se sva memorija koristi za bazu, računar će ostaviti pola memorije slobodno, a softver koji radi na drugoj polovini će otići u swap – sve pokušavajući da izbegne pristupanje memoriji sa drugog procesora. Ovo se da rešiti na par načina, a po meni je najelegantniji onaj koji izbegava menjanje samog koda baze. Samo napravite jednu dodatnu skriptu, koja izgleda ovako:

#!/bin/sh

numactl=/usr/bin/numactl
mysqld=/usr/local/mysql/bin/mysqld

exec $numactl –interleave all $mysqld “$@”

I dodajte je ovako u my.cnf fajl:

[mysqld_safe]

ledir=/usr/local/bin
mysqld=mysqld_using_numactl

Rezultat će biti jednostavan – kernel će aplikaciji davati memoriju sa oba procesora ravnomerno, ujedno raspoređujući rad aplikacije između oba procesora.

Dodatno, kad ste lepo optimizovali rad sa memorijom – potrošite je. Na modernoj bazi, koja ima samo InnoDB tabele, slobodno stavite oko 80% memorije u InnoDB buffer pool. Ovo će doneti najveće ubrzanje u radu sa bazom, a radi se dosta lako – na računaru gore to izgleda ovako:

innodb_buffer_pool_size = 80G

Na kraju – rad sa diskom. Prva preporuka je da particija na kojoj je MySQL datadir bude obavezno pod xfs fajl sistemom. Dodatno, pre svega zbog lakšeg recovery procesa, ako vam neka tabela bude oštećena, podelite tablespace po tabelama baze, tako da svaka tabela ima svoj fajl. Konačno, koristite Direct I/O kao metodu flush-ovanja na disk, pre svega zbog pouzdanosti rada. Za to su vam potrebna još ova dva reda u my.cnf fajlu:

innodb_file_per_table

innodb_flush_method = O_DIRECT

Zajedno, ovih par kratkih optimizacija daje brži i pouzdaniji rad baze. Ubrzanja mogu biti dosta primetna u zavisnosti od toga kako ste pre toga radili, ali u svakom slučaju ovo su neke osnove koje ne bi trebalo da preskočite.