> Scuze, nu am vrut sa sune ca un postulat. Mai corect s-ar spune "nu > intotdeauna sunt recomandate JFS". M-am lamurit inclusiv in cazul meu, am > mers pe ext4 default (data=ordered, cu bariere, cu atime etc) ani de zile > si nu am avut probleme pe productie, pana cand am dat de problema asta cu > un "anumit" model de executie (foarte multe update-uri). Recomandarea > anti-journaled am citit-o in mai multe locuri (ex. > http://informix-myview.blogspot.ro/2010/07/new-journaled-filesystem-rant.html > ).
Bull. (pt linkul aluia). Sint multi oameni pe aici care ingrijesc DB-uri cu zeci/sute de update-uri pe secunda pentru seturi de date de sute sau mii de GB si cu datele puse pe fs-uri standard. Daca ai ajuns intr-un scenariu in care sa-ti pui problema sa renunti la jurnalul fs-ului pentru ca altfel nu merge bine, atunci ai o problema mult mai mare ori in db-ul inadecvat ori in felul cum e scrisa aplicatia din acel db. > Cum spuneam mai sus, din documentatia lor rezulta ca folosesc by default > O_SYNC pentru date si metadate. Deci da, se pare ca introduce penalitate de > performanta majora, pe de alta parte incearca sa rezolve D-ul ala din ACID > indiferent de FS-ul/RAW-ul de dedesubt. Poate sa fie sync si pentru date atita vreme cit scrie datele de modificat intii in log. Cum logul de obicei are o dimensiune fixa si cu toate blocurile relativ in acelasi loc pe disc, scrierile in log se pot face foarte repede si nu este necesar sa ajunga de indata si in datafile. Daca s-au scris in log, este de ajuns pt db sa revina la o stare consistenta pina la momentul in care s-a intimplat crashul. De-asta spun ca in general este cel putin curios de ce are nevoie de sync pe datafile. Posibil ca fb sa nu aiba de fapt log si atunci da, are sens acest sync everywhere. Insa atunci esti in situatia cu "db inadecvata" pentru ca tehnic doar logul ar trebui sa fie scris sincron,dar pentru ca nu-l ai... :) Raw device-urile folosite ca atare de catre DB au niste avantaje, dar care nu vin cel mai mult din faptul ca dispare jurnalizarea oferita de filesystem (ca asa s-ar fi recomandat sa tii datafiles pe sisteme fat16 sau fat32 mountate cu sync in loc sa le tii pe rawdevices) > Nu e scriptul meu, insa din ce vad in procedura aia se baleiaza multe linii > din db, se face pe fiecare update, fiecare update are vreo 3-4 triggere, > care triggere mai apeleaza si ele fiecare niste proceduri stocate samd > samd... Sugereaza vendorului :) BTW, ceva imi spune ca si daca pui SSD pentru datele alea tot nu vei putea folosi in mod eficient resursele hardware pe care le ai la dispozitie. _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
