Fórum Root.cz
Hlavní témata => Server => Téma založeno: miro 06. 05. 2015, 13:44:18
-
Zdravim,
mam aplikaci v PHP ktera vyuziva MySQL databazi. Testoval jsem ji na slabem serveru (virtual - 4 jadra, 1GB pameti), kde je Debian Wheezy a MySQL 5.5.41, vychozi konfigurace.
Pro produkci jsem si pripravil server, kde byl CentOS 7 (ktery znam lepe nez Debian) a MariaDB, taktez 5.5.41. Jenze to, co na testovacim serveru bezi 2 sekundy, na tomhle trva 80 - naprosto shodna konfigurace, zkousel jsem i ruzne co jsem nasel na internetu, doporuceni z MySQL Tuneru, vsechno mozne, jedine ceho jsem docilil bylo, ze se to jeste zhorsilo.
Zkusil jsem pak jeste jiny hosting a nainstaloval tam Ubuntu 14.04 a MySQL server, opet 5.5.41. Uz je to lepsi, query trva 20 vterin, ale stale je to NESKUTECNE pomale. Zkousel jsem ten stroj roztahnout (je to skalovatelny virtual) - dodat vice CPU jader a RAM, ale naprosto beze zmeny, porad stejnych 20 vterin.
Query obsahuje hromadu insertu za sebou, ktere tomu trvaji dlouho. Neni to prilis optimalni, ale jaktoze se vykon tolik (10x-40x) lisi na ruznych strojich s naprosto stejnou konfiguraci? Pomohlo by misto MySQL pouzit jinou databazi, treba PostgreSQL?
-
Dodejte výsledky EXPLAIN: https://dev.mysql.com/doc/refman/5.5/en/explain.html na obou strojích
Bez toho to nepůjde...
-
"ale jaktoze se vykon tolik (10x-40x) lisi na ruznych strojich s naprosto stejnou konfiguraci? Pomohlo by misto MySQL pouzit jinou databazi, treba PostgreSQL?"
Naprosto stejna konfigurace - rovnako rychly storage? Porovnavat virtualy medzi sebou je dost problematicke, nikdy nevies na com to realne bezi a ako je to vytazene. Zaklad je porovnat query plan ci sa z nejakeho dovodu nevykonava inak. Zmena db servera ti zrejme nepomoze.
-
jaktoze se vykon tolik (10x-40x) lisi na ruznych strojich s naprosto stejnou konfiguraci?
Nedostatek iops, projevuje se hlavně při INSERT. Pomůže vypnout fsync, to ale není bezpečné.
DB od které se očekává nějaký výkon se zásadně provozuje na dedikovaném storage.
-
Obvykly bottleneck u mysql jsou i/o operace, pust iotop, iostat a sleduj...
-
Speciálně pro MySQL doporučuju velké množství INSERTů a UPDATEů sloučit do co největších transakcí. Výkon vzroste násobně. Má vlastní zkušenost, kvůli velkému počtu nahodilých zápisů jsem na jednom serveru speciálně psal kolektor, který všechny zápisy od různých zdrojů/uživatelů posbíral během dvousekundového okna a pak je jednorázově provedl a commitnul. Mezitim se v jiném dvousekundovém okně sbíraly další zápisy. Nevýhodou bylo, že data se do databáze reálně zapsala až po 2 - 4 sekundách po vykonání příkazu. Protože jsme ale stejně replikovali, frontend s tím počítal.
-
jak již bylo zmíněno klasika i/o to je vec kterou většina hostingu s virtualy silene trpi
vps jsou krasne na hrani atd... ale ve chvíly kdy dojde na lámání chleda tahle technologie mi prozatím nepříjde jako dobrá, ale sou situace kdy se hodí (pokud po serveru bud nic nechcete, nebo naopak chcete provest hromadu vypoctu s daty co se vlezou do ram)
-
Ten CentOS (kde to bylo nejhorsi) nebyl virtualni... Jinak EXPLAIN bych zaslal rad, ale query se tvori ORM v PHP a zatim jsem neprisel na to, jak z nej query dostat.
-
mysql umí logovat pomalé dotazy. Takže si ten explain uděláš na tom co si v tom logu přečteš
-
Ten CentOS (kde to bylo nejhorsi) nebyl virtualni... Jinak EXPLAIN bych zaslal rad, ale query se tvori ORM v PHP a zatim jsem neprisel na to, jak z nej query dostat.
na toto používam WireShark s filtrom mysql.query
-
1) mysql ma slow query log
2) pokud hodne insertujes tak virtual s 1GB RAM a aspon trochu slusnym SSD ti rozdrti jakejkoliv dedikac s bambilionem CPU a kopcem RAM (pokud ten kopec RAM nevyuzijes jako write cache)...
-
Ten CentOS (kde to bylo nejhorsi) nebyl virtualni... Jinak EXPLAIN bych zaslal rad, ale query se tvori ORM v PHP a zatim jsem neprisel na to, jak z nej query dostat.
Ted si delas srandu?
Protoze jestli ne tak je to k placi.