✉️ Saņem šito visu e-pastā. Tā vietā, lai palaistu garām kaut ko no tā, ko es rakstu savā blogā, tagad vari pierakstīties un saņemt e-pastā visu, ko es te rakstu. Tas nav bieži.

← Uz sākumu

Vai MySQL spēj dot analīzes?

2010. gada 10. februārī, 25 komentāri

Kamēr Tavs mazais blodziņš vai e-veikaliņš lēnām vago interenta āres ar saviem tris simtiem apmeklētāju dienā, nav par ko uztraukties. Bet, ja Tavam MySQL serverim ir savi daži simti pieprasījumi sekundē, no kuriem daudzi nav optimizēti dažādu apstākļu sakritības rezultātā, ir vērts sākt domāt. Provēt izrakt visu dažādas kvalifikācijas un dažādu cilvēku desmit gadus rakstīto kodu? Vai varbūt tomēr pieķerties lietai no otra gala?

MySQL ir milzums konfigurācijas parametru, ar kuru palīdzību atkarībā no servera izmantošanas veida var panākt milzīgu ātrdarbības pieaugumu. It sevišķi tas attiecas uz InnoDB. Ja esi nolēmis nopietni pie tā piestrādāt, tad nāksies vien ieguldīt darbu izpētē. Metodoloģija, protams, ir ļoti garš un plašs stāsts, savukārt, analīzei un paša servera uzturēšanai ir pieejami diezgan daudz labi rīki.

Manuprāt viens no labākajiem rīkiem ir vienmēr būs laba grāmata. Un MySQL pasaulē labākā grāmata ir “High Performance MySQL” (pašreiz otrais izdevums). Ja Tev līdz šim ir šķitis, ka MySQL ir maza figņa, kura tur kaut kur griežas un nav jāpieskata, tad šī grāmata ikurāt ir domāta tādiem kā Tu. Pašam man tā ir izrotāta ar milzumu grāmatzīmītēm un tiek pāršķirstīta regulāri.

MySQL Enterprise. Ļoti dārgs pakalpojums no MySQL AB, kurš bez maksas tehniskā (un ne tikai) atbalsta sevī ietver arīdzan MySQL Enterprise Monitor, kura izcilās daļas ir MySQL Query Analyzer un MySQL Enterpsise Advisors. Pirmais rīks ir ļoti labs, lai veiktu vispārēju datubāzes noslodzes analīzi, pētot individuālus pieprasījumus vai to grupas. Otrais, savukārt, sniedz padomus par iespējamām nepilnībām MySQL vai paša servera konfigurācijā ar padomiem - kas un kā ir jāmaina, lai viss būtu labi. Tas viss tiek ietverts MySQL Enterprise pakalpojumā, kura cena ir sākot no 2 tūkstošiem dolāru gadā. Tas ir fakts - šis ir viskvalitatīvākais no pieejamajiem rīkiem.

Starp citu, viens no manuprāt būtiskākajiem plusiem ir tas, ka atšķirībā no MySQL Proxy (lai arī risinājums ir faktiski tas pats), šī produkta aģents ir pilnībā caurspīdīgs. T.i. - visas uz IP bāzētās pieejas paliek spēkā un tās nav jāmaina uz @localhost.

Kontrollbase - bezmaksas alternatīva iepriekšminētajam. Projekts ir salīdzinoši zaļš, diezgan bugains, taču ātri gūst popularitāti un arī briedums nāk tam visam līdzi. Biedru ambīcijas ir diezgan nopietnas, jo izskatās, ka viņi vairāk vai mazāk tēmē uz iepriekšējā produkta "fīčām". Pamēģināju un domāju, ka tuvākā pusgada laikā darīšu to vēlreiz.

Nedrīkst piemirst vēl vienu nopietnu šī tirgus spēlētāju - “MONyog”. To, tiesa, neesmu mēģinājis, lai arī tas tiek stādīts līdztekus MySQL Enterprsie Monitor.

Savukārt, ja mēs runājam par vienkāršiem rīkiem, kas pamatā dod vienkāršu skaitlisku informāciju, tad to klāsts arī ir neaprobežojas ar vienu vienīgu.

Gana svaigs, bet oriģināls servera skaitliskās informācijas atainošanas rīks ir “mycheckpoint”. Tas principā ir viens pats nabaga paitona skripts, kurš paver iespēju ģenerēt daudz un dažādas statistikas. Savā ziņā varētu vilkt paralēles ar mazliet modernāku MRTG (neviens, tiesa, neliedz izmantot arī MRTG :P). Izstrāde notiek diezgan aktīvi, kā rezultātā projekts gūst nopietnas aprises un, šķiet, varētu apsavesties arīdzan ar monitorēšanas rīka iespējām.

Ļoti sens, bet aizvien bez maz vai must have rīks ir perlā rakstītais “mysqlreport”. Tas dara vienkāršu, bet ļoti noderīgu darbu - transformē MySQL statusa vērtības cilvēkam viegli uztveramā formātā.

Tīri no rīku viedokļa ikkatram būtu jāzin “maatkit”. Tas ir perl skriptu kopums, kuri ir orientēti neba nu uz vienkāršu lietotāju. Ar tiem var paveikt pašu vellu. Par to jaudu var pārliecināties, uzmetot acis vienam pašam rīkam - mk-query-digest, kas ļauj analizēt ne tikai MySQL logus, bet pat tcpdump savāktos datus.

Tas ir tīri par rīkiem, kurus es vairāk vai mazāk ikdienas darbā izmantoju. Kā tos pielietot, kādus secinājumus to darbības rezultātā veikt - tas paliek paša izmantotāja ziņā.

Ja monitoringa vajadzībām tiek izmantots “Cacti”, noteikti ekipējumā pienākas iegūt “MySQL Cacti templates”.

MySQL servera dziļākai uzlabošanai pavisam noteikti noderēs “Percona Lab” izstrādātie patchi (ielāpi), kas, starp citu, vakar tika oficiāli laisti klajā arī MySQL 5.1 sērijai. Nu, un, protams, arī Gūglei ir savi rīki un patchi MySQL serverim (pagaidām tikai 4.x un 5.0.37 versijai).

Visā visumā, pasaule ir pilna ar rīkiem, kas atvieglo vai bagātina ar piedzīvojumiem (atkarībā no roku liekuma rādiusa:) MySQL DBA dzīvi.

Nezinu, kā lai pietiekami uzsveru to, ka, pirms ķerties klāt savam serverim, nepietiek virspusēji iziet cauri tīklos atrodamajai informācijai. Viens konfigurācijas parametrs ietekmē desmit citus - sevišķi tas attiecas uz InnoDB. Lai sekmīgi operētu ar analīzes rezultātiem un ķertos pie uzlabojumiem, ir nepieciešams saprast arīdzan to, kas notiek aiz acīmredzamā. Tā teikt - problēmas cēloni.

Ne vienmēr pietiek iemest serverim ar atmiņu, ātrākiem diskiem un vairāk procesoriem (kas MySQL gadījumā ir atsevišķs stāsts). Piemēram, pie autoritatīviem avotiem ir lasīts par gadījumiem, kad operatīvās atmiņas dubultošana pat ir radījusi pretējo efektu - serveris ir kļuvis lēnāks.

Tu atbildi augstāk redzamajam komentāram. Atcelt

Gravatar newage

2010. gada 10. februārī, plkst. 17:42

Sorry par offtopic, bet vai man vienīgajam http://laacz.lv/blog redirektējas uz http://laacz.lv/2003/01/29/blog/ ??

Gravatar zh

2010. gada 10. februārī, plkst. 23:05

+1 Es ar eju uz lāczi caur grāmatzīmi un pāris dienas neiedziļinājos, kāpē nav jaunumu

Gravatar laacz Autors

2010. gada 11. februārī, plkst. 11:29

zh, newage, labots.

Gravatar laacz Autors

2010. gada 11. februārī, plkst. 12:26

hu_ha, vajadzētu būt.

Gravatar hu_ha

2010. gada 11. februārī, plkst. 13:10

Tagad ir gan, citādi ar nācu skatīties, ka nekas sen nav iekritis fīdā ;)

Gravatar Runcis

2010. gada 11. februārī, plkst. 14:10

Vienmēr brīnos kā nopietniem biznesa risinājumiem izmanto MySql

Gravatar Maksim

2010. gada 11. februārī, plkst. 15:44

Loti aktuala tema man.

  1. mysql tagad uz highloadiem loti biezhi dzivo ar memcache.
  2. Pie videjiem 1,5 pieprasijumiem sekunde, izmantojam mytop, lidz parejiem tooliem ta ari neaizgajam, nebija laika.
  3. Biezhas mysql bremzes: indeksi nepareizi salikti, lockojas uz lieliem delitiem.
  4. Mysql krutijas pussgadu uz ssd, ieprekshejo atrumu nemeriju, bet kopa ar innodb ngb bufferu - parasti lido.
  5. Lielaka tabula 15gb
  6. es brinos ka cilveki perk oracle, kur ar csv failu pietiek (atbilde Runcim)

Gravatar JanisB

2010. gada 11. februārī, plkst. 16:49

Ja nu šī tēma ir oftopiku pilna - vai var prasīt, kur rādās tieksme dēvēt lasītājus (arī SMS u.c.) - "Tu", tieši ar lielo burtu? Aizguvums no "You"? Konkrēti man (protams neesmu mēretalons) ne visai patīk, kad Tekstā Mani Šādi Izceļ.

Gravatar laacz Autors

2010. gada 11. februārī, plkst. 16:55

JanisB, nezinu. Es deviēju starp dažādām uzrunām un dažādiem lielo/mazo burtu lietojumiem.

Gravatar japets

2010. gada 11. februārī, plkst. 16:58

JanisB, "Tu" lietojums ir no latviešu valodas pareizrakstības pieklājības forma uzrunai vēstulēs. Internetā sarakste tam var tikt pielīdzināta. "Jūs" lietošana man personīgi nešķiet pieņemama.

Gravatar atis

2010. gada 11. februārī, plkst. 18:10

a kā tad ar mysql-slow.log?

ar mysqldumpslow var no tā iegūt pietiekami vērtīgu informāciju optimizēšanai.. protams pašam arī nav jābūt cirvim

Gravatar Artx

2010. gada 11. februārī, plkst. 18:26

JanisB: Es, Tu, Jūs, Tavs, Viņš, Viņa, Mans, Mana, Viņa, Viņas, pareizrakstība ir ar pirmo lielo burtu, ja pareizi atceros. (man tā liekas)

Gravatar laacz Autors

2010. gada 11. februārī, plkst. 18:33

atis, mysql slow loga patīkamāku analīzi var izveikt ar mk-query-digest - jamais pats tev sagrupē vaicājumus, sakārto tos pēc pieprasījumu skaita, kopējā, vidējā patērētā laika, utt. mysqldumpslow ir vienkārši dumps nevis analīzes rīks.

Gravatar paksis

2010. gada 11. februārī, plkst. 18:41

Artx, Ja pareizi atceros, tad latviešu valodas uzrunas korekti raksta: to, kas saistīts ar Tu - raksta ar lielo, to, kas saistīts ar vienas personas uzrunu - Jūs (ar lielo), to, kas saistīts ar vairākām personām - jūs (ar mazo).

Gravatar atis

2010. gada 11. februārī, plkst. 19:11

mysqldumpslow -s c mysql-slow.log > count.log mysqldumpslow -s t mysql-slow.log > time.log mysqldumpslow -s l mysql-slow.log > lock.log

Gravatar laacz Autors

2010. gada 11. februārī, plkst. 19:14

atis, arī variants. Nebiju šo zinājis. Tiesa, rezultāts nav tāds, kāds tas ir maatkit.

Gravatar atis

2010. gada 11. februārī, plkst. 19:20

es savukārt nebiju zinājis par maatkit, bet šis nāk kopā ar mysql.. abi gan izskatās samērā līdzīgi, rakstīti perlā

Gravatar laacz Autors

2010. gada 11. februārī, plkst. 19:21

atis, maatkit komplekts kā tāds ir iespēju ziņā pārbagāts. Tas pats mk-query-digest ir izmantojams deviņdesmit deviņos dažādos veidos, pie kam, var analizēt, kā jau norādīju, ne tikai pašus logfailus, bet arīdzan tcp/ip trafiku dzīvajā.

Gravatar docenc

2010. gada 12. februārī, plkst. 17:58

Zhetons Maksim!

It sevishki tas ir nirdziigi paarbagaatajaa LV :D

Gravatar docenc

2010. gada 12. februārī, plkst. 17:59

es domaaju par sho: 6. es brinos ka cilveki perk oracle, kur ar csv failu pietiek (atbilde Runcim)

Gravatar weedy

2010. gada 13. februārī, plkst. 09:06

Vienmēr brīnos, kā nopietnus biznesa lēmumus pieņem cilvēki, kas savu viedokli balsta uz stereotipiem (#7).

Gravatar nxt

2010. gada 14. februārī, plkst. 03:44

#23. +1 Savukārt es vienmēr brīnos par to, kā cilvēki ne tik nopietnu biznesa risinājumu mēdz uzskatīt par nopietnu un otrādāk.

Gravatar archaic

2010. gada 15. februārī, plkst. 13:45

Nu Latvijas datu apjomi nav tādi, ka nevarētu lietot MySQL da jebkam. Man te griežas db ~15Gb, 3000+ vaicājumi sekundē, 100+ vienlaicīgas konekcijas. Un nekāda vaine, cpu loads 4kodolu dzelzim nav augstāks par 2.