2013/4/14 Vali Dragnuta <vali.dragn...@inode.ro> > > > - nu sunt recomandate "journaled fs" pentru a tine pe ele baze de date. > > --- Um, what ?Asta e o prostie, folosesc de multi ani de zile baze de > date si toate pe fs-uri jurnalizate (ext3,xfs, ext4...). Sincer chiar nu > cred ca e vreun issue acolo. >
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 ). > > Ce-i drept nu am > lucrat cu firebird, insa daca intr-adevar face sync pt fiecare operatie, > va merge prost no matter what. > > Manualul lor spune ca by default (setarea forced-writes=on sau writes=sync) deschide database cu O_SYNC. In plus, ext4 incepand cu 2.6.32 (exact kernelul meu) are ceva reduceri majore de performanta tocmai ca sa imbunatateasca securitatea datelor ( http://www.phoronix.com/scan.php?page=article&item=ext4_then_now&num=3, e un benchmark de postgres dar cred ca e pe-aproape si pentru alte DB). Nu as merge pana acolo incat sa incerc sa dezactivez bariere samd, insa e clar ca forced writes din Firebird + barierele si jurnalele din ext4 post-2.6.32 duc la o reducere majora a performantelor. "performance or security - pick one". Chestii ortogonale, asta e. > --- Din pacate raspunsul la intrebarea ta ar depinde de DB. Insa > indiferent de db NU as renunta la un fs jurnalizat. Peste tot vad sugestii despre "tune and benchmark based on your own workload", ceea ce inseamna ca nu exista "retete" sau best-practices aplicabile in orice situatie (vorbesc de cazul DB peste varii FS). Pe de alta parte, eu unul m-as increde in sync-ul facut de motorul DB, ar trebui sa nu il intereseze absolut deloc de FS pe care lucreaza; de altfel, firebird (probabil si alte DBMS) accepta fara probleme sa lucreze cu un nume de genul /dev/sda1 in loc de /cale/catre/database.fdb. Pe scurt, "kilometraju' variaza" la fiecare. > Mai degraba as > investiga de ce db-ul tau mai vrea in secolul asta sa scrie totul in mod > sincron (ma rog, intrebarea este chiar TOT ce scrie scrie sincron ? Ca > daca doar logul (sau echivalentul sau in dbul ala) este sincron, asta e > ok. > 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. > De asemenea, as sugera sa rescrii acel script sa face updateurile > intr-un mod mai eficient - sa updatezi mai multe inregistrari inainte sa > faci commit-. Daca faci commit dupa fiecare update pt fiecare > inregistrare (si ai si DB-ul lucrind in mod sincron) este de asteptat sa > mearga prost, chiar si pentru simplul fapt ca trebuie sa faci foarte des > apeluri de sistem sa scrii ceea ce tocmai ai modificat. > 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... Multumesc tuturor, probabil voi mai rula o vreme pe configuratia curenta pana cand se vor observa incetiniri majore pe productie, dupa care fac saltul la SSD. _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
