Re: [rlug] pwrite() slow

2013-04-14 Fir de Conversatie Vali Dragnuta
> - 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 v

Re: [rlug] setvcpus

2013-04-14 Fir de Conversatie Catalin Bucur
On 4/14/2013 11:50 AM, Nux! wrote: >> virsh setvcpus VM01 6 --config --maximum > > De fapt cred ca e nevoie si de > virsh setvcpus VM01 6 --current > > iti recomand virt-manager, te scapa de bataile astea de cap. Mda, m-am tot cramponat de mesajul ala de avertizare ca n-am voie sa mai modific vcp

Re: [rlug] pwrite() slow

2013-04-14 Fir de Conversatie Bogdan BOTEZ
Daca scriptul foloseste multe scrieri, este important sa fii sigur ca ai nevoie de toate. Cateodata chiar nu este nevoie. Si daca scrii, conteaza si cum grupezi scrierile (controlul tranzactional) - 10k tranzactii != 1 tranzactie cu 10k inregistrari. Marimea paginii la indecsi nu este panaceul pe c

Re: [rlug] pwrite() slow

2013-04-14 Fir de Conversatie petrescs
@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

Re: [rlug] pwrite() slow

2013-04-14 Fir de Conversatie Dan Borlovan
> M-am gandit si eu daca nu cumva mecanismele de sync (db vs fs) se calca > reciproc pe picioare, insa nu am gasit ceva recomandari inca (firebird are Nu se calca, dar fiecare din ele sacrifica din viteza ca sa garanteze consistenta datelor la nivelul respectiv > Timing buffered disk reads: 368

Re: [rlug] pwrite() slow

2013-04-14 Fir de Conversatie Bogdan BOTEZ
"Se stie" ca nu se foloseste ext4 pentru baze de date ... Exista bench-uri publice cu mai multe baze de date si mai multe fs-uri. Ca intotdeauna insa depinde mult si de tipicul tau de operare. Din familia extx, ext2 tin minte ca facea fata cel mai bine. Dupa ce necesarul de stocare creste, multi ju

Re: [rlug] pwrite() slow

2013-04-14 Fir de Conversatie Andrei Pascal
N-are de unde RAID5 că are doar 2 discuri. 2013/4/14 Mircea Mitu > On 14.04.2013, at 13:20, petrescs wrote: > > > Am preferat RAID soft pentru ca am considerat ca nu se justifica un > > controller hw dedicat ... Nedumerirea mea era daca in conditiile date > durata pwrite > > este justificata d

Re: [rlug] pwrite() slow

2013-04-14 Fir de Conversatie Mircea Mitu
On 14.04.2013, at 13:20, petrescs wrote: > Am preferat RAID soft pentru ca am considerat ca nu se justifica un > controller hw dedicat ... Nedumerirea mea era daca in conditiile date durata > pwrite > este justificata de ceva, mi s-a parut inadmisibil de mare. Daca e Raid5, scrierea db e lenta

Re: [rlug] pwrite() slow

2013-04-14 Fir de Conversatie petrescs
2013/4/14 Dan Borlovan > Fara sa citesc ce ai scris (sorry), doua chestii > > - hdd fara un controller raid in fata, cu baterie si cache wb sint > dureroase la asa ceva (scrieri random, gen update in db). Un update in db > inseamna sa treci totul prin transaction log. Dupa care sistemul de fisier

Re: [rlug] pwrite() slow

2013-04-14 Fir de Conversatie Dan Borlovan
Fara sa citesc ce ai scris (sorry), doua chestii - hdd fara un controller raid in fata, cu baterie si cache wb sint dureroase la asa ceva (scrieri random, gen update in db). Un update in db inseamna sa treci totul prin transaction log. Dupa care sistemul de fisiere mai face si el o trecere prin

[rlug] pwrite() slow

2013-04-14 Fir de Conversatie petrescs
Salut, Nu reusesc sa imi dau seama de un bottleneck I/O pe un server de baze de date. Am un script care face niste modificari intensive pe o db firebird de aprox. 5GB, insa din alte investigatii, inclin sa cred ca problema nu e la db/script/indecsi samd, ci mai degraba undeva in filesystem (ext4).

Re: [rlug] setvcpus

2013-04-14 Fir de Conversatie Nux!
On 14.04.2013 09:44, Nux! wrote: > On 14.04.2013 09:26, Catalin Bucur wrote: >> De editat o pot face, cred ca pot pune si 100 cu virsh edit :-) >> Am pus 6 si n-a marait nimic, dar maximul setat cand s-a creat >> guest-ul >> a fost 4, asa ca dupa ce booteaza imi arata tot 4 vcpus. > > virsh setvcp

Re: [rlug] setvcpus

2013-04-14 Fir de Conversatie Nux!
On 14.04.2013 09:26, Catalin Bucur wrote: > De editat o pot face, cred ca pot pune si 100 cu virsh edit :-) > Am pus 6 si n-a marait nimic, dar maximul setat cand s-a creat > guest-ul > a fost 4, asa ca dupa ce booteaza imi arata tot 4 vcpus. virsh setvcpus VM01 6 --config --maximum -- Sent fr

Re: [rlug] setvcpus

2013-04-14 Fir de Conversatie Catalin Bucur
On 4/13/2013 7:34 PM, Nux! wrote: > Da, se poate, dar trebuie oprita masina virtuala. Ori faci din > virt-manager or ad labam cu "virsh edit VM" parca si modifici acolo nr > de cpu-uri. De editat o pot face, cred ca pot pune si 100 cu virsh edit :-) Am pus 6 si n-a marait nimic, dar maximul setat