Quoting petrescs <petrescs+r...@gmail.com>: > 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.
... sau poate treci la ZFSonLINUX(si cu SSD), si uiti de DB dump/restore ! > _______________________________________________ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ================================ ATENTIONARI ============================= - pentru atasamente tip Office va rugam sa folositi format OFFICE 97; - nu trimiteti date personale (CNP, copii dupa acte de identitate etc). O lista completa cu reguli de utilizare exista la: http://gw.casbv.ro/forum_smf/index.php?topic=2000.msg3106#msg3106 C.A.S.J. Brasov - B-dul Mihail Kogalniceanu, nr. 11,Brasov [web-site]: http://www.casbv.ro [forum]: http://gw.casbv.ro/forum_smf/index.php ========================================================================== _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
