[ dzigilibonglica @ 13.03.2025. 13:30 ] @
| Pozdrav, Verzije MySql-a koje se koriste su 5.5 i 5.6. Imam par nedoumica oko nekoliko parametara i Buffer-a, a koji mi nepotrebno zauzimaju Memoriju, i to je onako.... baš, baš glupo zauzeće memorije, tačnije memorija ne služi ničemu za 90% korisnika, a za 10% korisnika ona treba... Bufferi i podešavanja koje u 99% slučajeva zauzmu memoriju koja zvrlji prazna su: sort_buffer_size, join_buffer_size, tmp_table_size , i kao što se vidi to su sve Per Session/Connection varijable, koje zauzmu definisane MB za sve ove parametre za svakog konektovanog korisnika... bedak. Da stvar bude veći problem, od oko 300 korisnika jednog sistema, ne koriste svi isti softver, i samo pojedini korisnici koriste softvere koji rade JOIN i SORT BY nad velikim tabelama (razne analitike, pregledi magacina, trebovanja), dok aplikacije ostalih 90% korisnika nad MySQL-om rade jako proste Select, Insert , Update komande, bez da rade Join, Sort itd...(čekiranje barcodova u proizvodnji, telefonija,...znači jako prosti i straight forward SQL nad podacima). Pa sada pitanja: Q.1) Da li memorija koja se ovim parametrima zauzima spada u INNODB_Buffer_Pool ili je ona nezavisna i ide van innoDb_Buffer_Pool-a, tj jede dodatni RAM van innodb_buffer_pool? Q.2) Koliko je pametno smanjiti maksimalno ove parametre, a da za uzvrat podesim MySql Tmp folder na RAMDISK.... Ovo mi nekako deluje najlogičnije, da elaboriram: Umesto da bespotrebno zauzimam ogromne količine memorije za korisnike koji je NEĆE koristiti, smanjim te promenjive na neku razumnu veličinu, a kada i neki od retkih korisnika opale Query koji kreira Tmp_Table na disku, ili treba da uradi veliki sort posle Join i WHERE , pa naprave tmp_disk_table za njih će se zapravo kreirati tmp_table na RamDisk-u, tačnije u RAM-u, i to samo kada opale takav Query? Q.3) Koliko je pametno koristiti RAMDISK u Produkciji za MySQL TMP folder? Da li je neko imao problema sa tim? Q.4) Neka iskustva sa AMD Procesorima, posebno onima sa 3D Cache-om? Posle decenija korišćenja softvera u produkciji, razvoja i optimizacije, došlo se do toga da nema Query-ja koji ne koristi index-e, sve je bolesno optimizovano, i polako kako Index-i rastu, i količina podataka koja se ukršta, sve više zavisi od brzog CPU. Nekako je danas ponuda Consumer-skih serverskih mašina bazirana na Xeonima, koji su vremenom otišli u širinu horizontalno (broj jezgara i threadova) a što je za MySQL nepotrebno (bar za ono za šta ga ja koristim), dok clock kakska i prilično je bedan u poređenju sa AMD procesorima danas. Moram da nampomenem da Kod mene u produkciji sve baze staju komplet u RAM (a struktura veličine je 70% Indexi, 30% Data) i različiti Xeoni(generacije) u zavisnosti od CPU Clock-a i bryine RAM-a parave značajnu razliku. Mada, kao što sam rekao, Xeoni odoše u širinu, a ne u veći Clock, pa za iole veći clock na Xeonima treba prodavati bubreg, dok AMD nudi fantastične brzine po razumnim cenama... Kako su vam se pokazali AMD procesori sa MySQL-om u produkciji. Da li ovi procesori sa 3D Cache -om imaju neke prednosti u trčanju kroz RAM? Konkretno, rade li AMD procesori dobro sa MySql, u smislu da li instrukcije koje imaju rade stabilno na njima. Godinama sam oklevao i nisam se usuđivao da stavim AMD na produkciji... |