MySQL -> MariaDB lassulás

Adatbázis: SQL, XML DB

Sziasztok,

 

adott egy régi rendszer, Debian 8, MySQL 5, 2 db SATA diszken (Linux mdraid) az OS, és az egész LAMP stack. A gépben 8 CPU van és 8G RAM.

Van egy új rendszer, Debian 10, MariaDB 10, 2 db M2 SSD az OS-nek, és 2db M2 (Intel szerver) SSD a MariaDB-nek. Az SSD-k alatt van egy LSI HW raid vezérlő. A gépben 24 CPU van és 32G RAM.

Adott egy sql dump, ennek a betöltése a régi szerveren (különösebb tunnig nélkül, alapbeállításokkal):

real    17m2.267s
user    1m6.752s
sys     0m6.300s

Ugyanez az új gépen (tuning után):

real	28m12,458s
user	4m0,385s
sys	0m6,733s

Amit eddig módosítottam:

key_buffer_size        = 4096M
max_allowed_packet     = 32M
query_cache_size       = 128M
skip-log-bin
open-files-limit       = 65535
myisam_repair_threads  = 4
innodb-strict-mode     = 0

Ezek közül a myisam_repair_threads 4-re történő felemelése vitte le 32-35 percről a mostani 28-ra.

Mit lehetne/kellene még állítani, hogy legalább azt a szintet elérjük, amit a régi rendszer produkál? Az elvárás nyilván valami performancia javulás lenne, azaz gyorsabban töltődjön be a dump...

 

Köszi.

( andrej_ v | 2021. 03. 08., h – 20:57 )

Szerkesztve: 2021. 03. 08., h – 20:57

A dev.mysql.com -ról a MySQL 5.7-et próbáltad? Nekem Drupal site-okat kiszolgáló VM-nél volt ilyen problémám. Ragaszkodtak a MariaDB-hez, de klasszik MySQL-re kellett váltani, mert sehogy se jött ki a matek.

Ha a HW RAID-et kiveszed az SSD képletből, nem javul? A Linux mdadm lehet jobban kifuttatja az SSD-ket.

A régi gép véletlenül nem egy magas órajeles Xeon E-1xxx valami és az új pedig egy alap multisocket CPU, ami mondjuk 2,5GHz?

A dev.mysql.com -ról a MySQL 5.7-et próbáltad?

Nem - de amúgy van már 8.0 is, az nem lenne jobb?

Nekem Drupal site-okat kiszolgáló VM-nél volt ilyen problémám. Ragaszkodtak a MariaDB-hez, de klasszik MySQL-re kellett váltani, mert sehogy se jött ki a matek.

Bocs, ez mit jelent, hogy nem jött ki a matek?

Ha a HW RAID-et kiveszed az SSD képletből, nem javul? A Linux mdadm lehet jobban kifuttatja az SSD-ket.

Próbáltam elkerülni a HW raid-et, de sajnos mindenképp be kell állítani a kontrolleren a diszkeket, legalább RAID0-ba (egy eszközzel), ha JBOD-t akarsz. Akkor meg már inkább legyen HW raid.

Amúgy maga a diszk teljesítmény pl bonnie++ alapján sokkal jobb, mint a régi rendszeren.

A régi gép véletlenül nem egy magas órajeles Xeon E-1xxx valami

nem E1, hanem E3 (4/8) :), de magas órajellel (3.4GHz)

és az új pedig egy alap multisocket CPU, ami mondjuk 2,5GHz?

de, igen, ez egy E5 (6/24). De ez az órajel különbség magyarázat erre teljesítményre? (Bogomips-ben elmarad az új CPU (6800 a régi, 4200 az új), de egy dump betöltésnél ez ilyen eltérést okozna?)

Ha E3, akkor az bőven 3,4GHz fölé turbóz 1 szálon. Az E5-ös lehet csak 2,8-3GHz-ig megy. Bazisokat jelent a CPU órajel (pláne ha mondjuk E5 v1-2 az új és E3 v3-4 a régebbi gép). Ilyen összehasonlítást csak pontosan azonos gépen szabad megtenni. Erre még rátehet, hogy a hwraid kártya iops-ban megfogja valamennyire az SSD-ket, bár a SATA-t simán hoznia kéne szerintem.

Drupal VM vs. MariaDB vs matek: lassú volt, sehogy se sikerült a kortárs MySQL sebességet hozni, az "elavult" query cache se ment úgy, aztán a MySQL-el szárnyakat kaptak az oldalak. Ez 5 éve volt, azóta sokminden változhatott.

A MySQL 8 igensok újdonságot hoz, például az authentikációban, nem eröltetném.

Mielőtt bármilyen SQL verziót cserélsz legyen mentésed bőségesen, mert egymás és a verziók saját file formátumában kavartak bőven.

Bazisokat jelent a CPU órajel (pláne ha mondjuk E5 v1-2 az új és E3 v3-4 a régebbi gép).

Ezt elhiszem, de nem tudom, egy ilyen feladatnál ez tényleg ennyire releváns-e...

Ilyen összehasonlítást csak pontosan azonos gépen szabad megtenni.

Mondjuk ez elég kényszerű összehasonlítás - nem az a cél, hogy összehasonlítsam a kettő, hanem hogy az egyik utolérje a másikat.

Erre még rátehet, hogy a hwraid kártya iops-ban megfogja valamennyire az SSD-ket, bár a SATA-t simán hoznia kéne szerintem.

Nyilván lehetne szofisztikáltabban is mérni, lent látsz bonnie++ ereményeket, itt pedig egy "fio":

régi:

  read : io=204092KB, bw=1784.6KB/s, iops=446, runt=114364msec
  write: io=51908KB, bw=464777B/s, iops=113, runt=114364msec

új:

  read: IOPS=37.7k, BW=147MiB/s (154MB/s)(200MiB/1358msec)
   bw (  KiB/s): min=148568, max=152048, per=99.80%, avg=150308.00, stdev=2460.73, samples=2
   iops        : min=37142, max=38012, avg=37577.00, stdev=615.18, samples=2
  write: IOPS=9474, BW=37.0MiB/s (38.8MB/s)(50.3MiB/1358msec); 0 zone resets
   bw (  KiB/s): min=37592, max=38280, per=100.00%, avg=37936.00, stdev=486.49, samples=2
   iops        : min= 9398, max= 9570, avg=9484.00, stdev=121.62, samples=2

(az új gépen frissebb "fio" van, ezért más a kimenet is). Szerintem nem nagyon fogja meg IOPS-ben sem (a bonnie++-nál a random tesztek néha lassabbak, de ez sem reprodukálható mindig).

Drupal VM vs. MariaDB vs matek: lassú volt, sehogy se sikerült a kortárs MySQL sebességet hozni,

Ez viszont akkor azt jelenti, hogy a MariaDB-vel volt valami teljesítménybeli probléma? Ez pl. lehet támpont.

Én elsőre a CPU-ra tippelnék, hogy az komolyan bennevan a sebesség különbségben. Az E5-nél inkább a sokmagos széltében skálázódás volt a cél. Ha egy mai E Xeont megnézel, akkor simán 6 magot és akár 5GHz-es turbót is kapsz. Egy sokmagos Scalable Xeon vagy Epyc nem fog úgy pörögni, cserébe akár 64 magod is lehet Epyc-en. Egyébként mi a két konkrét CPU típusod?

Ahogy írtam, ez egy 5 éves MySQL vs MariaDB probléma volt, és azóta változhatott. Egy próbát megér, hogy mondjuk az 5.7-es MySQL mit mutat nálad a fentire. Miután a storage a tesztjeid szerint bőven jobb az új gépben, nemnagyon látok más próbálnivalót.

(Használok élesben Xeon X56xx-eket, E5 v2-ből mindenfélét, E5-1650-et, E-21xx és E-22xx Xeonokat is, ráadásul mindezek általában valamilyen webes vagy virtualizált témában mennek, főleg Apache+PHP és valamilyen SQL vonalon.)

Köszi - értem a CPU összehasonlítást, de még mindig nem látom, mi az a számítási kapacitás igény egy MySQL load-nál, ami így megfogja a procit.

A MySQL 5.7 teszt be van tervezve, jelzek, ha lesz fejlemény.

Amúgy ma csináltam egy dump tesztet is, ugyanazt a táblát lementettem mind a két gépen, hát is jobb a régi gép (28s vs 48s).

Most a dump-ba betettem minden művelet elé egy-egy SELECT NOW()-t, megpróbálom megnézni, mi az, ami lassú.

indexek újraépítése?

Igen, részben. Ez amúgy látszik is - egy táblát kidumpoltam (a dump sima text, ahogy írod), és minden művelet elé betettem SELECT NOW()-t. A tábla visszatöltése kb 10p volt, ebből 4p volt az ENABLE KEYS, de 6p volt csak maga az INSERT.

Nem tudom, hogy a DISABLE KEYS esetén van-e folyamatosan index építés, de ha nincs, akkor a puszta INSERT INTO 6p-es ideje is soknak tűnik. A régi szerveren 2:14 (2p 14mp)) az INSERT és 2:28 az ENABLE KEYS.

Röviden minden, nyilván van ami többé és van ami kevésbé, ahogy ezt lentebb tárgyaltátok is. Ha egy E3-12xx v4-ből ez izmosabbat cseréltetek E5-26xx v2-re, akkor ott nemcsak az órajel, hanem az 5-15%-os IPC különbség is képbe kerül, pláne ha épp valami optimalizáció még kedves is mondjuk az SQL-es használatnak a v4 javára. Mivel akár bő 1GHz-es különbségről simán szó lehet, az már erősen érezhető.

Még mindíg elég sűrűn találkozom azzal, hogy a "szupernagy" órajeles desktopon vagy devel szerveren hasít valami és utána az ugyanolyan sw környezetű a dualsocket enterspájz szerverből "hiányzik a performancia". Az más kérdés, hogy ez majd 4x annyi párhuzamos juzert kiszolgál hasonlóan, de egy szálon gyérebb. Mondjuk az sem segít, hogy 50GB-s adatbázist próbálnak hipphopp használni.

Vagy elengeded a sztorit, vagy az E5-ös szériából nézel egy izmos darabot (E5-2680 v2 vagy E5-2667 v2, vagy a v3/v4, ha újabb eggyel a sztori), de jellemzően egyszálon egy 8 magos E-22xx lemossa, mert akár 5GHz-ig megy a turbója és IPC-ben erősebb. Ez  napi tapasztalatból jön, semmi obskurus nincs benne.

Köszi mindent, egyelőre elengedtem. Most sikerült 23-25%-al lejjebb vinni a betöltési időt, ezt a jövőben valahogy átalakítjuk. Viszont hosszú távon valszeg fontosabb lesz a több user kiszolgálása.

Ez napi tapasztalatból jön, semmi obskurus nincs benne.

Igen, sajnos ezt elég nehéz papíron tervezni :).

( voiper | 2021. 03. 08., h – 21:22 )

Esetleg próbáld ki ilyen módon:

 

SET autocommit=0;
SET unique_checks=0;
SET foreign_key_checks=0;

.. sql import query

COMMIT;
SET unique_checks=1;
SET foreign_key_checks=1;

Köszi, kipróbálom - bár ua az értéke mindkét hoszton.

Jellemzően ezek tartanak "sokáig":

+---------+------+--------------------------+-----------------------------------------------------+----------+
| Command | Time | State                    | Info                                                | Progress |
+---------+------+--------------------------+-----------------------------------------------------+----------+
| Query   |  226 | Parallel repair          | /*!40000 ALTER TABLE `table1` ENABLE KEYS */        |    0.000 |
+---------+------+--------------------------+-----------------------------------------------------+----------+

Ez az ENABLE KEYS (az INSERT előtt van egy DISABLE KEYS, ezért kell ez - de része a dump-nak) a nagyobb rekordszámú tábláknál több perc.

( STP | 2021. 03. 08., h – 21:54 )

Mielőtt szétreszeled a DB-t...

A random write teszt az új vason jobban teljesít?

P

Hmmm... nem.

A szekvenciális írásnál és olvasásnál messze jobb értéket produkál az új diszk. A szekvenciális létrehozásnál (bonnie++ - sequential create/create) még jobb, de itt a read és a delete már rosszabb. A random create és random seek esetében pedig a régi rendszeren jobb eredményt ad a diszk - bár itt van néhány paraméter, ahol a bonnie csak latency eredményt ad, maga az átvitt adatmennyiség nincs ott (csak "+++++" karakterek).

Hogy lehet ezeket az adatokat kideríteni? Milyen más tool van még, amivel lehet ilyet tesztelni?

Szerk.: bocs, lehet, hogy elnéztem valamit, de az is lehet, hogy a bonnie formázó tool-ja szar (bon_csv3html).

A raw adatok:

régi gép:

# bonnie++ -d . -r 2048 -u airween -s 0 -n 1024

Version  1.97       ------Sequential Create------ --------Random Create--------
server              -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
               1024 84078  55 927317 100 128665  51 26913  93 1097046  99 124146  59
Latency             36273us     332us    4829us     186ms      61us    3815us

új:

# bonnie++ -d . -r 2048 -u airween -s 0 -n 1024

Version  1.98       ------Sequential Create------ --------Random Create--------
server3             -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
               1024 1048576  96 1048576 100 1048576  83 1048576  96 1048576 100 1048576  74
Latency              1204us     397us     490ms   86248us      26us     522ms

Ez alapján pl az új diszk jobb.

Én megpróbálnám mindkét gépen ramdisk-ről futtatni. Ha a régi gépen 17 s alatt "felszívta", akkor bele kell férnie, még ha szűkösen is. Akkor kijön a különbség, hogy tényleg a háttértár, vagy pedig a CPU vagy kód probléma. Bár az eddigiek alapján 99% az utóbbi, tehát sok újat nem hozna egy ilyen mérés.

Én megpróbálnám mindkét gépen ramdisk-ről futtatni.

Az a gond, hogy elég nagy maga a DB, 11G ez a dump, amivel "játszok". Az új gépen még csak-csak meg lehetne oldani, de a régin nem igazán.

Ha a régi gépen 17 s alatt "felszívta",

Az 17 perc volt :).

háttértár, vagy pedig a CPU vagy kód probléma. Bár az eddigiek alapján 99% az utóbbi

Mármint a kód? Azaz a MariaDB ennyivel gyengébb lenne?

Van rá esély.

„Furthermore, whenever a delete command is issued by the user or the operating system, the TRIM command immediately wipes the pages or blocks where the files are stored. This means that the next time the operating system tries to write new data in that area, it does not have to wait first to delete it.”

https://www.digitalcitizen.life/simple-questions-what-trim-ssds-why-it-…

 

Persze ehhez látni kéne az I/O wait értéket is, hogy csak néhány % vagy bőven 2 számjegyű a betöltésnél.

nem azt irtam hogy ne hasznalja hanem hogy uj ssd-nel nem fog szamitani, nem lesz tole gyorsabb az import

egyebkent sem gondolom hogy sokat dobna rajta, LUKS-ot hasznalok TRIM nelkul, vagyis minden szektort torolni kell iras elott:

# dd if=/dev/zero of=teszt.img bs=1G count=20 oflag=direct

21474836480 bájt (21 GB, 20 GiB) másolva, 43,9905 s, 488 MB/s

bar ez lehet ssd fuggo is

neked aztan fura humorod van...

Egyébként SSD esetében mit jelent a "random" teszt? Mármint hogy kell/lehet értelmezni?

Hagyományos tárolóknál volt a C/H/S elrendezés, ami a tároló fizikai kialakításából adódott. Gondolom a kompatibilitás miatt az SSD-k is megtartották ezt a rendszert, de itt nincsenek cilinderek, fejek és szektorok, itt nincs rángatva a fej, és nem pörög a diszk. A hagyományos diszkeknél értelemszerű szekvenciális vagy random írásról és olvasásról vagy beszélni. De hogy kell ezt elképzelni SSD-nél?

C/H/S az kb. 25 éve volt utoljára, és már akkor sem jelentett nagyon semmit. Az IDE diskek lényege, hogy megmondhatod neki a címet, de a fizikai szektor ott lesz, ahol ő szeretné. Ettől függetlenül mind CHS, mind LBA módban van egy "térkép", és a nagyobb eltérések nagyobb ugrásoknak fognak megfelelni a tányéron is.

Egyébként SSD esetében mit jelent a "random" teszt? Mármint hogy kell/lehet értelmezni?

Az ssd belső szerkezete úgy néz ki, hogy aszimetrikus a törlés és az írás művelet szempontjából. Azaz míg az üres biteket akár egyesével is lehet gyorsan a 1->0 irányban állítani, addig a fordított irányhoz egy egész nand erase block méretű részt egyben lehet csak törölni, ráadásul ez egy relatíve lassú művelet (ms-okban mérik). És ahogy nőnek az ssd-k, úgy lesz ez az erase block egyre nagyobb, de már régen is a 128-256KB körül volt, most már inkább az MB nagyságrendjébe esik.

Emiatt az ssd vezérlő nyilvántartja, hogy hol van hasznos adat, és hol nincs. Valamint ha már hasznos adatot tartalmazó területen egy kisebb blockot ki akarsz cserélni, akkor a nagyobb törlés szükségessége és lassúsága miatt ez egy read-modify-write művelet formájában fog megtörténni, egy új üres területre (aztán a régi használt területet majd valami háttérfolyamat felszabadítja), a kiírandó adatmennyiség jelentős növekedése mellett.

A random I/O írás teszt (jellemzően valamilyen kisebb I/O mérettel) valójában ezt a működést teszteli.

A random I/O olvasás teszt a cache-elést meg az I/O kérésenkénti overheadet teszteli a szekvenciális teszthez képest.

( airween v | 2021. 03. 09., k – 10:23 )

Kipróbáltam az 5.7-es MySQL-el a dev.mysql.com-ról - tuning nélkül 37 perc volt a betöltés, szal' nem ez lesz a megoldás.

Igen, most ennek a vizsgálata folyik. A performancia nem lett rosszabb a DB egyéb felhasználásánál. Van egy két SELECT, aminél jobb eredményeket vártunk, és "csak" ua, mint a régi rendszeren - de ezek még csak a default install utáni első tapasztalatok.

Viszont most utánanéztem a MariaDB-nek, hogy lehet több CPU-s rendszeren finomítani, hogy több felhasználó esetében jobb teljesítményt adjon, ezt még tesztelni kell. Ez talán a már talált lekérdezéseken is javít.

( hokuszpk | 2021. 03. 09., k – 11:00 )

tmp-table-size -t minimum duplazd meg, de mehet 1GB vagy fole is.

HUP te Zsiga !

( Mcsiv v | 2021. 03. 09., k – 12:14 )

Igaz nem írtál konkrét típust, de szerintem a proci lesz a problémád, egy dump betöltése egy szálon megy, így hiába van 3* annyi mag az új gépben ha a single thread teljesítménye kevesebb (a háttérben az index-ek újraépítését tudja csak több szálra szétszedni, de ott se fogja az összes cpu-t kiterhelni).

Szedd szét az adatbázist táblákra és párhuzamosan told be az összeset, vagy CPU csoportokra és úgy bindelve párhuzamosan

// Happy debugging, suckers
#define true (rand() > 10)

Igen, kb erre jutottam én is - bár én azt gondoltam, a CPU alacsonyabb órajelét kompenzálni fogja valahogy a gyorsabb diszk. Eleve az adatbázisoknak külön diszk jutott, és alapból sokkal gyorsabb az egész alrendszer. A régin a dumpot ugyanarról a diszkről olvassa fel a rendszer, amire betölti - itt még ez is meg van oldva.

Az is látszik szépen, hogy mikor betölt egy táblát és az ENABLE KEYS-hez ér, akkor ott a processz CPU használata felmegy 100%-ról 3-400%-ra. De még így is lassabban generálja le a kulcsokat, mint a régi gépen.

A dumpot mentésekből szedtem elő, most macerás lenne szétszedni, de ezen még lehet, hogy dolgozunk majd.

A betöltés 1 szálon megy, a kulcsok reindexelése pedig X szálon (attől függően, hogy tudja optimálisan darabolni a taskot a db).

Ez a régi gépen is ugyan így fog történni: betöltés 1 szál, reindex X szálon, ami ugyan azon a dumpon vélhetőleg pontosan ugyan annyi X-et fog jelenteni a gyorsabb processzorból mint a lassabból, vagyis pont azt nem használod ki amiből az új gép jobb, hogy több X lehet, cserébe pont abba ütközöl amivel rosszabb, hogy ugyan annyi X performanciája rosszabb.

A diszk alrendszer előnye egy dump betöltésnél egészen biztosan nem tud megmutatkozni (mert CPU heavy folyamat és itt pont CAP-be futsz), az előnye majd az életszerű workload alatt lesz óriási segítség.

dump-old ki darabolva a már most tesztelésre betöltött db-t ;)

// Happy debugging, suckers
#define true (rand() > 10)

A betöltés 1 szálon megy, a kulcsok reindexelése pedig X szálon (attől függően, hogy tudja optimálisan darabolni a taskot a db).

Igen, erre írtam, hogy ezt már állítottam (a kulcs indexelődés szerintem nem fog automatikusan több szálra bontódni, kell hozzá ez: https://mariadb.com/kb/en/myisam-system-variables/#myisam_repair_threads). De a régi szerveren ennek 1 az értéke, és még így is jobb értéket produkál, csak az indexelésre is. Amíg nem emeltem fel ennek az értékét, a CPU használat nem ment 100% fölé, és ez volt az első olyan paraméter, ami amúgy dobott az eredményen.

Mindegy, egyelőre elengedem ezt a témát, elkezdődik a teszt, remélem a napi használatban jobb lesz.

A mentésról nem tudok pontos adatot mondani, mert szerintem az új szerveren nem volt full dump (mármint az érintett DB-ről nem készült teljes dump, a régin levő mentés elég volt). Szétszedve szálakra (4 konkurens szálat engedtem, de ez növelhető) kb. 1.5p volt a teljes dump (> 300 db tábla van kb - ez olyan 22GB). A régi rendszeren ez kb 13-15p volt.

A betöltés először volt 35p volt, optimalizálás nélkül, de ez csak egy része volt a teljes DB-nek (kb ilyen törzsadat jellegű, ez változik negyedévente). Optimalizálás után lement 27 percre, utána már nem csináltam ilyen parciális betöltést. Egy nagy tábla van, ami érintett, ez kb 10p, valszeg ez a konstans idő meg is marad.

A teljes DB betöltése (tehát a > 300 tábla, 22G adaté, 4 szálon) most így kb 15-16 perc lett. Egyelőre ez jelentős javulás, és mind a mentés, mind a visszatöltés így sokkal jobb, mint korábban (nem csak ezen a gépen, hanem a régin is). Nyilván ott is lehetne több szálra szedni - ezt ilyen félmegoldással ki is próbáltam, de nem korrekt az eredményt: a több szálú mentés az új szerveren futott, SSH-n keresztül volt egy tunnel, úgy kapcsolódott a régi szerver MySQL-hez, és a mentés is az új szerverre készült, tehát a régi rendszeren a diszkről csak olvasás történt. Így kb 3-3.5p volt a mentés (szemben az új szerver 1.5 percével), ill a régi gépben csak 8 mag van, ott óvatosabban lehetne emelni a szálak számát.

( _Franko_ v | 2021. 03. 10., sze – 08:44 )

Ez teljesen használhatatlan metrika ilyenkor, mert itt csak azt nézed, hogy a CLI SQL kliens mennyit vár arra, hogy az SQL szerver elvégezze a melót (sokat):

real 17m2.267s
user 1m6.752s
sys 0m6.300s

Betöltés közben hogy alakulnak a gépen a metrikák? iowait? load? sys/user arány? CPU magok terhelése? I/O terhelés? IOPS?

Látatlanul és saccra azt mondom, hogy nem az I/O lesz a kevés, hanem a CPU, pláne azért, mert valahol vélhetően egy szálra korlátozódik a betöltés... egy mag szarrá terheli magát, a többi meg röhög rajta.

https://iotguru.cloud

( freeoli v | 2021. 03. 14., v – 23:23 )

A tarolomotor szerintem innodb, próbálj arra vonatkozóan némi optimalizaciot elvégezni percona doksi alapján. Buffersize, instance, stb

Nem, szinte minden érintett tábla MyISAM. Ezek jellemzően törzsadatok, negyedévente egyszer módosulnak, és a cél kb a "SELECT * FROM table WHERE id=x" leggyorsabb futtatása :).

A negyedéves karbantartáson kívül nincs semmi DML. A MyISAM optimalizálásokat átnéztem, így ment le 35 percről 27-re a betöltés.

( debtamas88 | 2021. 03. 15., h – 00:46 )

Szia!

Új gép BIOS-ba kapcsold ki ezeket: C-States, Spread-Spectrum,
ACPI beállításokat nézd át ( Power Management Options ) - mindehol tedd "Performance" -ra, tiltsd azokat ahol "Power saving" -van.

Ezek után a processzor teljesítménye FIX - lesz, nem fogja semmi tekergetni az órajelet/teljesítmény - máshol találkoztam ilyennel, ezek után megjavult a "szerver" :)

OS alatt ellenőrizd, hogy a max órajelen fut minden mag:
> cpufreq-utils csomag
$> cpufreq-info

Teszteld megint a különbséget.

HP Servernél van power profile ami lehet Dynamic Power Saving és tényleg le tudja fogni a CPU-t. Máshol nem tudom mennyire erősek ezek, de jellemzően nem kéne ekkora különbséget okoznia. A max órajel egy dolog, de egy modern CPU-n a turbót is le tudod tiltani a fentivel, illetve ha mindíg maxon megy akkor adsz a villanyszámlának egy pofont (tudom, tudom a cég fizeti, de a szünetmentest is méretezd ehhez). Tapasztalatom szerint ha a normál turbó vagy frequency scaling megy, akkor nagyon kicsi az overhead es hacsak nem valami nagyon lowlatency, nagyonszámolós megy, akkor nem érdemes pörgetni a CPU-t. Az sem árt, ha picit zöldebb a gondolkodás.

Attól mert fasza szervert használunk, még nem kell Pakson sikítófrászt kapniuk a fogyasztástól. Már minden normális gyártó eleve platinás tápot, de sok esetben titánium szintűt szállít, és jó esetben minimális felárért választható. Ez az odafigyelés része, a másik része, hogy jó eséllyel nagyon picit nyersz a fix órajellel, sőt, ha a turbót is kikapcsolja a szerver akkor vesztesz. Hacsak nem 24/7-ben HPC jelleggel használod, akkor pedig egy csomó zsetont fölösen fizettetsz ki a céggel.

Rendes SLA-ra és rendes adminra legyen zseton inkább, az a része a normális karbantartásnak.

Köszönöm a segítő szándékot, tényleg jól esik mindenkitől - de ezt kicsit túlzásnak érzem.

Ha az összehasonlításban szereplő értékeket optimalizációval lehetne közelíteni (tehát csökkenteni a futási időket - szignifikáns mértékben), az szerintem nagyon nagy baj lenne.

( debtamas88 | 2021. 03. 15., h – 23:02 )

Szerkesztve: 2021. 03. 15., h – 23:08

Debian 10-ben, a Mariadb csomagot melyik repo-ból raktad fel?

1., debian repo ( --> 10.3.27-0+deb10u1)
2., mariadb repo ( --> v10.5; https://downloads.mariadb.org/mariadb/repositories/ )

Gondolom "debian gyárit" ami sokkal régebbi, mint a legutolsó "hivatalos stable: v10.5".

Teszt gépen nézd meg a külöbséget a kettő között, szerintem ez lesz a megoldás - "hivatalos stable: v10.5" jobb lesz.

Köszi,

annyira azért nem dobta meg:
 

$ time mysql -h vm-mysql2 -p db < table.sql
Enter password:

real    7m10,433s
user    1m14,691s
sys    0m3,137s


$ time mysql -h vm-mysql1 -p db < table.sql
Enter password:

real    7m20,680s
user    1m15,508s
sys    0m3,178s

 

Az első a MariaDB-s repoóból származó 10.5, a második a "mezei" Debian. Mindkettő ugyanazokkal a beállításokkal. Az a 10mp kb a jelszó gépelésből adódó különbség... :)

Már production-ben van a DB vagy még mindig a betöltést optimalizálod?

Nem, még nincs production-ben, de már elengedtem a betöltést. Viszont kíváncsi voltam, hogy van-e releváns különbség a 10.3 és a 10.5 között. Erőforrás egyelőre van (CPU, memória, diszk...), így megengedtem ezt a luxust :).

Amit kérdezni akarok: tudod már, hogy élesben is rosszabb lett? Megéri még ezzel most molyolni?

Mármint mi lett rosszabb élesben? Maga az alkalmazás átlagos használata? Az még nem derült ki, várom a tesztelők visszajelzéseit.

Ha nem így értetted, akkor hogy?