@all: multumesc pentru sfaturi, chiar m-au ajutat sa ingustez aria cautarilor. Ce concluzii am tras pana acum (poate sunt utile si altora ca mine):
- nu sunt recomandate "journaled fs" pentru a tine pe ele baze de date. 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. - 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... Multumesc, Silviu _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
