> - 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. > Inca nu inteleg de ce doar ext4 e in principal vinovat; stiam ca > ext3/ext4/jfs/xfs folosesc toate jurnale, dar se pare ca jfs sau xfs sunt > totusi acceptabile (nu intru in discutia cu db pe raw partition). Motivul > pentru care (pana acum) nu am dorit sa renunt nici la DB forced writes nici > la FS journal/barriers a fost ca (speram eu) doua protectii pentru > consistenta/integritate nu strica, mai ales ca serverul se comporta > admirabil in productie (scriptul sql in cauza e foarte intensiv la > update-uri, pe cand in productie se fac multe select-uri si relativ putin > inserturi). I was wrong. --- Depinde de baza de date, insa nu ar trebui sa ai penalitate atit de mare doar de la foarte multe update-uri. DB-urile moderne oricum la update-uri nu trebuie sa se asigure decit ca au scris corect log-ul (care este suficient pentru ca in caz de crash baza sa ramina consistenta in caz de crash), nu si blocurile de date efective care pot fi trimise ulterior intr-o ordine mai bine aleasa. Ce-i drept nu am lucrat cu firebird, insa daca intr-adevar face sync pt fiecare operatie, va merge prost no matter what. > > - ref. fs block size == db page size: db-ul meu are deja indecsi pe 3 > nivele, la un page size de 8k; ideal ar fi sa fac page size de 16k insa nu > stiu cum se va comporta un fs cu astfel de block size. Pe de alta parte, > daca refac db page size sa fie egal cu 4k recomandat la fs, o sa imi > incetineasca performanta accesarii paginilor in db (indecsi pe mai multe > nivele, multe selecturi folosite in productie) > > - de curiozitate am rulat scriptul pe o copie a bazei de date, pe o masina > virtuala - un container openvz cu mult mai putine resurse ca serverul de > productie, hdd sata desktop, insa cu firebird forced writes dezactivat; > pana m-am intors sa vad in ce stare mai este terminase deja (in mai putin > de doua ore). Am sa refac testul cronometrat cu time si separat un alt test > cu forced writes ON insa ext4 cu nobarrier/writeback/noatime/commit marit > etc etc. > > Daca nu e cu banat, as schimba intrebarea din Subj in: "cum e mai bine? > sync la nivel de DB sau de FS?" Impreuna m-am lamurit clar ca nu > coabiteaza, nici macar institutional... --- Din pacate raspunsul la intrebarea ta ar depinde de DB. Insa indiferent de db NU as renunta la un fs jurnalizat.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. 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. _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
