Hdd noslodzes mazināšana.

[Lynx]

Tatad ir diezgan liels projekts, kurš ēd daudz mysql datubāzes resursus un ir plāns samazināt datubāzes noslodzi.

Kā viens no lielākajiem ēdajiem, kas darbojas nepārtraukti tika noteikts SELECT, kas savāc informāciju no vismaz 7iem vienas tabulas datubāzes laukiem katru reizi pakustoties ielogojušamies lietotājam lapā.

Šo problēmu paris dienas atpakaļ es būtu atrisinājis vienkārši uz logošanos ierakstot visu informāciju sesijas mainīgajos un ar tiem arī tālāk darboties, un, ja nepieciesšams veikt izmaiņas. Tad izmainiit gan sesijas mainīgo, gan veikt updeitu datubāzē.

 

Bet studējot materialus internetā izdomāju interesantu ideju. Uz logošanos lietotaja dati no īstas tabulas tiktu parakstīti uz HEAP tabulu. No kuras arī tiktu visu laiku selektēti un pie reizes arī updeitoti dati. Teorētiski vajadzeetu strādāt daaaudz ātrāk, jo tiek lasīta informācija no rama un samazināta hdd lietošana.

Ja cilvēks izlogautojas tad visi dati no HEAP tabulas tiktu pārakstīti uz īsto tabulu un ieraksts no HEAP izdzēsts.

Takā lapai ik pa 5min backgroundā iet datubāzes updeiti, tad pie visiem pārejiem procesiem vajadzēs arī piesaistīt HEAP datu parakstīšanu uz īsto tabulu. Priekš tiem, kas neizlogautojas un vienkārši aizver browseri, vai arī, ja pēkšņi serveris nokaras lai ir tikai max 5min rollbacks.

 

Kuru variantu Jūs ieteiktu izmantot? Un varbūt ir vēl kādas svarīgas lietas, ko neesmu ņemis vēra meklējot labāko risinājumu?

[Klez]

diez vai tev tas paliidzeees pie daudz cilveekiem, linuxis meedz pietaisiit ramu ... vareetu mok gadiities atminjas truukums, vai arii mysql gaidiis kad atbriivojas atminja, bet ja viss pasaakums saak liist swap`aa, vai tam ira jeega?

ja selecti nau sarezhgiiti , tad labaak atstaaj selektus. pareizi saindeksee tabulas un domaaju ka buus okey :)

ko citi domaa ? :)

[Roze]

1. Izlaist visus SELECT kverijus caur EXPLAIN (tb EXPLAIN SELECT ....) paskatīties vai vai nekur neparādas 'filesort' un no tā tikt vaļā par visu cenu.

Vai visus gadijumos tiek izmantoti pareizie indexi uz WHERE nosacijuma laukiem (reizēm MySQL neprot izmantot indeksu pat ja tabulai konkrētajam laukam tas ir uzlikts) iebarot vinjam tos ar FORCE INDEX

 

2. skatīties vai nosacijumos nav OR 'id = 1 OR id = 2' izpildaas kudish ilgaak nekaa SELECT * .. WHERE id = 1 UNION SELECT * WHERE id = 2

 

3. ja tabulaam notiek selects ar lauks1=1 AND lauks2=2 tad taisīt apvienotu indeksu uz abiem laukiem..

 

4. Paskatīties vai MySQLam ir ieslēgts query cache (vai tas ir pietiekami liels / vai ir normāls hitrate).

 

5. Izdomāt kuru no db enginēm izmantot: MyISAM ja ir daudz SELECti, bet samērā maz konkurenti INSERTi/UPDEiti, InnoDB ja ir daudz konkurentu gan selectu gan insertu. Pretēji ķeska ar lockošanos.

 

6. Izmantot eksternālu keshingu piem Memcached.

 

 

diez vai tev tas paliidzeees pie daudz cilveekiem, linuxis meedz pietaisiit ramu ... vareetu mok gadiities atminjas truukums, vai arii mysql gaidiis kad atbriivojas atminja, bet ja viss pasaakums saak liist swap`aa, vai tam ira jeega?

Ko nozīmē "pie daudz cilvēkiem"? Linux pēc idejas praktiski vienmēr izmanto visu pieejamo atmiņu lai atvieglotu IO operācijas (proti failu keshings atmiņā), problēma reizēm rodas tajā ka kernelis vai konkrētais daemons sapinas meistarībā (balstoties uz sistēmas parametriem) un taupa vai tieši pretēji par daudz atmiņas izdala vienai vai otrai lietai.

Kas attiecas konkrēti uz MySQLu tad katrai konekcijai viņš izdala sort / key un hvz vēl kādus buferus ( formula apmēram šāda: MySQL memory = key_buffer + max_connections * (join_buffer + record_buffer + sort_buffer + thread_stack + tmp_table_size) ) līdz ar to jāizvērtē kā rīkoties..

Var mēģināt izmantot persistantas konekcijas un teorētiski rejūzot iepriekšējās konekcijas (lai katreiz nav jāizdala un jāatbrīvo atmiņa), taču no otras puses ja persistantas konekcijas sarodas pa daudz tas beidzas ar to ka atmiņa vairs nepietiek nekam..

 

 

Bet vispār ja tas ir liels projekts tad vajag skatīties uz vairākiem DB serveriem (Master/Slave vai vienkārši contenta dalīšanu) vai kādu cluster risinājumu, jo vienam serverim tomēr ir zināmas robežas.

Šeit arī divi vienkārši varianti..

Ja tabulas samērā mazas bet aktīvi lietotas tad der MySQL cluster.

Ja datu daudz un tie nav satilpināmi atmiņā, tad jādala saturs vai jāsadala loģika:

1) Uzliekam vienu Master serveri caur kuru iet tikai INSERT/UPDATE/DELETE un piemēram divus Slave serverus kuri datus sihronizē no Master un nodarbojas tikai ar SELECTiem..

2) Var dalīt arī pašu saturu, piemēram lietotāji ar pāra identifikatoriem glabājas uz viena servera, lietotāji ar nepāra uz otra.

[Lynx]

Hmm skaidrs, tad sanāk ka, ja šie visi punkti ir izdarīti tad nav pat jēgas likt atmiņā vai rakstīt kā sesijas mainīgos, lai dabūtu vēl kādu ātrdarbības uzlabojumu?

[Delfins]

A moš mysql vaina? es bi paskatītos kā tas Q izpildās citā DB.. piemēram Postgre...

 

Par to monstrīgo selektu ar mok šaubas.. kaut kas nav īsti labi (ja ir tikai viena tabula)

[Roze]

Hmm skaidrs, tad sanāk ka, ja šie visi punkti ir izdarīti tad nav pat jēgas likt atmiņā vai rakstīt kā sesijas mainīgos, lai dabūtu vēl kādu ātrdarbības uzlabojumu?

Taisni otrādi.. šie punkti bija domāti pirms grūšanas atmiņā u.c. izvirtībām pārbaudīt standarta lietas - proti pārbaudīt vai paši kveriji ir normāli, vai ir korekta DB servera konfigurācija.

 

Starp citu ja jums izmantojas sesijas standarta variantā (datu nesējs ir faili) tad nebūs starpība jo sesijas dati tiks tikuntā rakstīti un lasīti no diska (ja vienīgi kā sesijas save path nenorāda ramdisku).