Тема: бавна дискова активност (Прочетена 2689 пъти)

n00b · « -: Dec 02, 2010, 04:06 »

Привет!

От едно известно време администрирам един сървър (дълга история, наследен ми е).

Обаче ми направи впечатление че дисковата активност е бавна.

00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory Controller Hub (rev 92)
00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 2-3 (rev 92)
00:03.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 3 (rev 92)
00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 4 (rev 92)
00:05.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 5 (rev 92)
00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 6-7 (rev 92)
00:07.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 7 (rev 92)
00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA Engine (rev 92)
00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 92)
00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 92)
00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 92)
00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev 92)
00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev 92)
00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev 92)
00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev 92)
00:1d.0 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (rev 09)
00:1d.1 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (rev 09)
00:1d.2 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (rev 09)
00:1d.3 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #4 (rev 09)
00:1d.7 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller (rev 09)
00:1f.2 IDE interface: Intel Corporation 631xESB/632xESB/3100 Chipset SATA IDE Controller (rev 09)
00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller (rev 09)
01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01)
01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge (rev 01)
02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 (rev 01)
02:01.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E2 (rev 01)
05:05.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS (rev 01)
07:00.0 PCI bridge: Broadcom EPB PCI-Express to PCI-X Bridge (rev b5)
08:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5715 Gigabit Ethernet (rev a3)
08:04.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5715 Gigabit Ethernet (rev a3)
0c:05.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) (rev 02)

# mpt-status
ioc0 vol_id 0 type IM, 2 phy, 279 GB, state OPTIMAL, flags ENABLED
ioc0 phy 1 scsi_id 8 ATA Maxtor 6V300F0 1630, 279 GB, state ONLINE, flags NONE
ioc0 phy 0 scsi_id 1 ATA Maxtor 6V300F0 1630, 279 GB, state ONLINE, flags NONE

Това е хардуера (вързан в RAID 1).

Ето и реални тестове на 2 различни машини.

---------
$ time gunzip -t -vvvvvvvvvvv linux-2.6.35.tar.gz
linux-2.6.35.tar.gz:    OK

real   0m2.695s
user   0m2.636s
sys   0m0.037s
----------

Това е на моята каруца (напълно нормален MacPro)

-----------
# time gunzip -t -v linux-2.6.35.tar.gz
linux-2.6.35.tar.gz:    OK

real   0m4.281s
user   0m4.232s
sys   0m0.048s
-----------

Това е на uber страшния сървър дето на хартия параметрите му са 2-3 пъти по-добри. Общо взето банален тест - да разархивираме 88 МБ файл за да получим 412 МБ такъв.

----------
$ time gunzip linux-2.6.35.tar.gz
real   0m31.325s
user   0m0.596s
sys   0m4.759s
----------
Това е при мен. Общо взето нормална скорост.

----------
# time gunzip linux-2.6.35.tar.gz
real   3m36.754s
user   0m0.232s
sys   0m2.368s
----------

Тук гледам едно влачене... дето не мога да си го обясня...

Нещата са много сложни и заплетени и не мога да си обясня по никакъв начин бавната дискова активност.
Та въпроса ми е има ли някакъв бенчмарк който да го пусна на линукса и на osx-а да ги бенчна?

n00b · « **Отговор #1 -:** Dec 02, 2010, 04:08 »

И преди да питате - съвръра е празен и неизползван (в момента) няма потребители и др. такива.

Натоварването му е 0%.

Друг пример - импортиране на 400 МБ база данни в mysql. На MacPro ми отне около минута/минута и нещо. На сървъра ми отнема около 3-4 часа!

ROKO__ · « **Отговор #2 -:** Dec 02, 2010, 08:35 »

Лоши сектори

nemanema · « **Отговор #3 -:** Dec 02, 2010, 08:54 »

Здрасти,
За да сме коректни, нали не очакваш чудеса от хардуера ?
05:05.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS (rev 01)
Чип на дъното, морално стар, стари кабели, за дисковете не коментирам

а схемния набор 5000Р е класика, с който трябва набедените студенти борещи се за титли пред името да започват обучението си, но . . .
За теста:
1. time dd if=/dev/null of=/home/neshto_si.txt bs=1M count=5000 (големината да е повече от наличната памет на машината)
2. time cat /home/neshto_si.txt > /dev/null
3. time cp /home/neshto_si.txt /home/neshto_si.001.txt
Не си обективен. Или тествай само дисковия тракт или не си прави грешни изводи.
Ако искаш, да направиш някой и друг тест, мога да ти предложа "мръсни" идеи.
Успех !

n00b · « **Отговор #4 -:** Dec 02, 2010, 12:05 »

predator:/home# time dd if=/dev/zero of=/home/neshto_si.txt bs=1M count=5000
5000+0 records in
5000+0 records out
5242880000 bytes (5.2 GB) copied, 386.951 s, 13.5 MB/s

real   6m27.251s
user   0m0.012s
sys   0m12.601s
predator:/home# time cat /home/neshto_si.txt > /dev/null

real   1m30.137s
user   0m0.056s
sys   0m3.396s
predator:/home# time cp /home/neshto_si.txt /home/neshto_si.001.txt

real   8m20.671s
user   0m0.056s
sys   0m15.313s

---------------------------

predator:/home# time dd if=/dev/zero of=/home/neshto_si.txt bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.244101 s, 430 MB/s

real   0m0.736s
user   0m0.000s
sys   0m0.284s
predator:/home# time dd if=/dev/zero of=/home/neshto_si.txt bs=1M count=200
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 5.99526 s, 35.0 MB/s

real   0m10.108s
user   0m0.000s
sys   0m0.532s
predator:/home# time dd if=/dev/zero of=/home/neshto_si.txt bs=1M count=300
300+0 records in
300+0 records out
314572800 bytes (315 MB) copied, 13.2679 s, 23.7 MB/s

real   0m16.552s
user   0m0.000s
sys   0m0.820s
predator:/home# time dd if=/dev/zero of=/home/neshto_si.txt bs=1M count=400
400+0 records in
400+0 records out
419430400 bytes (419 MB) copied, 21.2825 s, 19.7 MB/s

real   0m21.284s
user   0m0.000s
sys   0m0.972s
predator:/home# time dd if=/dev/zero of=/home/neshto_si.txt bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 29.0262 s, 18.1 MB/s

real   0m32.296s
user   0m0.000s
sys   0m1.364s
predator:/home# time dd if=/dev/zero of=/home/neshto_si.txt bs=1M count=600
600+0 records in
600+0 records out
629145600 bytes (629 MB) copied, 37.439 s, 16.8 MB/s

real   0m43.776s
user   0m0.000s
sys   0m1.616s
predator:/home# time dd if=/dev/zero of=/home/neshto_si.txt bs=1M count=700
700+0 records in
700+0 records out
734003200 bytes (734 MB) copied, 44.4468 s, 16.5 MB/s

real   0m44.602s
user   0m0.000s
sys   0m1.868s
predator:/home# time dd if=/dev/zero of=/home/neshto_si.txt bs=1M count=800
800+0 records in
800+0 records out
838860800 bytes (839 MB) copied, 53.3298 s, 15.7 MB/s

real   0m57.559s
user   0m0.000s
sys   0m2.168s
predator:/home# time dd if=/dev/zero of=/home/neshto_si.txt bs=1M count=900
900+0 records in
900+0 records out
943718400 bytes (944 MB) copied, 60.919 s, 15.5 MB/s

real   1m1.122s
user   0m0.000s
sys   0m2.400s
predator:/home# time dd if=/dev/zero of=/home/neshto_si.txt bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 68.7124 s, 15.3 MB/s

real   1m10.328s
user   0m0.000s
sys   0m2.688s

Забележи как при увеличаване на файла производителноста деградира. По-лошото е че проблема е видим само при записване, при четене скоростта си е сякаш нормална.

n00b · « **Отговор #5 -:** Dec 02, 2010, 12:06 »

И ето на MacPro стойностите...

$ time dd if=/dev/zero of=neshto_si.txt bs=1000000 count=5000
5000+0 records in
5000+0 records out
5000000000 bytes transferred in 101.398521 secs (49310384 bytes/sec)

real   1m41.940s
user   0m0.011s
sys   0m4.652s

romeo_ninov · « **Отговор #6 -:** Dec 02, 2010, 12:09 »

Цитат на: nemanema в Dec 02, 2010, 08:54

Здрасти,
За да сме коректни, нали не очакваш чудеса от хардуера ?
05:05.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS (rev 01)
Чип на дъното, морално стар, стари кабели, за дисковете не коментирам а схемния набор 5000Р е класика, с който трябва набедените студенти борещи се за титли пред името да започват обучението си, но . . .
За теста:
1. time dd if=/dev/null of=/home/neshto_si.txt bs=1M count=5000 (големината да е повече от наличната памет на машината)
2. time cat /home/neshto_si.txt > /dev/null
3. time cp /home/neshto_si.txt /home/neshto_si.001.txt
Не си обективен. Или тествай само дисковия тракт или не си прави грешни изводи.
Ако искаш, да направиш някой и друг тест, мога да ти предложа "мръсни" идеи.
Успех !

точка едно трябва да е:

Код:

1. time dd if=/dev/zero of=/home/neshto_si.txt bs=1M count=5000

защото както е горе ще създаде файл с нулева големина

Код:

[root@vmlinux ~]# time dd if=/dev/null of=neshto_si.txt bs=1M count=5000
0+0 records in
0+0 records out
0 bytes (0 B) copied, 4.7729e-05 seconds, 0.0 kB/s

real    0m0.055s
user    0m0.000s
sys     0m0.007s
[root@vmlinux ~]# ls -l neshto_si.txt
-rw-r--r-- 1 root root 0 Dec  2 18:08 neshto_si.txt

n00b · « **Отговор #7 -:** Dec 02, 2010, 12:36 »

Да - явно колегата в бързината е объркал /null с /zero. Разконспирирахме го вече...

nemanema · « **Отговор #8 -:** Dec 02, 2010, 13:43 »

Абсолютно правилна и адекватна корекция на romeo_ninov !
Благодаря !
Относно намаляването на скоростта ще коментирам както ги виждам нещата на база наличната информация.
Увеличаване обема на тестовия файл увеличава времето за писане, респективно намалява скоростта в единица време. Защо се получава ? Ами 1068 не е най продуктивният чип

. Обикновено драстична разлика четене/писане се получава, когато не е добре конфигуриран embedded controller-a. Не си спомням точната опция в Web config менюто преди зареждане на ОС. Само насока, трябва да се укаже да ползва cache на самите дискове и да не се изчаква блоковия процес за писане и синхронизация преди завършването, а да се допусне стартиране на следващият такъв. Добре ще е да се flash-не самото дъно и ако има възможност и самия чип 1068. Ако има KVM и не е супер секретна машина, предлагам да ми се даде достъп в указан ден и час да погледна самите настройки на контролера, и ако се сетя какво се ръчка, да го оптимизираме да е правилно. Не е задължително да е от моя машина, не ме мързи и ако питащият е в София, може да се срещнем и от негова машина да го ръчкаме.
Според мен е това, и трябва да се вдигне скоростта след корекция.
Успех !

gat3way · « **Отговор #9 -:** Dec 02, 2010, 13:50 »

Увеличаването на големината на текстовия файл намаля производителността, но не защото ти е калпав контролера. Пробвай да си монтираш файловата система с sync флаг и наглеждай по време на теста утилизацията на паметта и ще разбереш защо.

jet · « **Отговор #10 -:** Dec 02, 2010, 15:41 »

ах този презрян Линукс.

а ти прегледа ли SMART данните на диска

n00b · « **Отговор #11 -:** Dec 02, 2010, 18:00 »

@jet

smartctl -a /dev/sda
smartctl 5.40 2010-07-12 r3124 [i686-pc-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

Device: LSILOGIC Logical Volume Version: 3000
Device type: disk
Local Time is: Thu Dec 2 18:01:23 2010 EET
Device does not support SMART

Error Counter logging not supported
Device does not support Self Test logging

-----------
W.T.F.

@gat3way
да ти копирам направо fstab да помъдруваме?

@nemanema
както казах проблема е наследен, нямам си и най-малка представа как е бил настоен. Понеже машината е в Рак ще трябва първо да се извади и нагласи...

nemanema · « **Отговор #12 -:** Dec 02, 2010, 18:14 »

Ако няма KVM достъп до машината, да това ще е проблем, защото няма да ме пуснат до въпросният рак.
Наследената машина не е проблем, както и как е настроена. Въпросът е сега да се направи да е добре и да се изцеди колкото може от желязото.
Явно трябва да обесня какво е KVM достъп, за да не си губим времето. KVM (keyboard, video, mouse) т.е. да си виждаш машината отдалечено както, когато си пред нея, това включва и power ON & power OFF, а също така и разни други глезотийки.

gat3way · « **Отговор #13 -:** Dec 02, 2010, 18:34 »

Има много нормална причина за това, когато пишеш нещо във файл, нищо не се commit-ва директно на диска (освен ако не си монтирал файловата система със sync флаг). Всичко това отива в кеша и се изписва след някакво време. Ако видиш /proc/meminfo, има две полета - Cached и Dirty. Cached ти е page cache-a, dirty ти е паметта, на която й е писано след известен период от време да се commit-не на диска.

Има няколко procfs-базирани настройки, които контролират как става това, но по дефолт най-често, dirty паметта се изписва или регулярно 20-30 секунди, или преди да се достигне една threshold стойност, която обикновено е 10% от свободната памет + Cached паметта, но може и да има различна стойност.

Демек ако примерно имаш 2 гигабайта памет, 200 мегабайта свободни и 1 гигабайт pagecache, dirty паметта ще започне да се commit-ва върху диска след като надмине 120 мегабайта (или ако преди това не уцели регулярното flush-ване през половин минута).

Което на практика би ти позволило да изпишеш 100 мегабайта във файла с много голяма скорост, понеже ти реално погледнато не пишеш нищо върху диска, пишеш в кеша.

При същото положение, пробваш ли се да изпишеш 200 мегабайта във файла, на 120-тия мегабайт, pdflush ще се събуди и ще почне да изписва dirty страниците върху диска и това е бавно.

Надявам се не вярваш, че постигнатата скорост при писането в 100-мегабайтовия файл (430 MB/s) е възможна. SAS шината, която доколкото виждам е в употреба, има 2400 Mbit/s максимална теоретична пропускателна способност, твоят трансфер е 430*8 = 3600 Mbit/s.

Та, трябва да тестваш да пишеш върху блоково устройство, а не върху файл.

n00b · « **Отговор #14 -:** Dec 02, 2010, 19:37 »

@nemanema

Знам, имам и няколко kvm-over-ip, но конкретната машина няма уви. Явно ще последва махане от рака колкото и да не ми се иска.

@gat3way

Ама ако активирам sync и ще ме спъне още повече. В момента кеша спасява донякъде ситуацията въпреки че трансфера на запис е просто плачевен.

При малки записи първо влиза в кеша и после се flush-ва на диска.

Ще пробвам да обновя към по-нов кернел, ако и това не помогне ще последва вадене...

Автор Тема: бавна дискова активност (Прочетена 2689 пъти)

n00b

бавна дискова активност

n00b

Re: бавна дискова активност

ROKO__

Re: бавна дискова активност

nemanema

Re: бавна дискова активност

n00b

Re: бавна дискова активност

n00b

Re: бавна дискова активност

romeo_ninov

Re: бавна дискова активност

n00b

Re: бавна дискова активност

nemanema

Re: бавна дискова активност

gat3way

Re: бавна дискова активност

jet

Re: бавна дискова активност

n00b

Re: бавна дискова активност

nemanema

Re: бавна дискова активност

gat3way

Re: бавна дискова активност

n00b

Re: бавна дискова активност