lørdag, januar 23, 2021

Høj I/O CPU forbrug ved skrivning til disk

Daily Rush Debat Programmering Høj I/O CPU forbrug ved skrivning til disk

  • Forfatter
    Emne
  • #0

    atroxes
    Bruger
    1.180 indlæg
    Offline

    [Flyttet fra det gamle Open Source forum]

    Efter at have revet så godt som alle hår ud af hovedet på mig selv søger jeg lidt assistance hos jer eksperter.

    Jeg sidder med en Ubuntu 9.04 maskine hvor jeg har sat 6 diske sammen (4x750GB og 2x1000GB) i LVM og lagt en gang LUKS ovenpå, for at kryptere skidtet.

    Kort fortalt, prøver jeg at skrive til mit LVM så går I/O wait helt i vejret. Hele LVM disken hænger og iflg. iostat ser jeg følgende:

    Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
    sda 0,00 0,00 0,00 0 0
    sdb 2,50 0,00 2232,00 0 4464
    sdc 0,00 0,00 0,00 0 0
    sdd 0,00 0,00 0,00 0 0
    sde 0,00 0,00 0,00 0 0
    sdf 0,00 0,00 0,00 0 0

    2232 blocks/sec er meget lavt, og samtidigt hænger hele LVM. Jeg troede selvfølgelig at det bare var en dårlig disk, men for det første kan jeg sagtens læse med fuld hastighed fra alle diske i LVM’et og for det andet så går problemet igen på alle disk og ikke kun /dev/sdb.

    Problemet har ikke altid været på maskinen, er først inden for de sidste 3 mdr. at den er begyndt at skabe sig.

    Lidt mere information følger:

    # uname -a
    Linux atrox-lager 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux

    # lspci

    00:00.0 Host bridge: Intel Corporation 82G35 Express DRAM Controller (rev 03)
    00:02.0 VGA compatible controller: Intel Corporation 82G35 Express Integrated Graphics Controller (rev 03)
    00:02.1 Display controller: Intel Corporation 82G35 Express Integrated Graphics Controller (rev 03)
    00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02)
    00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02)
    00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 02)
    00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02)
    00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02)
    00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 02)
    00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 02)
    00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02)
    00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02)
    00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02)
    00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02)
    00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
    00:1f.0 ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface Controller (rev 02)
    00:1f.2 IDE interface: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4 port SATA IDE Controller (rev 02)
    00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
    00:1f.5 IDE interface: Intel Corporation 82801I (ICH9 Family) 2 port SATA IDE Controller (rev 02)
    01:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit Ethernet Adapter (rev b0)
    02:00.0 IDE interface: JMicron Technologies, Inc. JMB368 IDE controller

    System information:
    CPU: Core 2 Duo E4600
    RAM: 2GB PC2-800 (er testet igennem)
    Bundkort: ASUS P5E-VM HDMI

    Jeg håber inderligt at nogen har nogen pointers, for Google har ikke kunnet hjælpe indtil videre

    1BEmqVdQSy71XjHXxHHbZnLUH43jm4toT4 - Støt Atroxes med Bitcoins!

Viser 7 kommentarer - 1 til 7 (af 7 i alt)
  • Forfatter
    Kommentarer
  • #1

    atroxes
    Bruger
    1.180 indlæg
    Offline

    Ingen der kan give en hånd?

    Jeg skiftede motherboardet i maskinen, samme resultat. Den nye SATA controller de nu sidder på er ICH10R.

    1BEmqVdQSy71XjHXxHHbZnLUH43jm4toT4 - Støt Atroxes med Bitcoins!

    #2

    Holger-IST-
    Bruger
    6.970 indlæg
    Offline

    hm… måske du skulle spørge på et dedikeret Ubuntu forum

    - Holger "A woman drove me to drink and I didn't even have the decency to thank her." - W. C. Fields

    #3

    Sterrior
    Bruger
    13 indlæg
    Offline

    Har du defineret det som raid i BIOS eller i ubuntu selv? Og hvilken slags raid?

    Hvis du gør det i BIOS vil den bruge den interne raidcontroller til at ordne paritets-bits (ihvertfald for striped raid) og det er den ikke forfærdelig hurtig til. Så er det bedre at lade Ubuntu definere raid og så bruge software raid. Så udnytter du din CPU når der skal laves paritetsbits.

    Med de diske du har dig der ville jeg anbefale et raid 5 synes jeg. Så er alle diskene samlet til én disk og du får både højere ydelse og redundans.

    Det kan selvfølgelig også være at det er krypteringen som optager CPU’en fuldstændig og derfor går det langsomt med at skrive. Eller også har du allerede software raid og så skal den både lave kryptering og paritet.

    #4

    atroxes
    Bruger
    1.180 indlæg
    Offline

    #2 Jeg spørger her fordi DR som regel owner alle andre fora

    #3

    Diskene har jeg prøvet at sætte som IDE/RAID/AHCI. Lige lidt hjalp det. Det drejer sig om samtlige diske på ICH10R controlleren. Har 1 ny 1.5TB Seagate disk på en ekstra Sil3114ctu controller som jeg har erhvervet mig for nylig, og den lader til at køre som den skal.

    Hvad angår kryptering, så har jeg fjernet 1 750GB WDC disk (sidder på ich10r controlleren) og kørt en ‘badblocks -nsv /dev/sdx’ på den, hvilket iflg. iostat giver samme resultat som da den sad i LVM+LUKS setup’et. CPU’en arbejder ikke, den banker bare afsted med iowait’s, 50-100% hele tiden.

    Prøver jeg f.eks. at “starte forfra” med disken og lave en partition og så smide mkfs.ext3 på den, så stall’er den når den begynder at lave inodes. Kommer hurtigt til ca. 140 ud af 5590, og så bevæger den sig ellers med sneglefart opad. Et normalt system banker en 750GB disk igennem på ingen tid, 1-2 min. maks.

    Jeg har på fornemmelsen at det er ICH10R controlleren den er gal med (ICH9R på det gamle bundkort) men jeg kan ikke se hvordan de hos Ubuntu kan overse noget så almindeligt som langsom write på intels ICH controllere til ganske standard WDC diske.

    1BEmqVdQSy71XjHXxHHbZnLUH43jm4toT4 - Støt Atroxes med Bitcoins!

    #5

    Wayfarer
    Bruger
    5.714 indlæg
    Offline

    #4 Jeg er ikke er ikke raid erfaren, men på et tidspunkt havde WD problemer med Spindown på linux systemer (ved deres greenline anyway, ved ikke lige hvilken line du har), mente dog det var blevet fixed.. men du kan da prøve og deaktivere spindown anyway (et forsøg hver)

    I believe our future depends powerfully on how well we understand this cosmos in which we float like a mote of dust in the morning sky. -Carl Sagan

    #6

    atroxes
    Bruger
    1.180 indlæg
    Offline

    #5

    Prøver lige pt. med en gang:

    /dev/sdX {
    dma = on
    write_cache = on
    spindown_time = 0
    }

    på alle diskene. Det fjerner jo spindown tiden, og at sætte DMA og Write Cache igen kan ikke skade, kan jo være skidtet bliver disabled. Opdatere med mere info.

    Iøvrigt så ser hdparm -Tt sådan her ud for alle diskene (svinger 5-10MB/s fra disk til disk):

    /dev/sda:
    Timing cached reads: 2286 MB in 2.00 seconds = 1142.70 MB/sec
    Timing buffered disk reads: 282 MB in 3.00 seconds = 93.97 MB/sec

    NÅH: Problemet er ikke løst desværre.

    1BEmqVdQSy71XjHXxHHbZnLUH43jm4toT4 - Støt Atroxes med Bitcoins!

    #7

    atroxes
    Bruger
    1.180 indlæg
    Offline

    Btw, I/O Schedulers har heller ingen effekt. Har prøvet med cfq, noop og deadline uden udsving, hverken til det værre eller det bedre.

    Desuden siger smartctl -H også:
    SMART overall-health self-assessment test result: PASSED

    på samtlige drev. Altså er drevene heller ikke ved at fejle.

    1BEmqVdQSy71XjHXxHHbZnLUH43jm4toT4 - Støt Atroxes med Bitcoins!

Viser 7 kommentarer - 1 til 7 (af 7 i alt)
  • Du skal være logget ind for at kommentere på dette indlæg.