[ anon70939 @ 08.03.2017. 16:03 ] @
Gasimo neki stari dev server zbog neke Hetznerove migracije, a i zastareo je, pa sam porucio neki nov.
Linux CentOS 7.3 + Plesk ponovo

S tim što mi je sada na serveru nije instaliran MySQL nego MariaDB.
# mysql -V
mysql Ver 15.1 Distrib 5.5.52-MariaDB, for Linux (x86_64) using readline 5.1

Megento 1.9 requirements za DB je MySQL 5.6 (Oracle or Percona)
A za Magento 2 je
Citat:
MariaDB and Percona are compatible with Magento because we support MySQL 5.6 APIs.


Sa ovog linka sam razumeo da meni treba verzija 10?
[ nkrgovic @ 08.03.2017. 19:44 ] @
Ako nemas neki poseban razlog (hint: ako ne znas koji - nemas), safe bet je pretplatis se na official Oracle yum repo, stavis MySQL 5.6 iz njega poslednji i miran si. Ne 5.7 jer ima nekompatiblnih promena, ne Percona, ne Maria, vec plain vanilla MySQL 5.6 GPL.

Ako ti ikad zatreba nesto drugo upgrade je lako izvesti, ovo ti je safe bet.
[ anon70939 @ 08.03.2017. 20:20 ] @
Sta znaci pretplaatiti se na Oracle um repo?
Odnosno sta znaci pretplatiti se? Neka koštanja dodatna, ili...?

Koliko vidim to bi trebalo da bude samo
https://docs.oracle.com/cd/E37...l/ol_downloading_yum_repo.html


Mozes li pls u kratkim crtama da mi napises kako bi trebalo da izgleda prelazak sa MariaDB na MySQL 5.7, a ja cu dalje da guglam.
[ djoka_l @ 08.03.2017. 20:47 ] @
https://docs.oracle.com/cd/E52.../E39381/html/ol_about_uln.html

Za 119 dolara godišnje dobiješ ono što je u dokumentu.
[ anon70939 @ 08.03.2017. 21:34 ] @
Je l' moze nekako bez 119 dolara :)
[ bogdan.kecman @ 09.03.2017. 00:38 ] @
ne kosta bre nista ...

https://dev.mysql.com/downloads/repo/yum/

instaliras rpm sa repozitorijumom za rhel 7:

https://dev.mysql.com/get/mysq...unity-release-el7-9.noarch.rpm

onda odes u /etc/yum.repos.d/ i editujes mysql-community.repo

po defaultu ti je enabled mysql 5.7 a disabled 5.6 ako oces obrnuto
stavi za 5.7 da je disabled a 5.6 da je enabled i to je to

uradis yum update posle toga

i vozi misko :D .. imas uvek najnoviji 5.6 oracle binary na serveru

(sad dal ti terba 5.6 ili 5.7 nemam pojma ja se klonim i pleska i
magentoa, ako nidza kaze 5.6 idi sa 5.6 :D )
[ bogdan.kecman @ 09.03.2017. 00:38 ] @
https://dev.mysql.com/doc/mysql-yum-repo-quick-guide/en/
[ nkrgovic @ 09.03.2017. 08:39 ] @
Moze, dao ti je Bogdan link. :) Samo instaliras rpm i vozi.

Pazi, ako ti pasuje 5.7, ako imas multi-core CPU (ili vise njih) i dosta RAM-a koje mozes da uposlis, sve su to ralozi da razmisljas o 5.7 ili Percona - ali ako hoces "safe bet", zvenki 5.6, vidi kako radi, pa onda mozes dalje. Sustina je da sa plain vanilla 5.6 uvek mozes upgrade na nesto drugo (percona 5.6 , vanilla ili percona 5.7 , mysql 8 kad izadje, maria 10...), ali je mnogo slozenije sa njih nazad na 5.6 . Takodje, sve ovo podrazumeva da radis ozbiljne optimizacije, a ne da stavis Plesk i isklikces nesto, bez uvrede.

Ja pretpostavljam da ces na tom Plesku da imas 5-6-10+ sajtova, koji nemaju veliki saobracaj. Ako ikad budes imao dosta toga, npr. na tom Magento-u, onda ces imati drugu pricu, masinu samo za njega i onda mozes polako da razmisljas i o boljoj bazi, ali i o drugim stvarima koje ce ti za Magento vise znaciti (ako nemas za komercijalni magento, pre svega neki Varnish ispred).
[ anon70939 @ 09.03.2017. 09:38 ] @
Mene zanima da li moram da uninstall MariaDB prvo?

server ima 64GB RAM, a CPU je (Intel® Xeon® E3-1275 v5 Quad-Core Skylake inkl. Hyper-Threading-Technologie)
Nego ne znam kako ću posle da namunjim 5.7 da mi radi Magento i ostalo ako krenu problemi... Jer jbg, ipak sam ja samo "plek klikač" :P. I daleko bilo da se uvredim zbog toga, svestan sam šta sam :), a i sujeta mi je 0%.

Inače evo potrebe.

dakle nema mail servera. To sam uzeo kod Euneta neki cloud postfix.

Biće mi potrebno za
- 1 Magento 1.9 site oko 5000 produkata, ali nema online kupovine. Prezentacioni je sajt.
- 1 Magento 1.9 site sa oko 300 aktivnih produkata, ima online kupovine, ali par mesečno
- 2 Magento 2.1 sa po tridesetak produkata, moguća je online kupovina, ali više služi za "request a quote". Dakle samo prezentacioni
- dvadesetak WP sajtova, opet samo prezentacioni, nisu preterano posećeni
- desetak HTML statičnih stranica

- Magento 1.9 u dev fazi, dosta produkata, ali po završetku ide na odvojen server
- Magento 2 u dev fazi, par desetina produkata, verovatno će ostati na serveru.


To je u principu sve, i verujem da je ovaj server ok, jer mi se isto to vrti na trenutnom starom serveru, i CPU load je 3, a imam 12 core.
Memorija 8/64
[ bogdan.kecman @ 09.03.2017. 10:32 ] @
Citat:
CoyoteKG: Mene zanima da li moram da uninstall MariaDB prvo?


ne moras, instaliras oraklov mysql repo, i kada uradis yum update on ce pregazi mariju sa normalnim mysql-om (posto je marija vec napisala da je "normalan mysql" tako da je to samo obican update)

[ agvozden @ 09.03.2017. 19:28 ] @
U čemu je štos kod tih sistema koji zahtevaju striktnu verziju baze?
Postoje sistemi koji ne mare mnogo ni koji je proizvođač baze, bitno da je sql.

Kapiram da je masa sql upita, ključeva, indeksa, procedura, ista.

Šta oni koriste specifično od baze, da bi bili zavisni od verzije?
[ nkrgovic @ 09.03.2017. 19:58 ] @
SQL sintaksu, posebno vezano za stored procedure. Takodje, masa upita zapravo nije ista, create statementi se isto razlikuju, indexi se razlikuju - cak nisu ni isti. MySQL je primer da neki indexi ne rade na svim tipovima tabela unutar iste baze - vec su vezani za odredjeni storage engine.... a kamoli da predjes na postgre npr.
[ agvozden @ 09.03.2017. 21:51 ] @
@nkrgovic

Ovo kažeš vezano za verzije MySql-a? Što bi se razlikovali upiti i indeksi?

Batali moju opasku vezanu za različite verzije baza, to je blagi offtopic...
[ anon70939 @ 09.03.2017. 23:23 ] @
Citat:
bogdan.kecman:
Citat:
CoyoteKG: Mene zanima da li moram da uninstall MariaDB prvo?


ne moras, instaliras oraklov mysql repo, i kada uradis yum update on ce pregazi mariju sa normalnim mysql-om (posto je marija vec napisala da je "normalan mysql" tako da je to samo obican update)


u medjuvremenu sam instalirao Debian.
isto Maria DB, doduse verzija 10.0.29


Ispratio samo tacku 1. Adding the MySQL APT Repository
https://dev.mysql.com/doc/mysql-apt-repo-quick-guide/en/

Izabrao 5.6

okinuo apt-get update, ali nista. i dalje je MariaDB

root@srv1 /tmp # dpkg -i mysql-apt-config_0.8.3-1_all.deb
(Reading database ... 135219 files and directories currently installed.)
Preparing to unpack mysql-apt-config_0.8.3-1_all.deb ...
Unpacking mysql-apt-config (0.8.3-1) over (0.8.3-1) ...
Setting up mysql-apt-config (0.8.3-1) ...
OK
root@srv1 /tmp # mysql -V
mysql Ver 15.1 Distrib 10.0.29-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
[ agvozden @ 09.03.2017. 23:55 ] @
da bi deinstalirao mariadb, moras da znas i kako se instalira.
fazon je u tome sto preuzme holder za mysql, tako da apt gadja mariadb repozitorijum.

ukoliko je debian, otvori /etc/apt/sources.list
i pronadji zapis za mariadb, npr: deb [arch=amd64,i386] http://mirror.netinch.com/pub/mariadb/repo/5.5/ubuntu trusty main

obrisi taj zapis, deinstaliraj mariadb paket, obrisi apt kes, apdejtuj pakete i instaliraj mysql ponovo.
ili kompajliraj iz source-a, ali opet ces morati da uklonis mariadb zapise.
[ bogdan.kecman @ 10.03.2017. 00:50 ] @
@kojot, rece ti agvozden sta i kako, pitao si za yum/rpm pa ti to
napisah :D .. ja licno nisam ljubitelj debi(l)ana .. sa centos-om na
hz-u imam najbolja iskustva

@agvozden, generalno kod tih zahteva 99% razloga je pismenost .. sta je
fora, mysql je krenuo dosta davno i u startu je imao samo osnovnu
podrsku za sql, nikakvu podrsku za mnogo sta drugo i pun .!. bagova, al
je bio mega brz, i za tada "izrodjenog" web developera bio je dovoljno
jednostavan ... zato je procvetao i postao najinstaliraniji rdbms na
svetu.. e sad, fora je sto je mysql za ove 22 godine rastao i polako
podrzavao full sql standard, a da bi podrzao pun sql standard neke
stvari je morao da promeni, jeli, tako da je brdo stvari koje su radile
pre 22 godine prvo bilo deprecated u par verzija pa onda postalo i
unsupported.. (pritom te promene se menjaju samo na drugom broju
verzije, na trecem broju verzije su samo bugfixes nema nikakvim izmena
tog tipa)... oko 1-2% stvari koje su tako promenjene su potpuno izbacena
dok su sve ostale promene bazirane na default vrednostima koje ce mysql
da koristi ako ih nema u konfigu i veci deo njih se kontrolise sa
sql_mode setom modifikacija... tako da "neispravno vreme i datum" koje
si mogao da imas u date/time/datetime.. poljima od neke verzije recimo
vise ne radi (ako upises pogresn datum u polje ne dobijes datum
0000-00-00 nego gresku i nema inserta) i brdo aplikacija (poput magenta)
je prestalo da radi ... naravno, u mysql serveru mozes da podesis
sql_mode da izbacis NO_ZERO_DATE i NO_ZERO_IN_DATE i onda radi ko ranije
.. i brdo takvih stvari .. pogledaj spisak npr ovde:
https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html

sa druge strane, dok je mysql napredovao, menjao se, dodavao nove
stvari, menjao kako stare stvari rade ( cuveni problem recimo je group
by
https://dev.mysql.com/doc/refm...tml#sqlmode_only_full_group_by
zato sto su ljudi koristili group by na pogresan nacin ) neki developeri
su ostali u devedesetim i lakse im je da kazu "mora imas verziju x.y"
nego da oprave svoj pateticni kod :( ..

ja licno ne verujem da za magento treba vise od 1 dan posla za nekog ko
nikad nije video taj kod da ga opravi da radi ok sa 5.7 .. a za ljude
koji pisu taj kod ne verujem da treba vise od 2-3h posla .. samo sto bi
jbg.. radi i ovako :D ...

e sad imas i onih 1% razloga koji su najcesce vezani za testiranje ..
nesto je "vazno" (npr neki banking sistem) pa je pretreseno i na sve
nacine testirano sa verzijom XYZ svega zivog .. pa radi samo sa ovim
libovima i tim verzijama, samo sa onom bazom, samo sa... i tako dalje
... radi najverovatnije i kad sve upgradeujes ali oni ljudi nisu
testirali pa nece garantuju da radi ok..

dal je magento u 99% ili u 1% ne znam, nisam koristio doticni nikad ...
mada php ko php, ja kontam da su u 99%
[ nkrgovic @ 10.03.2017. 08:35 ] @
@agvozden: Ja sam konkretno mislio na FullText indexe. MySQL ih ima odavno, ali samo za MyISAM tip podataka, za InnoDB nije radio sve do 5.6 recimo. Tako si na MySQL 5.5 (godinama bio standard), imao fulltext samo na myisam tabelama i mogao si da biras izmedju glupog storage engine-a ili nemanja fulltext-a... najcesce se biralo ono trece - externi fulltext, tipa sphinx ili elasticsearch. :) Da ne ulazim u pricu na sta lici Percona i Toku engine npr. Bogdan ti je mnogo lepo objasnio :D
[ _owl_ @ 10.03.2017. 09:59 ] @
@bogdan.kecman
Tvoj prethodni odgovor me podsetio na priču kako MS objašnjava zašto ima gomila špageta/$"#$# u Windows-u a sve zarad očuvanja kompatibilnosti sa aplikacijama pisanim ko zna kad.
[ bogdan.kecman @ 10.03.2017. 10:45 ] @
@owl, pre nego je oracle preuzeo management bilo je gore nego sto
mislis, monti je kralj spageti koda, mysql je u originalu bio ozbiljan
spageti vestern, monti je zarad toga da dobije promil na ubrzanju ceo
sistem pravio nabudzeno i prebudzeno .. zbog toga je bilo nekoliko
pokusaja forkova za refaktoring i ciscenje koda, najpoznatiji je drizzle
projekat..

kada je oracle preuzeo, zaposlio je cudo QA inzenjera (to monti nije
dozvoljavao nikad, to je razlog zasto marija binary nije ni za .!. i
zasto kukaju i placu sto je oracle prestao da publishuje sve test
caseove za bagove i slicno, jer oni i dalje zavise iskljucivo od koda
koji oracle pravi) i zamenio coveka koji vodi development (prebacio
tomasa koji je vodio mysql klaster dev da vodi ceo mysql) i postavio
stvari na pravi nacin ... od tada je skoro ceo kod refaktorovan, izbacen
je skoro sav spageti kod i skoro pa je doslo do (u 5.7) cistog sorsa :D
... u osmici (koja je izasla pre neki dan) mislim da vise niceg nema od
tog starog budza... vise ni myisam nije tu :D ... takodje, za razliku od
promena za vreme montija (gde se iz cista mira menjalo stagod, bez
backward kompatibilnosti, procesa etc..) sve promene u oraklu prolaze
uzasno komplikovan proces, generalno "nekompatibilne promene" su skoro
nemoguce. tako da sada cak i kada se prave promene zarad usaglasavanja
sa standardom i slicno kroz sql_mode mozes da vratis staro ponasanje

sad jbg, monti je iskoristio skoro sve pare koje je dobio od prodaje
mysql-a da sirenje fud-a... i posle par godina i potrosenih skoro 11M
dolara na kampanju uspeo je da ugura mariju u distro-e umesto orakla,
uspeo je da napravi neku pricu protiv orakla koja bas nema nikakvu
podrsku u realnosti .. tuzno jbg ... napravio je ogromnu stetu i mysql-u
i open source svetu zarad svoje sujete :( .. no sta je tu je .. biznis
as usual ..
[ anon70939 @ 10.03.2017. 13:49 ] @
Citat:
bogdan.kecman:
@kojot, rece ti agvozden sta i kako, pitao si za yum/rpm pa ti to
napisah :D .. ja licno nisam ljubitelj debi(l)ana .. sa centos-om na
hz-u imam najbolja iskustva

instalirao ponovo centos, i mysql 5.6. ne znam koji sql_mode da upucavam da bi mi radio Magento, mada vidim da ljudi pisu po forumima da im radi magento na 5.7.
hvala :)
mysql Ver 14.14 Distrib 5.6.35, for Linux (x86_64) using EditLine wrapper
[ bogdan.kecman @ 10.03.2017. 14:03 ] @
ne trosim magento ali verovatno ce ti raditi ako stavis prazan sql_mode
(znaci u config turis sql_mode='' )
[ anon70939 @ 12.03.2017. 12:13 ] @
Instalirao ponovo server komplet, rekoh ajd da probam sa mysql 5.7 i radi sve. i ova 1.9 verzija magenta i 2.0.

E sad ova 1.9 verzija i ne radi bas savrseno. Odnosno prilikom loadovanja izgubi oko 7 sekundi na TTFB, posle toga svuče stranicu u deliću sekunde.
A verzija magento 2.1, drugi sajt naravno, on radi savršeno.

Da li mysql može uopšte da utiče na TTFB?
my.cnf mi je jos uvek default, okacio sam ga u attach.
mysqltuner sam instalirao i naravno daje preporuke sta da podesim.

Nego ne znam kako da dijagnostikujem zasto je TTFB tako visok, dok na starom serveru radi super. Jedina razlika (osim mysql verzije) bi trebalo da je sto sam na starom serveru pratio instrukcije mysqltuner-a i podesio.
[ nkrgovic @ 12.03.2017. 12:17 ] @
Tuner je OK, ali nije bas savrsen alat - zna da daje neralno male preporuke vezano za InnoDB buffer pool recimo.

Sto se 5.7 tice, pazi, ti si nabroja svasta. Ne znamo ni sta imas u Magento-u, ni koje custom dodatke (imao bi, racunam 2.x magento svuda da nema neka customizacija), ni te WP sajtove sta ima u njima i njihovim temama i custom modulima ni jos svasta nesto... Plesk bi trebalo da radi, ali ni za njega nisam siguran, stavise - njega ja nemam pojma, ne koristim.

Ako ti SVE radi na 5.7 u svakom slucaju ga zadrzi, pa polako.
[ bogdan.kecman @ 12.03.2017. 12:36 ] @
na ttfb moze ti utice sta oces, najbolji nacin da skratis ttfb i
rasteretis server je da turis ispred apacheta neki reverse proxy (ja
teram nginx, imas i varnish i svasta jos nesto sto mozes da koristis,
varnish je zgodan ako znas sta radis i adaptiras app da ga dodatno
koristi, nginx je zgodan za dzumle kesiranje svega lako i super brzo)

a sto se mysql-a tice, proveri sta ti kaze

select * from sys.statement_analysis order by total_latency desc;

select * from sys.statements_with_full_table_scans order by
total_latency desc;

povecaj innodb_buffer_pool, proveri da ti nije ostala neka myisam tabela
etc etc ...

takodje idealno je uzmes enterprise monitor pa vidis sta ti se tacno
desava na serveru (graficki) i opravis probleme..
[ anon70939 @ 12.03.2017. 13:26 ] @
nkrgovic, procitao sam sysrequirements i magento 2.x i plesk mora da rade. Za 1.9 ne pise, ali vidim po foruimma da svi kazu da im radi. WP takodje podrzava 5.7. A nista trece mi ni ne treba.
Znam da je plesk njesra, i jako bih voleo da mogu da ga zaobidjem. Ali mala smo firma radim 100 poslova, a administracija iz posla mi je presla u hobi. Odnsno radim popodne i vikendom jer na poslu nemam kad.
Inace bih jako voleo da mogu da posvetim vreme podesavanju servera i kapiranju svega onoga sto mi plesk nudi na klik
Čekam da izgorim ovde pa da trazim drugi posao gde ću raditi samo to što volim. Za sada još uspevam.
Ne planiram sad da sklanjam 5.7, bitno mi je da radi sve ovo što sam se i uverio, jedino taj ttfb je samo u slučaju magento 1.9 jako loš.
Ali do večeras ću valjda da skontam u čemu je prolem.


bogdane
select * from sys.statement_analysis order by total_latency desc;
mi je bacio skoro 9000 redova koječega

a
select * from sys.statements_with_full_table_scans order by total_latency desc;
oko 1200

Po ovome sto mi kaze mysqltuner imam myisam tabele, i verujem da su one bas iz ove 1.9 verzije
Citat:
[--] Data in MyISAM tables: 15M (Tables: 23)
[--] Data in InnoDB tables: 1G (Tables: 1087)
[--] Data in MEMORY tables: 1M (Tables: 31)
[!!] Total fragmented tables: 39



Sad ću da iščitam o MySQL Enterprise Monitor-u. Čim je enterprise pretpostavljam da košta :).
[ nkrgovic @ 12.03.2017. 14:27 ] @
@Coyote:

- Dosta ljudi customizuje Magento, ne znam sta je u tvom slucaju.
- WP teme imaju svoje SQL upite, to sto WP radi sa 5.7 (radi, WP je OK), ne znaci da ce sve u tvojoj varijanti da radi - jer ti kazes da imas 10-20 WP sajtova. Imaju li svi samo basic temu?

Imas dva resenja:

- Nadjes ljude koji su odgovorni za svaki od sajtova i pitas njih.
- Probas pa vidis. Ali moras da probas sve opcije, svakog sajta...

Malo ides na slepo, ali ocigledno tako moras. Samo polako, istestiraj dok jos nije u produkciji.

Za Magento ti je Bogdan lepo rekao: Ako nemas pare za komercijalni magento, moras da stavis ispred ili Varhish ili nesto slicno, Magento je generalno jako spor. Ne znam sta ti znaci "Memorija 8/64" sto si napisao, ali ako imas 64GB RAM-a, stavi slobodno i 32GB u InnoDB Buffer pool. Naravno, ne stavljaj vise od kompletnog tablespace-a, ali nikako ne stavljaj ni manje od kompletne velicine indexa.

Zapravo, dobar pocetak je da saberes koliko ti je kompletan tablespace i koliko ti od toga uzimaju indexi.
[ anon70939 @ 12.03.2017. 19:52 ] @
Stavio sam za sada kao sto je bilo na proslom serveru, doduse samo ovo

query_cache_type = 1
join_buffer_size = 186M
tmp_table_size = 144M
max_heap_table_size = 512M
table_open_cache = 1200
innodb_buffer_pool_size=13G

I sajt je poleteo. TTFB se smanjio na minimum.
Samo prvi put dok očita stranicu traje tih nekih 7sec, posle otvara momentalno. Bukvalno leti.

OK, bilo mi je bitno da znam da je do toga, sad ću da nastavim da čitam i da "tjunujem"

Nadam se da shvatate koliko sam vam zahvalan što ste tu :). U RL nemam sa kim da se konsultujem, i moje znanje je guglanje, tako da piskaranje po ES mi puno znači..
Prošli put, pre više od godinu, kad sam ufonjao sa update sa 5.5 na 5.7 i napravio cirkus koji me koštao puno nespavanja i stresa, tada mi je Bogdan napisao "sledeći put pitaj pre nego što kreneš u takvu avanturu". :)
[ anon70939 @ 12.03.2017. 22:25 ] @
Guglao malo nasao lika koji ima slican server i okacio svoj neki setup.
Uradih copy paste, plus mysql tuner malo editovao i ne mogu da verujem kako sajt radi. :)

Ovo je neki setup.

query_cache_type = 1
join_buffer_size = 186M
tmp_table_size = 144M
max_heap_table_size = 144M
table_open_cache = 1200
query_cache_limit = 256M


innodb_buffer_pool_size = 24G
innodb_buffer_pool_instances = 24
innodb_log_file_size = 100M
innodb_flush_log_at_trx_commit = 2
innodb_lock_wait_timeout = 1800


net_read_timeout = 120
thread_cache_size = 16
back_log = 100
max_connect_errors = 10000
open-files-limit = 20000
interactive_timeout = 3600
wait_timeout = 1800
max_connections = 200
key_buffer_size = 1G
connect_timeout = 120

max_allowed_packet = 16M
query_cache_size = 256M
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 8M
join_buffer_size = 3M
[ bogdan.kecman @ 13.03.2017. 01:06 ] @
oba ta selekta ti vracaju sortirano po "problematicnosti" dakle ti u
vrhu su najproblematicniji .. dodaj limit 10, pa resi 10 prvih
najproblematicnijih upita

ako taj myisam prepevas u innodb mozda resis problem, zavisno kako si
konfigurisao sta, myisam pristup fajlovima se ne kesira u mysql-u vec
samo sistemski dok se pristup innodb tabelama kesira kroz innodb buffer
pool.. plus je kesiranje u buffer pool-u inteligentno etc etc..

query_cache_type = 1 -> ovo ne valja, treba da ugasis query cache a da
montiras reverse cache za sajtove (nginx ili varnish)

> mo prvi put dok očita stranicu traje tih nekih 7sec, posle otvara
momentalno. Bukvalno leti.

iskesirao ti se upit, ali ce da ispadne iz kesa brzo + ti to usporava
svasta nesto drugo, posebno kada isti rdbms koristi vise sajtova... imas
neke upite koji "ne valjaju" trebalo bi da ih nadjes....

select * from sys.statements_with_full_table_scans order by total_latency desc;

ovo ti vraca upite koji su full table scan, rece da si dobio 1200 ->
1200 upita koji ne koriste index!!!!!!!!!!!!!!!!!!!!

umesto da dizes qcache (evo ti dobar tuner za query cache:
https://dom.as/tech/query-cache-tuner/ ) nadji odakle dolaze ti upiti
koji ti kolju bazu koji ne koriste indexe i resi ih
[ anon70939 @ 22.03.2017. 22:45 ] @
Citao sam malo ovih dana, nista nesto posebno nisam shvatio :D, ali sam naleteo na neke savete bas za magento, i tamo je isto savet da query_cache_type bude 0. Odnosno da ga sklonim iz my.cnf jer je valjda u verziji 5.7 default da je 0.

Sad mi je ovo cnf, i mysql opterecenje mi je manje od 1%.

Citat:
### SAFETY #
innodb = force
max_allowed_packet = 250M
max_connect_errors = 100000
skip-name-resolve


### MyISAM #
key_buffer_size = 16M # keep it low if no myisam data
myisam-recover-options = FORCE,BACKUP

#innodb settings
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2
innodb_lock_wait_timeout = 7200
innodb_buffer_pool_size = 50G
innodb_thread_concurrency = 0
innodb_flush_method = O_DIRECT
innodb_log_files_in_group = 2
innodb_log_buffer_size = 32M
innodb_file_per_table = 1
innodb_read_io_threads = 8
innodb_write_io_threads = 8
innodb_buffer_pool_instances = 4



#other vars

back_log = 20
interactive_timeout = 7200
wait_timeout = 7200
net_read_timeout = 120
net_write_timeout = 300
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 2M
join_buffer_size = 2M
tmp_table_size = 128M
max_heap_table_size = 128M
max_connections = 150
thread_cache_size = 32
#thread_pool_size = 16
open_files_limit = 65535
table_definition_cache = 4000
table_open_cache = 4000



Još samo da skontam nginx kako da namestim
[ bogdan.kecman @ 22.03.2017. 23:14 ] @
query cache je stvar koja je jaaaaaaaaaako retko korisna, u
99.99999999999999% slucajeva treba da bude ugasen

(ko sto ti vec napisah)

za nginx -
https://www.digitalocean.com/c...-as-a-reverse-proxy-for-apache
[ nkrgovic @ 23.03.2017. 09:41 ] @
[quote]CoyoteKG:
Citat:
### SAFETY #
innodb_buffer_pool_size = 50G

Meni je ovo malo mnogo, ako ti masina ima 64GB RAM-a.

Koliko ti zauzima baza na disku? Fizicki, daj du -hs /var/lib/mysql ?

P.S.

Da li znas sta ovo znaci:

innodb_flush_log_at_trx_commit = 2


Ovo ti je donelo performanse, ali da li si siguran da zelis da zivis sa ovime? Procitaj dokumentaciju, razmisli da stavis na 1 , proveri performanse....
[ anon70939 @ 23.03.2017. 17:24 ] @
# du -hs /var/lib/mysql
5.6G /var/lib/mysql



stavio sam 50 jer je to blizu preporucenih 80% ukupnog rama.
Pojma nemam sta znaci, i citao sam ali mi nije bas jasno.

Nego... sludeo mi se malopre server. Verovatno neki zaheb sa mysql. Fenomenalno radio od sinoc do malopre, i malopre se nanizalo 20 zapocetih kojekakvih procesa, Load Average bio preko 3... :/
Vratio sam stara my.cnf podesavanja i sad je ok... :/

Odoh da popijem pivo
[ bogdan.kecman @ 23.03.2017. 18:30 ] @
ceo datadir ti je ispod 6G, nema svrhe da imas innodb_buffer_pool koji
je veci od toga

sto se tog loada tice, nema to veze sa konfigom, ti imas tu neke silne
fts-e garant i to ce ti uvek zabosti masinu.. mora pocistis aplikacije
koje ne rade... zbog takvih stvari ja ne podnosim shared hosting,
dovoljan ti je jedan pajser da ti totalno zakuca server
[ anon70939 @ 23.03.2017. 21:00 ] @
pa pazi... nemam znanja jbg, ali metodom eliminacije saznajem da mi je mysql definitivno problem.

Prebacim bazu ovog magento sajta na drugi server. mnogo slabiji.
Kako sam ga prebacio na ovom prvom serveru apache se smiri skroz. Load padne sa 65 na 15%.
Baza ovamo na slabijem serveru miruje. load 3%. A ovamo je kad je sve OK pucala i 25%, kad nije ok onda 500%

Razilka je sto ovamo je verzija
mysql Ver 14.14 Distrib 5.5.44

my.cnf fajl na ovom slabijem serveru
Citat:
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0

[mysqld]
bind-address = ::
skip_name_resolve
local-infile=0

user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking

key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8

myisam-recover = BACKUP

query_cache_limit = 1M
query_cache_size = 16M

log_error = /var/log/mysql/error.log

expire_logs_days = 10
max_binlog_size = 100M

[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[mysql]


[isamchk]
key_buffer = 16M

!includedir /etc/mysql/conf.d/



edit:

aaaahh... i ovamo slican problem imam. Cim pokrenem magento reindex mysql poludi.
sad sam na ovom matorom serveru gde mi je mysql 5.5 (dakle vratio sam ga sa novog koji je 5.7 nazad) i okinuo sam komandu
mysqlcheck -u admin -p --auto-repair --check --all-databases

Jesam li to trebao posle transfera baze ovog magenta na novi server? Ja sam kapirao kad dampujem bazu i importujem je, da ona prodje taj check?



[Ovu poruku je menjao CoyoteKG dana 23.03.2017. u 23:20 GMT+1]
[ anon70939 @ 24.03.2017. 00:53 ] @
Resio problem upravo, i nije mi jasno kako ranije nisam zakljucio.
Ovo je neka prastara verzija magenta, nikad patchovana. Radi na php 5.4. Switchovao sam ga samo na 5.4 i server je progledao.
[ nkrgovic @ 24.03.2017. 07:46 ] @
PHP na 5.4? Uhh.... Mislim da to nema vise podrsku, ni security patcheve. Vidi mozes li da probas bar 5.5 ? Proveri da li taj Magento radi na 5.5 ili 5.6 i stavi na cemu radi, ne stavljaj najstariju... :)

Poslusaj savet, smanji InnoDB buffer na 6GB, bolje da OS kesira nesto nego da MySQL drzi prazan buffer. I proveri ovo sto sam ti napisao za trx_commit.
[ anon70939 @ 24.03.2017. 08:39 ] @
http://devdocs.magento.com/guides/m1x/system-requirements.html

Na 5.6 je bio i tu je pucao. Ali koliko na ovom linku vidim radice n 5.5

Smanjio sam inno buffer i iskljucio trx. Ali sajt mi nije radio pa sam morao da prebacim bazu na drugi server. Nocas cu opet vratiti.
Treba li mysqlcheck da radim ili nesto slicno kad prebacujem jednu bazu sa jednog servera sa mysql 5.5 na drugi sa 5.7?
Radim obican mysqldump -u username -p dbname > file.sql
I importujem sa mysql -u username -p dbname < file.sql
[ anon70939 @ 08.04.2017. 00:37 ] @
samo eto da javim, da sam sada siguran da nije (samo) do sajta nego i do toga sto je MySQL 5.7.
Digao sam neki nov backup server i probao na njemu, tu je 5.6 verzija i baza radi odlicno..

Test mi je pokretanje tog nekog magento reindex-a. Koji mi traje vise od 1h.
Na ovim serverima do sada gde mi je 5.7 tu kad pokrenem reindex kao sto sam vise puta opisivao, CPU poludi i ceo server zabode...
Na serveru gde mi je do sada bila baza sa 5.5 taj problem nisam imao.
A evo sada i na 5.6, default my.cnf opet sve ok.

Al ok, tako cu i da ostavim. Neka je baza na tom serveru :)