Изпечатай

[senser]

Здравейте,

Проблемът предполагам е познат за част от вас, но все пак ще поясня:
Системата е 64 битово Gentoo, с последните версии на всичко. Кернела, който ползвам е 2.6.34-zen1, но това надали има голямо значение, тъй като съм пробвал с какви ли не кернели от 2.6.30 насам (приблизително) и няма разлика. При четене или писане на диска натоварването на системата скача драстично, а скоростта на четене/писане измерена с iotop в пиковите си моменти е не повече от 2,5-3МБ/с, но иначе нормално се движи под 1МБ/с.

Код:

Total DISK READ: 9.74 K/s | Total DISK WRITE: 0.00 B/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO> COMMAND                                                       
19116 be/4 senser      3.90 K/s    0.00 B/s  0.00 %  0.91 % python2.6 /usr/bin/iotop -Po -d 4
 7520 be/4 senser    997.33 B/s    0.00 B/s  0.00 %  0.03 % firefox --sm-config-prefix /fire~012899100000311450025 --screen 0
 9395 be/4 mysql       4.87 K/s    0.00 B/s  0.04 %  0.00 % mysqld --defaults-file=/etc/mysq~cket=/var/run/mysqld/mysqld.sock

Проблемът не е във файловата система - почти няма разлика при различните. Хардът също е ОК и производителността му измерена с hdparm е нормална:

Код:

hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   950 MB in  2.00 seconds = 474.45 MB/sec
 Timing buffered disk reads:   88 MB in  3.03 seconds =  29.03 MB/sec

Проблемът се дискутираше във форума на gentoo, но нещо замря: http://forums.gentoo.org/viewtopic-t-482731-postdays-0-postorder-asc-start-925.html. Там имаше различни предположения, но повечето витаеха около това, че 64 битовите системи са засегнати значително повече от 32 битовите и, че е "замесен" disk scheduler-a. Пробвал съм и с трите различнi scheduler-a и няма промяна, поне не и осезаема.

Ползвам компютъра за ежедневна работа, и предполагам, че го натоварвам малко повече от средностатистически потребител, защото освен браузър, офис, музика и т.н. имам пуснати апач и mysql, но въпреки това не мисля, че е нормално натоварването на системата да е постоянно около 1-ца, а програмите да се стартират понякога за минути.

Това, което ми направи впечатление вчера е io статистиката на произволен процес, която изглежда така:

Код:

# less /proc/1/io

rchar: 157786078883
wchar: 65325745653
syscr: 906017819
syscw: 168525258
read_bytes: 47304096768
write_bytes: 17572843520
cancelled_write_bytes: 2679222272

и по-точно последния брояч cancelled_write_bytes. За него намерих следното тук http://www.kernel.org/doc/Documentation/filesystems/proc.txt:

cancelled_write_bytes
---------------------

The big inaccuracy here is truncate. If a process writes 1MB to a file and
then deletes the file, it will in fact perform no writeout. But it will have
been accounted as having caused 1MB of write.
In other words: The number of bytes which this process caused to not happen,
by truncating pagecache. A task can cause "negative" IO too. If this task
truncates some dirty pagecache, some IO which another task has been accounted
for (in its write_bytes) will not be happening. We _could_ just subtract that
from the truncating task's write_bytes, but there is information loss in doing

Дали относително високия процент cancelled_write_bytes (), може да има връзка с високия load при входно изходни операции или дайте други идеи, ако имате.

П.П. Сега се сетих за един елементарен тест, който пробвах:

Код:

dd if=/dev/zero of=/mnt/test bs=512k count=1024
1024+0 records in
1024+0 records out
536870912 bytes (537 MB) copied, 29.1484 s, 18.4 MB/s

Относително бързо писане, но през това време компютъра е неизползваем - дори и мишката трудно се движи, а лоуда е към 10.
Прави ми впечатление, че май когато един процес прави дисковата операция (четене или писане) скоростта е добра, но когато няколко конкурентни процеса се борят за достъп, скорстта пада драстично ..... ако може да се вярва на iotop де.

[shadowx]

DMA върви ли ?

[senser]

DMA върви ли ?

Код:

hdparm -i /dev/sda

/dev/sda:

 Model=SAMSUNG MP0804H, FwRev=UE100-14, SerialNo=S042J10Y814823
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5
 AdvancedPM=yes: unknown setting WriteCache=enabled
 Drive conforms to: ATA/ATAPI-7 T13 1532D revision 0:  ATA/ATAPI-1,2,3,4,5,6,7

[Naka]

Хардът също е ОК и производителността му измерена с hdparm е нормална:

Не изглежда да е добре. Трябва да дава много повече от  29.03 MB/sec.
това е UDMA 100 хард. а е включен на *udma2. udma2 ограничава на около 30мб/сек (овен ако наистина не е бавен хард)

UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5

Виж къде е звездичката. А трябва да е на *udma4 или *udma5

Ти с какъв ide кабел си? с 40 или 80 жилен (ATA66). Защото ако с обикновен точно това ще се получава. Какво е дъното и какъв е чипсета. Виж си също и биоса да не би отам да е ограничено.

[senser]

Хардът също е ОК и производителността му измерена с hdparm е нормална:

Не изглежда да е добре. Трябва да дава много повече от  29.03 MB/sec.
това е UDMA 100 хард. а е включен на *udma2. udma2 ограничава на около 30мб/сек (овен ако наистина не е бавен хард)

UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5

Виж къде е звездичката. А трябва да е на *udma4 или *udma5

Ти с какъв ide кабел си? с 40 или 80 жилен (ATA66). Защото ако с обикновен точно това ще се получава. Какво е дъното и какъв е чипсета. Виж си също и биоса да не би отам да е ограничено.

По-принцип си прав и още при буутване кернела си казва, че кабела е 40 жилен:

Код:

ata1.00: limited to UDMA/33 due to 40-wire cable

само че машината е лаптоп и няма начин да сменя "кабела", защото такъв няма.
Чипсета е SiS, лаптопа е FSC.
Но въпреки това продължавам да твърдя, че не е там проблема - все пак скорост измерена с hdparm от 30МБ/с (дори и да не е максимално възможната за диска) е достааааа далече от скорост от 1МБ/с в процес на нормална работа. Отделно каквото и четене и писане да правиш по диска не е нормално да ти спира часовника, мишката и компа да е замръзнал.
Не помня да съм пускал скоро уиндоус за да кажа там как е, но съм на 99%, че проблемът ще отстъства - поне последните пъти, когато съм пускал вин си беше ОК.

[gat3way]

Ми нормално да е доста далече. hdparm теста е sequential четене от блоковото устройство и въобще не се минава през vfs слоя, това обикновено няма нищо общо с реалния workload. В реалността, четенето от диска въобще не е последователно, причините са много - четеш различни файлове, които са разположени на различни места по диска, дори да четеш един голям файл, нямаш гаранция че е разположен на последователни блокове - фрагментацията си съществува и при ext3 файлови системи противно на това което повечето хора си мислят. При всяко четене на файл, променяш atime на файла, това се отразява на журнала, който в един момент трябва да се commit-не. Всъщност, най-бавното нещо при харддисковете е времето за което главата прескача на друга пътечка, колкото по-*далеч* е тя, толкова по-бавно става. Операционните системи се стараят да го минимизират, използвайки въпросните I/O scheduler-и, като обикновено идеята е дисковите операции да не се изпълняват веднага, а да влизат в една структура и да се изпълняват в друга последователност така че seek time-a да се минимизира. И в общият случай затова I/O scheduler-ите се наричат "elevator"-и, защото това което правят е че постоянно сноват по диска от първата до последната пътечка и обратно и подреждат I/O заявките така че да следват тия разходки нагоре-надолу. Разликите между anticipatory, deadline и etc политиките са главно по начина по който новите заявки се обработват - възможно е примерно "разходката" нагоре-надолу да бъде нарочно забавена ако се *очаква* да пристигне нова I/O заявка, която да изчете нещо от следващата пътечка, с цел да не чака докато "разходката" стигне до последната пътечка и после се върне до тази. Такива работи.

Ако примерно I/O scheduler-а е _счупен_ поради някаква причина в това ядро, както твърдят онези в онзи форум, тогава това поведение въобще не е странно - резултатите биха били по принцип плачевни.

[senser]

gateway, съгласен съм с теб - наистина скоростта измерена с hdparm или dd не може да се сравнява при реален workload.
Но лоада на с-мата да е постоянно около и над 1 и в същото време процесора да почива някак си не ми се струва нормално.
Сега се присещам и за още един момент който е свързан - при монтиране на някаква мрежова ФС, sshfs, nfs ... etc и без никакво четене или писане лоада скача чувствително, особено ако поради някаква причина връзката с отдалечената ФС се лагне

Да разбирам ли, че никой не мисли, че има връзка с cancelled_write_bytes

[gat3way]

Не мисля, че има връзка и не е ненормално - по-странното е защо init процеса е успял да изпише и изчете над 60ГБ. Не съм сигурен дали това с мрежовите системи не е съвсем отделен проблем. Може ли да пейстнеш какво има в /proc/interrupts ?

[senser]

Може ли да пейстнеш какво има в /proc/interrupts ?

Код:

less /proc/interrupts
           CPU0       
  0:   10791420   IO-APIC-edge      timer
  1:      48141   IO-APIC-edge      i8042
  8:          1   IO-APIC-edge      rtc0
 10:    1039416   IO-APIC-fasteoi   acpi
 12:     128372   IO-APIC-edge      i8042
 14:     312380   IO-APIC-edge      pata_sis
 15:     416649   IO-APIC-edge      pata_sis
 17:         14   IO-APIC-fasteoi   yenta, yenta
 18:    1276141   IO-APIC-fasteoi   SiS SI7013 Modem, SiS SI7012
 19:    1076192   IO-APIC-fasteoi   ohci1394, b43
 20:     393121   IO-APIC-fasteoi   ohci_hcd:usb2
 21:     131135   IO-APIC-fasteoi   ohci_hcd:usb3
 23:         10   IO-APIC-fasteoi   ehci_hcd:usb1
NMI:          0   Non-maskable interrupts
LOC:   11534875   Local timer interrupts
SPU:          0   Spurious interrupts
PMI:          0   Performance monitoring interrupts
PND:          0   Performance pending work
THR:          0   Threshold APIC interrupts
MCE:          0   Machine check exceptions
MCP:        106   Machine check polls
ERR:          4
MIS:          0

изчетените и изписани байтове на инит процеса са за неизключвана машина 4-5 дена

[gat3way]

Ммм нищо ненормално. Дали случайно SiS нямат някъде на сайта си линукски драйвер за IDE контролера си? Може пък с него да се държи по-добре...

[senser]

Ммм нищо ненормално. Дали случайно SiS нямат някъде на сайта си линукски драйвер за IDE контролера си? Може пък с него да се държи по-добре...

Честно казано не съм проверявал. Единствено за видеото съм търсил драйвер, но определено SiS са един от най-лошите варианти за ползване с Линукс......., но както и да е

Ако проблемът беше с драйвера на ИДЕ-то, нямаше ли да има и кофти производителност с hdparm и  dd. От друга страна, ако scheduler-a е причината, доста народ трябваше да е изревал досега. Аз в момента съм със sio, като че ли най-добре се държи.

Направих и един тест със sysbench, ако някой иска да постне резултати да сравним:

Код:

sysbench --test=fileio --file-total-size=1500MB --file-test-mode=rndrw run
sysbench 0.4.10:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Extra file open flags: 0
128 files, 11.719Mb each
1.4648Gb total file size
Block size 16Kb
Number of random requests for random IO: 10000
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Threads started!
Done.

Operations performed:  6000 Read, 4000 Write, 12800 Other = 22800 Total
Read 93.75Mb  Written 62.5Mb  Total transferred 156.25Mb  (1.3697Mb/sec)
   87.66 Requests/sec executed

Test execution summary:
    total time:                          114.0749s
    total number of events:              10000
    total time taken by event execution: 76.6723
    per-request statistics:
         min:                                  0.01ms
         avg:                                  7.67ms
         max:                                342.44ms
         approx.  95 percentile:              19.07ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   76.6723/0.00

Резултата се приближава до реални условия, като че ли и лоада беше малко над 1

Това е с процесор AMD65 Turion 800/1600 MHz 512 cache; 1GB RAM

[Naka]

Ако проблемът беше с драйвера на ИДЕ-то, нямаше ли да има и кофти производителност с hdparm и  dd.

Да точно така е. Досега не съм виждал диск който да има добра скорст с hdparm и dd, а пък реално да е зле под обикновен товар.

От друга страна, ако scheduler-a е причината, доста народ трябваше да е изревал досега.

И това е така. scheduler-a не би трябвало да има никава връзка с ide-драйвера и sis чипсета. Поне така си мисля.

Имаше и един тест Bonnie++ Пусни го за 1GB.
А някави подозрителни съобщения в dmesg имаш ли?
Виж и smartctl --all /dev/sd...

[senser]

Имаше и един тест Bonnie++ Пусни го за 1GB.
А някави подозрителни съобщения в dmesg имаш ли?
Виж и smartctl --all /dev/sd...

Не го знаех този тест, сега ще го пусна.
В dmesg не съм заблелязал нищо подозрително:

Код:

dmesg  |egrep -i "ide|disk|sda"
Command line: root=/dev/ram0 real_root=/dev/sda5 init=/linuxrc resume2=file:/dev/hda5:0xfc038 resume=UUID:7bc7db8d24134cfdac72d1e63a14fd5e:0x42f68 real_resume=UUID:7bc7db8d24134cfdac72d1e63a14fd5e:0x42f68 splash=verbose,theme:natural_gentoo,fbcon=scrollback:512K vga=791 CONSOLE=/dev/tty1 INPUT_EVDEV=y DEVFS_MOUNT=n acpi_sleep=s3_bios,s3_mode nodevfs udev  memory_corruption_check=1 pci=nomsi
BIOS-provided physical RAM map:
RAMDISK: 37df4000 - 37ff0000
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ10 used by override.
Kernel command line: root=/dev/ram0 real_root=/dev/sda5 init=/linuxrc resume2=file:/dev/hda5:0xfc038 resume=UUID:7bc7db8d24134cfdac72d1e63a14fd5e:0x42f68 real_resume=UUID:7bc7db8d24134cfdac72d1e63a14fd5e:0x42f68 splash=verbose,theme:natural_gentoo,fbcon=scrollback:512K vga=791 CONSOLE=/dev/tty1 INPUT_EVDEV=y DEVFS_MOUNT=n acpi_sleep=s3_bios,s3_mode nodevfs udev  memory_corruption_check=1 pci=nomsi
  #2 [0037df4000 - 0037ff0000]         RAMDISK
pci 0000:01:00.0: Boot video device
PM: Resume from disk failed.
sd 0:0:0:0: [sda] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 < sda5 sda6 sda7 > sda3
sd 0:0:0:0: [sda] Attached SCSI disk
EXT3-fs (sda5): recovery required on readonly filesystem
EXT3-fs (sda5): write access will be enabled during recovery
EXT3-fs (sda5): orphan cleanup on readonly fs
EXT3-fs (sda5): 14 orphan inodes deleted
EXT3-fs (sda5): recovery complete
EXT3-fs (sda5): mounted filesystem with writeback data mode
EXT3-fs (sda5): using internal journal
REISERFS (device sda7): found reiserfs format "3.6" with standard journal
REISERFS warning (device sda7):  reiserfs_fill_super: CONFIG_REISERFS_CHECK is set ON
REISERFS warning (device sda7):  reiserfs_fill_super: - it is slow mode for debugging.
REISERFS (device sda7): using ordered data mode
REISERFS (device sda7): journal params: device sda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
REISERFS (device sda7): checking transaction log (sda7)
REISERFS debug (device sda7): journal-1153: found in header: first_unflushed_offset 4940, last_flushed_trans_id 2794869
REISERFS debug (device sda7): journal-1206: Starting replay from offset 4940, trans_id 2794870
REISERFS debug (device sda7): journal-1299: Setting newest_mount_id to 336
REISERFS (device sda7): Using r5 hash to sort names
REISERFS (device sda7): Removing [24768 168033 0x0 SD]..done
REISERFS (device sda7): Removing [24768 166196 0x0 SD]..done
REISERFS (device sda7): There were 2 uncompleted unlinks/truncates. Completed
Adding 979928k swap on /dev/sda6.  Priority:-1 extents:1 across:979928k

[gat3way]

Ако проблемът беше с драйвера на ИДЕ-то, нямаше ли да има и кофти производителност с hdparm и  dd. От друга страна, ако scheduler-a е причината, доста народ трябваше да е изревал досега. Аз в момента съм със sio, като че ли най-добре се държи.

Трудно е да се каже - първо, наистина има кофти производителност с hdparm, това идва от бавния udma режим. Имам един стар 80-гигабайтов Maxtor IDE диск, при него правя около 58 мб/с. Но при копиране на големи файлове, никога не съм виждал скорости по-високи от няколко мегабайта в секунда.

I/O scheduler има доста голяма връзка с IDE драйвера. На практика, в общият случай, I/O scheduler-a работи едно ниво над дисковия драйвер - ако му се връщат грешни статус кодове или драйверът проявява странности при обслужването на разни заявки, нормалното функциониране на elevator-а  пряко зависи от тези неща.

[senser]

Това е резултата от bonnie++: http://senser.no-ip.info/bonnie.html

А това тук е от piozone:

Код:

piozone /dev/sda
[PIOZONE, version 1.0 - Copyright (c) 2002 Peter Eriksson <pen@lysator.liu.se>]

Linear read transfer rates:
26.5 MB/s at offset   0 GB using  64 KiB reads
26.0 MB/s at offset  33 GB using  64 KiB reads
18.1 MB/s at offset  67 GB using  64 KiB reads
21.3 MB/s at offset 101 GB using  64 KiB reads
19.1 MB/s at offset 135 GB using  64 KiB reads
19.0 MB/s at offset 169 GB using  64 KiB reads
17.9 MB/s at offset 202 GB using  64 KiB reads
18.8 MB/s at offset 236 GB using  64 KiB reads
19.2 MB/s at offset 270 GB using  64 KiB reads
17.3 MB/s at offset 304 GB using  64 KiB reads
16.8 MB/s at offset 338 GB using  64 KiB reads
16.6 MB/s at offset 372 GB using  64 KiB reads
18.8 MB/s at offset 405 GB using  64 KiB reads
17.2 MB/s at offset 439 GB using  64 KiB reads
16.7 MB/s at offset 473 GB using  64 KiB reads
 4.6 MB/s at offset 507 GB using  64 KiB reads
13.6 MB/s at offset 541 GB using  64 KiB reads
16.2 MB/s at offset 574 GB using  64 KiB reads
14.2 MB/s at offset 608 GB using  64 KiB reads
13.0 MB/s at offset 642 GB using  64 KiB reads
13.7 MB/s at offset 676 GB using  64 KiB reads
11.9 MB/s at offset 710 GB using  64 KiB reads
15.8 MB/s at offset 744 GB using  64 KiB reads
12.9 MB/s at offset 777 GB using  64 KiB reads
13.6 MB/s at offset 811 GB using  64 KiB reads
13.7 MB/s at offset 845 GB using  64 KiB reads
                   
26.2 MB/s at offset   0 GB using 1024 KiB reads
24.3 MB/s at offset  33 GB using 1024 KiB reads
16.3 MB/s at offset  67 GB using 1024 KiB reads
16.9 MB/s at offset 101 GB using 1024 KiB reads
18.8 MB/s at offset 135 GB using 1024 KiB reads
17.9 MB/s at offset 169 GB using 1024 KiB reads
16.6 MB/s at offset 202 GB using 1024 KiB reads
16.5 MB/s at offset 236 GB using 1024 KiB reads
16.8 MB/s at offset 270 GB using 1024 KiB reads
16.8 MB/s at offset 304 GB using 1024 KiB reads
15.9 MB/s at offset 338 GB using 1024 KiB reads
11.6 MB/s at offset 372 GB using 1024 KiB reads
11.9 MB/s at offset 405 GB using 1024 KiB reads
10.9 MB/s at offset 439 GB using 1024 KiB reads
 9.7 MB/s at offset 473 GB using 1024 KiB reads
14.9 MB/s at offset 507 GB using 1024 KiB reads
17.9 MB/s at offset 541 GB using 1024 KiB reads
17.2 MB/s at offset 574 GB using 1024 KiB reads
13.0 MB/s at offset 608 GB using 1024 KiB reads
11.4 MB/s at offset 642 GB using 1024 KiB reads
14.9 MB/s at offset 676 GB using 1024 KiB reads
13.0 MB/s at offset 710 GB using 1024 KiB reads
12.2 MB/s at offset 744 GB using 1024 KiB reads
13.7 MB/s at offset 777 GB using 1024 KiB reads
17.2 MB/s at offset 811 GB using 1024 KiB reads
16.5 MB/s at offset 845 GB using 1024 KiB reads
15.5 MB/s at offset 879 GB using 1024 KiB reads
15.5 MB/s at offset 913 GB using 1024 KiB reads
                   
Random access read transfer rates (area size: 1 GiB):
630.3 MB/s at offset   0 GB using  64 KiB reads
 7.0 MB/s at offset  33 GB using  64 KiB reads
168.4 MB/s at offset  67 GB using  64 KiB reads
                   
 9.9 MB/s at offset   0 GB using 1024 KiB reads
18.2 MB/s at offset  33 GB using 1024 KiB reads
15.8 MB/s at offset  67 GB using 1024 KiB reads

Според мен всичко изглежда нормално, а на всичкото отгоре и лоада е в нормални граници. Подозирам, че се на дължи на факта, че днес имаше 2-3 токови удара, заради които се наложи да рестартирам РС. По принцип нямам навик да я спирам и си седи пуснат нон стоп, което ме навежда на мисълта, че лоада най-вероятно се качва с течение на времето, т.е. с увеличения на uptime. Предполагам, че сутринта като стана, ако няма други токови удари, ще е доста по бавна машинката, но да видим