Dotaz: sw vs hw raid

[cx0]

Zdravím vás,

prosím o radu.

Na serveru máme 2x500GB 3G disky .. a při velkém zapisování a prácí se soubory (zkrátka IO) jde absolutně do háje a vždy se přetíží, je tam sw raid.

Prosím, potvrďte mi, že s HH raidem 256MB to bude úplně jiná liga.. nerad bych to koupil a zjistil že to je minimální rozdíl.

Díky zkušení :)

Odpovědi

[Michal Kubeček]

Pokud tam nemáte extrémně slabý procesor, neměl by SW RAID 0 nebo 1 být úzkým hrdlem, takže se obávám, že problém bude spíš v něčem jiném. Váš popis problému je ale natolik vágní, že těžko nějak spekulovat.

[cx0]

díky. Ještě poprosím tedy zhodnotit druhou variantu a to..

Nyní tam jsou tedy disky 2x 500GB SAS 3G 7,2k ot 3,5"

bylo by "efektivnější" zaměnit na

SAS 15k HP 600GB 6G SAS 15K rpm LFF (3.5-inch) Dual Port Enterprise

Díky.

Co se týče procesoru, název z hlavy nepovím ale jedná se o jeden z TOP procesorů dnes a ram je 16GB.

[Michal Kubeček]

Jak už jsem napsal: bez aspoň trochu použitelného popisu, co se vlastně děje, nemá smysl planě spekulovat. (Ne, "jde absolutně do háje a vždy se přetíží" není použitelný popis.)

[cx0]

ok příklad. zálohují se databáze (mysqldump), jsou třeba velké 3gb a v tu chvíli je IO na max., load vzroste na 50, v iotop je vidět vytížení 100% md1_ (sw raid). Nebo když se mažou miliony txt souborů hromadně, tak opět se server přetíží, apache, mysql se samozřejmě ucpou, problém stejný.

procesor aktuálně nový xeon 3,2ghz.

snad to takhle stačí. díky.

[Michal Kubeček]

Hodnota load average sama o sobě moc velkou vypovídací hodnotu nemá, spíš by bylo zajímavé, co ukazuje top, jednak ve stavech procesoru(-ů), jednak jestli u nějakého procesu nebo kernel threadu neukazuje moc velká čísla. Případně jestli procesor není vytížen něčím jiným, co by pak brzdilo softwarovou implementaci RAIDu.

[Michal Kubeček]

Také by bylo dobré vědět, jaká je tam verze jádra (distribuce), protože implementace writebacku prošla postupem času několika zásadními změnami.

[cx0]

Takže,

Kernel and CPU Linux 2.6.26-2-amd64 on x86_64 Processor information Intel(R) Xeon(R) CPU E31230 @ 3.20GHz, 8 cores

při spuštění skriptu co maže tisíce záznamů (to je ten méně náročnější, např. zabalování 10gb souboru je podstatně horší, ale i tohleto už laguje apache)

iotop: 100% io příkaz find a rm (hledá v adresáři staré soubory a maže xxx tisíc v tomto případě textových souborů)

občas ten find zmizne a místo toho tam je kjournald na 50% a na 50% cca md1_raid

top:

top - 21:01:14 up 17 days, 6:53, 2 users, load average: 6.17, 3.59, 2.01 Tasks: 180 total, 1 running, 178 sleeping, 0 stopped, 1 zombie Cpu(s): 2.7%us, 1.2%sy, 0.0%ni, 81.8%id, 13.9%wa, 0.3%hi, 0.0%si, 0.0%st Mem: 16436872k total, 15837436k used, 599436k free, 2096092k buffers Swap: 7811064k total, 764k used, 7810300k free, 8350092k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20980 mysql 20 0 4421m 2.3g 5860 S 16 14.4 1322:31 mysqld 7393 www-data 20 0 259m 15m 7480 S 2 0.1 0:00.16 apache2 877 www-data 20 0 260m 37m 28m S 1 0.2 0:15.14 apache2

[cx0]

a debian 5

[Michal Kubeček]

Nejsem zrovna specialista na tuhle problematiku, ale podle těch čísel to nevypadá, že by to brzdil SW RAID. Sice vám to ukazuje jen 13.9%wa, ale jestli tam máte osmijádro, může to klidně znamenat 100% na jednom procesoru a úzké hrdlo právě tam (schválně v topu zkuste klávesou jedničkou přepnout na režim, kdy se stavy ukazují pro každý procesor zvlášť). Co by snad mohlo pomoci, by byla změna I/O scheduleru (případně poladění parametrů) a/nebo přechod na novější jádro.

[cx0]

Na druhém serveru od jiné firmy máme HW raid a kapku výkonnější disky oproti tomuto "problémovému", pomalejší CPU o trochu a server je 3x více zatížen a veškeré promazávání a archivování objemných souborů zvládá při sebevětším náporu absolutně bez problému.

Systém, verze, i kernel jsou na obou totožné, sw výbava je také stejná, config taktéž tam kde to jde.

Oba servery jsou plně aktualizované.

Tedy mi z toho plyne, že musí být problém, že chybí HW raid nebo rychlejší disky.

Nebo i přesto může být problém v jádru a konfiguraci?

Díky za trpělivost..

[Michal Kubeček]

Můj odhad prostě je, že tento typ problémů se přechodem na HW RAID nevyřeší (ale můžu se samozřejmě mýlit).

[cx0]

Přikládám screenshot: http://2i.cz/68605872a1

Ještě jednou děkuju..

[jaroleto]

A stejny obrazek pro druhy server? Tady to vypada, ze nejaky typ io obstarava pouze 0. cpu

[cx0]

Screen druhého (balení 2gb souboru), balí a ostatní stíhá bez omezení.

http://www.2i.cz/548eb69c4f

Díky za rady!

[martin-ux]

ako ti uz bolo spominane, load average je klamlivy (hlavne pri viac cpu), resp. samotne cislo ti moc nepovie.

zaujimave by bolo vidiet output z iostat za 30s ked je busy (iostat -dc 5 6), vmstat tiez pomoze.

z obrazkov co si poslal to vyzera skor, ze ten server sa nudi.

tento problem s performance sa ti objavil len teraz (a server pouzivas uz dlhsie) alebo je poskladany teraz? ako su zapojene disky v raide (radic bottleneck napriklad).

tiez uz spominali - aj odchadzajuci disk dokaze narobit problemy, nie vzdy to smart zachyti. jedna z moznosti by bola vytiahnut jeden disk, spravit testy, sync, vytiahnut druhy disk, spravit testy, sync a porovnat vysledky.

[cx0]

tento problém je od počátku serveru, doted to bylo tolerováno.

jasně, load se brat nedá, ale běžně je pod 2, při find a balení souborů vyskáče na 120 třeba a i příkaz uptime v konzoli potom trvá dokud nekillnu to balení.

screen: http://2i.cz/40363e14c7

díky.

[Michal Kubeček]

z obrazkov co si poslal to vyzera skor, ze ten server sa nudi.

To bych neřekl. Problém je, že je tam úzké hrdlo v podobě jednoho procesoru, na který se koncentruje veškerá I/O zátěž.

[cx0]

a dá se to prosím někde v configu upravit?

díky za trpělivost

[Michal Kubeček]

Tak jednoduché to bohužel není. Podstatné je zjistit, proč to tak je. Jak vypadá ten /proc/interrupts?

[cx0]

úplně dolů jsem to postnul

[martin-ux]

bolo to myslene v duchu, ze ten server by mohol byt kludne zatazeny viac a nic by sa mu nestalo (customer si neplati za idle servery :) )

ale pravda je, ze na IO bottleneck tam naraza. tie vmstat/iostat by bolo fajn pozriet. autor problemu moc svoj server neopisal, takze nevieme ani ako/na com ma tie disky fyzicky zapojene.

[cx0]

pravda pravda.

IOSTAT http://2i.cz/40363e14c7

interrupts níže, díky.

[martin-ux]

z toho obrazka to vyzera, ze si zapisoval len ~21MB/s na tie disky - pravda ? iostat -k ti zobrazi r/w v kB, nie v 512k blokoch.

ako su tie disky fyzicke zapojene ? tie disky maju 512 alebo 4k sector size? to tiez moze sposobit problemy. co za FS je na nich? bol nejak specialne naformatovany/mountnuty ?

[cx0]

mohlo by to souhlasit, podle toho jak jsem reloadoval velikost souboru.

Fyzické zapojení netuším, počáteční instalace a zapojení měl na starosti dodavatel/serverovna.

Sector count = 256

Disk je to: http://www.globalonetechnology.com/HP_500GB_3G_SATA_7_2K_3_5_MDL_Hard_Drive_p/mb0500eamzd_new.htm

Filesystem status Used in LVM VG group

Cylinders: 60801 | Partition format: MSDOS

Snad to pomůže, díky

[martin-ux]

ok, takze najskor je to nejaky proliant.

v tom serveri nemas hp smart array ? ak ma ten server warranty/kontrakt tam by som to riesiel cez HW raid urcite.

ake fw maju tie disky ? podla webu tu bol fix v poslednej verzii:

Corrects a drive hang that causes long command response times and drive resets

[cx0]

ano přesně tak.

nemá nemá.. pokud by to mělo být tím raidem, tak ten 256MB raid do toho půjde.

Firmware Version: HPG3

No presets are defined for this drive. Its identity strings: MODEL: /dev/sda FIRMWARE: (any)

Takže aktualizovat FW, případně pak RAID, chápu to správně? Díky.

[homunkulus]

Zkusil bych vymenit oba SATA kabely za nove (nedelam si legraci) a zastrcit jeden do jineho SATA konektoru na zakladni desce.

[martin-ux]

no HPG3 je posledny fw podla webu, takze tam by som /uz/ problem nehladal.

na kontrakt som sa pytal preto, lebo pri chybe kontrolera potrebujes ten isty, aby si mohol opat precitat data; ak TTR (time to repair) nie je casovo rozumne (v zavislosti na co sa ten server vyuziva), mozno by bolo dobre mat po ruke aspon jeden nahradny kontroler (ak nie je onboard).

tak isto zo sw raidu na hw raid neprejdes bez straty dat, tj budes musiet robit full restore.

este by som skusil checknut sata kable (ako ti uz bolo spomenute kolegom dole), pripadne kontroller.

z linuxu mozes ovladat kontroller pomocou hpacucli commandu.

[cx0]

Ještě co jsem našel:

Allocation block size 4 MB Usable size 488191168 blocks (465.58 GB) Persistent superblock? Yes

Speed test results Buffer cache: 9802.65 MB/sec Buffered: 56.08 MB/sec

[HrabalVojta]

na to cpu "cat /proc/cpuinfo"

[Jan Kratochvíl]

Už to tu někde bylo, ale nemůže to být tím, že odchází některý disk (elektronika...) a tohle to způsobuje? Při zátěži začne systém extrémě lagovat? Zkuste tady prohledat fórum, už si nepamatuju, jak to šlo diagnostikovat...

[Sten]

Když je to SW RAID, tak to bude v dmesg (resetování SATA řadiče ap.) nebo ve SMARTu, odkud to jde přečíst pomocí smartctl.

[cx0]

nene disky jsou nové, smartd tam běží a je to ok..

[tark]

ta diskuze byla tady - http://www.abclinuxu.cz/poradna/linux/show/344475 ... zkuste se pomocí atop podívat na vytížení disků, jestli jeden bude mít třeba 30% a druhý 100%, tak je to jasné..

[cx0]

disky mají stejné vytížení, +-3% si jsou stejné. při archivaci měly oba 99% (to je to o čem píši vlastně, že prací se soubory se to celé přetíží..)

[ewew]

Možno to s týmto nesuvisí. Kontrolovali ste rozloženie irq, ktoré reportuje bios pri štarte systému. Použitie kernel parametrov. Daná dokumentácia by mala byť dostupná v balíku linux-doc-x.x.xx .

Ďalšia vec je, že default má filesystém v parametroch pripojenia zapnuté parametre atime,diratime. Atime je aktualizácia prístupu k súboru a diratime pre priečinky. Podorobnosti v man mount .

[cx0]

upravovalo se nedávno to na noatime a nijak to nezlepšilo výkon.

[Marv-CZ]

Nemáš možnost tam připojit stejný (nebo alespoň podobný) disk single na stejný řadič a pustit ty úlohy na něj. Pokud by to jelo dobře, tak je problém v SW RAIDu, pokud stejně blbě, tak v něčem jiné (třeba ovladač řadiče?).

[Jan Kratochvíl]

Souhlas, vyndat jeden disk z RAIDu, udělat z něj normální neRAID, překopírovat, nabootovat a otestovat, pokud to dělat nebude, můžeš investovat do HW raidu a možná to bude lepší, pokud to nepomůže tak už víš, že problém je úplně jinde....

[Marv-CZ]

Nevím, jestli bych zrovna riskoval odebrání jednoho disku s živými daty, nehledě na časovou náročnost zpětné synchronizace pole. Spíš vzít jiný kus odjinud.

[ewew]

Ako vyzerá súbor /proc/interrupts ?

[cx0]

           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       
  0:  706201115          0          0          0          0          0          0          0   IO-APIC-edge      timer
  1:          6          0          0          0          0          0          0          0   IO-APIC-edge      i8042
  8:          1          0          0          0          0          0          0          0   IO-APIC-edge      rtc0
  9:          0          0          0          0          0          0          0          0   IO-APIC-fasteoi   acpi
 12:          3          0          0          0          0          0          0          0   IO-APIC-edge      i8042
 16:         31          0          0          0          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb3
 20:         28          0          0          0          0          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb2
 21:         28          0          0          0          0          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb1
1263:  206921644          0     899250          0          0          0          0          0   PCI-MSI-edge      ahci
1270:          2          0          0          0          0          0          0          0   PCI-MSI-edge      eth0
1271: 1733131974          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-tx0
1272:  325211149          0          0          0          0    1663435          0          0   PCI-MSI-edge      eth0-rx0
NMI:          0          0          0          0          0          0          0          0   Non-maskable interrupts
LOC:   78084302  176030291  110686569   74109699  199332082   79642243   71610596   63312423   Local timer interrupts
RES:   30875760   33763225   23945114   17008641   59195261   28889151   29398115   27014669   Rescheduling interrupts
CAL:       5774       6020       6033       6032       6009       5988       5999        418   function call interrupts
TLB:    1830414    1339546    1219889     997277    2905000     917547     820990     668101   TLB shootdowns
TRM:          0          0          0          0          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0          0          0          0          0   Threshold APIC interrupts
SPU:          0          0          0          0          0          0          0          0   Spurious interrupts
ERR:          0