stiu, top posting sucks, dar ti-ai raspuns singur la problema, raid 5. fa un raid 10 acolo si se rezolva cel putin problemele "hw"
Fa teste de random reads, writes sa vezi unde e bottleneckul, hdparm, dd sunt inutile Sent from mobile On Sep 13, 2012, at 13:51, [email protected] wrote: > Hello all, > > Am o problema cu un server, care de ceva timp a inceput sa "tuseasca". > > Este un server de baze de date, folosit pentru tot felul de rapoarte. > In anumite situatii creste nejustificat timpul de raspuns al unor > interogari. Dezvoltatorul aplicatiei mentioneaza ca: > - interogarile sunt optimizate > - da vina pe platforma hardware (IO, memorie si CPU server). > - cere viteza mare de citire mare de pe disc (storage device)! > > OS: Redhat 5.8 pe 64 biti > > Serverul este un HP DL380 G4 > - Procesor Dual Core Intel Xeon 3.2 GHz/800MHz - 2MB L2 > - 12GB RAM (PC2-3200 DDR2) + 12GB swap > > Are atasat prin fibra optica un storage HP Storageworks Modular Smart > Array 1000 (10 diskuri U320 SCSI, 15k rpm, 72.8GB, raid5) via unui > fiber channel card Qlogic QLA2340. Volumul rezultat este folosit > exclusiv de baza de date oracle (nu are nicio legatura cu discurile pe > care este instalat OS-ul) > > Specificatii QLA2340: > > Autonegotiation of Fibre Channel speed bit rate (1 Gbps or 2 Gbps) > Automatic topology detection > Concurrent support for SCSI and IP protocols > Simultaneous initiator and target mode support > Bus Interface: 64-bit, 133-MHz PCI-X > Fibre Channel Interfaces: 1 Multimode Optical > > http://www.ecrunch.com/listing/Qlogic_QLA2340_QLA_2340_2-Gbps_Fibre_Fiber_Channel_HBA_Card.html > > De aici, deduc eu, ca in cel mai nefavorabil caz, cand autonegocierea > se face la 1Gbps, cardul de FO ar limita viteza la 125MB/sec! Buuun ... > > Din monitorizarile facute de mine pe volumul din storage am cam asa: > > hdparm -tT /dev/mapper/MSARAID5-STORAGE: > > Timing cached reads (~2000MB/sec) > > Timing cached reads = This measurement is essentially an indication of > the throughput of the processor, cache, and memory of the system under > test. La mine, acest parametru se mentine constant cam tot timpul > (indiferent de ora la care fac monitorizarea), deci pare ca probleme > legate de CPU& memory usage nu sunt! > > Timing buffered disk reads (~35-40MB/sec up to 50-60MB/sec): > > This measurement is an indication of how fast the drive can sustain > sequential data reads under Linux, without any filesystem overhead. > > Aici dimineata pana in pranz am un throuput de 35-40MB/sec iar seara > acesta urca pe la 50-60MB/sec. > > Ce vreau sa va rog. Comparativ, cineva care are mai multa experienta > decat mine: > > 1. De la 35-60MB/sec cat citesc cu hdparm pana la 125MB (cat permite > placa de FO) mi se pare ca este totusi mult loc? De unde apare totusi > aceasta diferenta? E normal? > 2. Cum vi se par timpii (throuput-ul) lui hdparm pe buffered disk > reads? Valorile sale sunt normale? > 3. Limitarea vitezei de citire poate proveni de la discurile SCSI > (U320 SCSI, 15k rpm, 72.8GB)? Din cate stiu eu pe SCSI nu exista > altele mai rapide. > 4. Adaugand inca 4 discuri in plus la cele 10 deja existente, as putea > creste IO-ul? > 5. Daca ma iau dupa cum lucreaza RAID5, informatia distribuindu-se pe > mai multe discuri decat in trecut (14 in loc de 10 in matricea raid), > dupa adaugarea celor 4 discuri ar fi rezonabil sa sper la un castig de > 10-20% in ceea ce priveste I/O-ul si implicit outputul lui hdparm sau > nu? > 6. Ce alte discuri mai "pricopsite" as putea folosi? Daca as merge pe > un SAN de ssd-uri as avea ceva sanse sa ma apropii 125MB/sec respectiv > 250MB/sec atat cat poate controlerul de FO (daca negociaza la 1Gbps > sau 2Gbps)! Mentionez ca nu am nevoie de o capacitate de stocare care > sa depaseasca 1TB! > > Va multumesc. > Alx > > > ------------------------------------------------- > This message sent via VFEmail.net > http://www.vfemail.net > $14.95 ONETIME Lifetime accounts! 15GB disk! > Commercial and Bulk Mail Options! No bandwidth quotas! > > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
