( blackluck | 2018. 08. 22., sze – 13:53 )

top-ban 'wa' resz lenne a az io wait, annyi hogy erdemes magonkent is nezni, hatha valami 1 magot hajt ki es arra var valami, de megnezheted iotop-al vagy dstat is diszk muveleteket.
Bar ha fel giga az innodb buffer akkor kb elfer benne az egesz adatbazisod, igy csak iras muveletek eseten lesz erdemben sql-nek diszk hasznalata meg file temp tablak gyartasanal, talan kevesbe errol van szo.

A cpu oszlopban jelenik meg a terhelest gondolom mysqld-re erted, hogy annal latod a terhelest, vagy lehet valojaban valami mas terheli kozben a gepet?

A buffer es cache ertekek ranezesre nem tunnek kevesnek a 2G memoriahoz, meg hogy 0.5G innodb buffer es 50 max connection, de nem szamoltam utana es mysqltuner megmondja mennyi lehet a max memoriahasznalat ezzel a konfiggal.

Mentesekhez van hasznalva binlog vagy nem lehet azt kikapcsolni? Mondjuk ha keves az irasmuvelet akkor nem veszes, de ha jelentosebb es kozben nincs hasznalva akkor plusz terhelest tud adni.

Grafikonok hasznosak tudnak lenni ha gond van vagy tervezni kell a jovore hogy mekkora terheles szokott lenni, mik a jellemzo ertekek es a problemas idoszakban hogy valtozik, sokszor olyanokbol konnyebben ki lehet szurni milyen iranyban erdemes nezelodni. Mysql eseten is van jopar ami hasznos lehet pl: memoria hasznalat, tranzakciok szama (tipusonkent), kliensek szama, query cache hasznalata (bar ugy latom az ki van kapcsolva), temp tablak hasznalata stb. Muninhoz is van jopar ezekhez mysql_ es tarsai neven, de lehet zabbixhoz is talalni pl percona monitoring toolkitben: https://www.percona.com/software/database-tools/percona-monitoring-plug…

Egy query terhelese jo esellyel nem lehet nagy ha gyorsan kikerul, de ha tobb ilyen fut egyszerre akkor mar kevesbe mind1 hogy mennyire gyorsan. Ha pl 0.3sec alatt fut le 1 query akkor onmagaban nem sok, de ha ebbol jon egyszerre 10 egy weboldal betolteshez akkor mar jo esellyel nem 0.3sec alatt adja vissza az osszest, de talan nem is 3 sec lesz azert.
Erdemes ezert slow query logot elemezni, vagy ha el tudod kapni ilyen terheles idoszakban akkor aktualis halozati forgalmon (127.0.0.1:3306) nezni mysql muveleteket, percona toolkitben van query digest azzal slow query logot is tudod elemeztetni, meg tcpdump-al csinalt capture-t is elemezni: https://www.percona.com/doc/percona-toolkit/LATEST/pt-query-digest.html (jo esellyel ubuntu repoban is benne vannak ezek alapbol).

Elso korben mindenkepp azt kene behatarolni hogy amikor jelentkezik a nagy terheles akkor azt mysql okozza-e es ha igen akkor abban milyen muveletek tortennek, hogy lehessen vizsgalni az miert ekkora gond, aztan lehet az lesz belole, hogy sok egyforma query fut le egyszerre es query cache vagy valami egyeb cache megoldas kellene mysql es webszerver koze, de siman lehet olyan is hogy valami olyat kerdeznek le ami nincs (jol) indexelve, vagy adatmennyiseg elerte azt a limitet valamelyik tablaban amivel ugyanaz a query ami evek ota fut mar nem fer bele sort bufferbe es temp tablakat general.