[ CoyoteKG @ 24.12.2015. 15:23 ] @
Imamo neki Magento shop, na nekom dedicated serveru.
Oduvek nam pravi problem sa vise stvari, izmedju ostalog sa sesijama koje pretrpavaju folder do nekih silnih gigabajta...

No, i na ovom i na proslom serveru, neki mysql procesi uzimaju dosta resursa.
Najproblematicniji je ovaj prvi koji je podignut dok god ne resetujemo ponovo server. A neko mi rece, da mysql procesi ne treba da traju duze od par minuta.

Kako da saznam zasto se to desava, sta je problem?
Koji su koraci?


[ Panta_ @ 24.12.2015. 18:14 ] @
Pogledaj sa mysqladmin ili mytop sta ti opterecuje server.

Code:
mysqladmin status
mysqladmin processlist
mysqladmin proc stat
[ nkrgovic @ 24.12.2015. 19:05 ] @
Taj neko te slagao - ili nije znao :) . Pazi ovo:

Code:
 314197:30 /usr/local/mysql/bin/mysqld --basedir=/usr/local/Percona-Server-5.6.25-rel73.1-Linux.x86_64.ssl101....


I radi sjajno. U sustini:

- show processlist;

- pa pogledaj ima li slow query-ja

- pa razmisli da ukljucis query cache, ako se mali broj upita ponavlja cesto

- Generalno proveri execution plan za teze upite, plus proveri sta imas od indexa

- Vidi imas li dosta insert/update/delete upita ili dosta selectova. Ako je ovo prvo, proveri opterecenje diska

Ima dosta toga, ovo nije los pocetak.
[ Duka_ @ 24.12.2015. 19:50 ] @
TIME+ u top/htop ne prikazuje vreme od kad je proces startovan, već vreme koje je procesor potrosio na izvršavanje task-ova. Vreme startovanja procesa možeš da vidiš ili kroz
Code:
ps auxwf
ili
Code:
ls -ld /proc/PID

Koliko često viđaš da neki proces uđe u D stanje, i koliko ostaju u tom stanju? Moguće da ti disk problem. Proveri iotop.
Takođe, pogledaj mysql-tuner, možda ti pomogne da identifikujes koji parametri u MySQL konfiguraciji nisu dobro konfigurisani.
[ nkrgovic @ 25.12.2015. 08:54 ] @
Tako je, pricamo o utrosenom CPU vremenu. To vreme zavisi od broja konekcija, kolicine upita i uptime-a. Moj primer je za server koji radi godinu dana (od update-a), i koji ima average preko 2000 query/s (u peak vremenu ide preko 6000qps). Nije nista cudno da server trosi dosta cpu vremena, generalno je direktno proporcionalno opterecenje.

Disk I/O je nesto sto i ja mislim da treba da se proveri. Druga stvar su indexi, mozda neki fali, a mozda je i neki viska, pa se ne koristi a jede iops-e.
[ CoyoteKG @ 25.12.2015. 10:43 ] @
Citat:
Panta_:
Pogledaj sa mysqladmin ili mytop sta ti opterecuje server.

Code:
mysqladmin status
mysqladmin processlist
mysqladmin proc stat

Pogledah sa mytop tu bazu za koju sam mislio da je problematicna, i ne deluje mi bas tako.
To je shop, koji trenutno i ne funkcionise. Odnosno trenutno nije moguca kupovina, nego samo pregled artikala.
Server nije bas slabasan, da bi se memorija onako punila brzo, i da CPU ima onakve pikove? A vrti samo jedan magento shop, jedan opencart, i 2 WP sajta. Pored toga ima i par dev WP sajtova koji su trenutno u izradi, ali niko im od spolja ne pristupa.

Evo kako izgleda mytop


Ove komande, da vidim processlist, nesto mi ne polazi sa rukom. Guglam da vidim na debianu kako da ih izvrsim... pa cu javiti rezultate


@Nikola, nemam bas nekog iskustva, ali ok su smernice, pa sad upravo guglam da vidim kako da uradim sve to sto si rekao :)


Sto se tice HDD sa smartmontools sam smao pogledao SMART status i "Passed" je. Sad sam pustio long scan na sda, nego traje par sati, pa cu i na sdb, da vidim da li ima nekih gresaka...

@Duka_, instalirao sam mysql tunner, evo SS, cisto ako mozes da pretpostavis sta od ovih upozorenja je kriticno. A usput cu i ja malo da citam, pa da pokusam da resim.

[ CoyoteKG @ 25.12.2015. 18:03 ] @
Ne mogu da odradim većinu ovih komandi koje ste mi savetovali, i koje sam dodatno još našao po netu, jer ne mogu da se ulogujem na mysql kao root, non stop dobijam poruku

Access denied for user '[email protected]' (using password:NO)


Ispratio sam više uputstva, a sa ovim sam "najdalje" dogurao, ali na zalost na kraju ovog uputstva kad uradim
mysql> update user set Password=PASSWORD('new-password-here') WHERE User='root';
Query OK, 2 rows affected (0.04 sec)
Rows matched: 2 Changed: 2 Warnings: 0


dobijem poruku 0 rows affected i isto za matched i chanched.
Naravno, kad startujem ponovo mysqlu, ne mogu i dalje da se ulogujem kao root.


Nesto razmisljam o tome gde gresim, i tek sada mi pada na pamet, da je ovo komanda za update vec postojeceg passworda koji postoji na root?
Doduse pokusao sam i sa

mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('MyNewPass');


I nisam uspeo :)

[ Miroslav Strugarevic @ 25.12.2015. 21:44 ] @
Pozdrav,

[email protected] Iz ovoga sto si napisao ja bih rekao da ti mislis da imas problem zato sto ti je neko rekao da mysql procesi ne treba da traju vise od par minuta? Molim te ispravi me ako gresim.

U ovom sto si poslao imas mysql process u D stateu sto znaci da ceka na I/O ali to ne mora da znaci da problem postoji. Ako se to cesto desava onda nemas dovoljno jak server, tacnije disk ne moze da opsluzi toliki broj IOPS-a. Nema potrebe da pustas nikakve provere sa smartmontools osim ako ne sumnjas da je neispravan.

1. Sto se tice mysql root passworda, ako ga nemas onda sigurno ne moze setovati novi root password kao obican (non-root) user. Jedini nacin da to uradis je da stopiras i startujes mysql bez grant tabela i onda resetujes root password.

https://www.howtoforge.com/set...resetting-mysql-root-passwords

2. Mozes da objasnis koji je tacno problem? Kako se manifesuje? Kada si poceo da primecujes problem?
3. Da li si nesto radio na OS-u ili samoj bazi pre nego sto je pocelo sve to da se desava? Zasto mislis da problem postoji?

4. Pokreni ove komande i prikazi output u plain text formatu ako moze.

free -m
cat /proc/cpuinfo
vmstat 1 15
ps auxww --sort=pcpu
iostat 10
iotop -o -b -n 20 > iotop.txt


Ako imas instaliran sar, molim te dumpuj metriku u fajli i attachuj je ovde.
LC_ALL=C sar -A > sar.txt

Ako sredis password onda obavezno uradi ovo sto su rekli Panta, Duka i Nikola. Jako je bitno da znas sta mysql radi a to bez mysqladmin processlist neces moci da znas.

Pozdrav.

[Ovu poruku je menjao Miroslav Strugarevic dana 26.12.2015. u 00:04 GMT+1]
[ CoyoteKG @ 28.12.2015. 16:36 ] @
Miroslave, hvala na odgovoru.

Nisam nasao vremena da podesim root password i pokrenem ove komande, javljam se sa vise detalja sto skorije.

Sto se tice prvog dela pitanja,

Server bi trebalo da je jak
U pitanju je ovaj server
https://www.hetzner.de/at/hosting/produkte_rootserver/px91

U pravu si, moje misljenje "da nesto nije u redu" se zasniva na koleginom komentaru da mysql procesi ne treba da traju duze od par minuta (i sada shvatam da gresi), ali i da procesor na serveru ne treba da bude toliko opterecen, kao sto se vidi na screenshot-u u prvom postu.
Evo sada je ovako. Doduse ovo uhvatim kad bas skoci, ali se menja iz sekunda u sekund.


Nejasno mi je da se ovakav procesor toliko "muci", a gura samo 2 sajta. Jedan Magento i jedan Opencart. Pri tom nema bas kupovine, vise je surfovanje i pregledanje proizvoda.

Pokusacu sada da resim root password, pa se javljam sa vise detalja.


edit:
I prosli put ovi problemi kod menjanja password-a... :)
Za razkliku od svakog tutoriala, dobijem poruku "Rows matched: 0", a svima pise 2 ili 4. Tako da ne promenim nista, i eto, ne mogu da se ulogujem kao root.


[Ovu poruku je menjao CoyoteKG dana 28.12.2015. u 18:03 GMT+1]




[Ovu poruku je menjao CoyoteKG dana 28.12.2015. u 18:05 GMT+1]
[ Miroslav Strugarevic @ 28.12.2015. 20:17 ] @
Caos,

Sto se tice mysql passworda, mozda nemas root usera na sistemu?

mysql> select Host,User,Password from mysql.user;

Proveri prvo to pa onda menjaj password za tog usera.

Mozes dodatno da dodas novog usera dok je mysql startovan bez grant tabela pa da koristis njega za administraciju.

https://www.digitalocean.com/c...and-grant-permissions-in-mysql

Sto se tice procesora i tvog problema, ja ne vidim nikakav problem sa tvojim sistemom. Load average od 2.X nije nista, a uzork je mysql koji nesto radi.

Proveri disk kao sto sam ti rekao i pogledaj sta mysql zapravo radi.

Mozes da proveris i soft raid, mozda se rebuilduje ili je jedan disk vrisnuo. Ovo je malo verovatno ali mozes da proveris.

cat /proc/mdstat

Najbolje da instaliras neki monitoring alat da bi mogao da vidis sta je mysql radio u toku dana i kada je opterecenje bilo najvece. Mozda imas neki cron ili nesto skedulovano u bazi ili je baza "lose" dizajnirana itd itd..

https://www.digitalocean.com/c...p-to-monitor-mysql-performance

Pozdrav
[ Miroslav Strugarevic @ 28.12.2015. 21:04 ] @
Napravio sam malu gresku u prethodnoj poruci. Ako hoces da kreiras novog usera dok je mysql pokrenut sa --skip-grant-tables moras rucno da uradis INSERT u bazu i tako dodas usera.

http://serverfault.com/questio...-mysql-users-have-admin-rights

Pozdrav
[ Miroslav Strugarevic @ 30.12.2015. 20:05 ] @
Jos nesto sto sam zaboravio a to je slow query log. Ovde mozes pogledati kako da ga ukljucis i kako da ga koristis.

https://easyengine.io/tutorials/mysql/slow-query-log/
[ nkrgovic @ 30.12.2015. 21:28 ] @
Slow query log i iostat su dve stvari koje ja napisah gore, i koje su po meni dobar pocetak. :) Posle ides na kopanje po information schema-i za probleme sa indexima i/ili analizu execution plana za te upite. :) To je neki standardni nacin mysql optimizacije, pod pretpostavkom da si osnovne stvari (kernel tuning, numa affinity, innodb buffer sizing i sl) odradio kako treba.
[ Miroslav Strugarevic @ 30.12.2015. 21:30 ] @
Jesi. Ja sam samo hteo da dam i neki useful link da covek moze lakse da se snadje :-)
[ CoyoteKG @ 30.12.2015. 22:29 ] @
hvala svima, uspeo sam da kreiram root account, ali ne sa tog linka, nego sa nekog drugog, odnosno kombinacijama razlicitih tutorijala :). Poceo da pisem post sa komandama ovde, ali izgleda nisam zavrsio posto ne vidim da sam napisao :/.

Nego me uhvatise sa nekim poslovima pa nikako da se vratim na ovaj problem.

sad mi rade mysqladmin komande.
Sutra idem na odmor, pa ću u selu da odmaram i trazim probleme pomocu vasih uputstava...

Sto se tice same optimizacije, iskusniji kolega mi kaze, da je baza kao baza sigurno dobra, jer je to magento baza, i da tu "nema sta da se optimizuje" :)

[ nkrgovic @ 31.12.2015. 09:15 ] @
Pa eto onda, sta se ti tu nerviras - sigurno je dobro :D

Sve jedno, proveri innodb buffer pool size, povecaj malo query cache i za svaki slucaj pogledaj iostat i slow queries.... Ili, nabavi neki reality distorsion field i pricaj sebi da to ne moze bolje :)