Linux за българи: Форуми

Привет!

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

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

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-а да ги бенчна?

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

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

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

Лоши сектори

Здрасти,
За да сме коректни, нали не очакваш чудеса от хардуера ?
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
Не си обективен. Или тествай само дисковия тракт или не си прави грешни изводи.
Ако искаш, да направиш някой и друг тест, мога да ти предложа "мръсни" идеи.
Успех !

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

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

И ето на 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

Здрасти,
За да сме коректни, нали не очакваш чудеса от хардуера ?
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
Не си обективен. Или тествай само дисковия тракт или не си прави грешни изводи.
Ако искаш, да направиш някой и друг тест, мога да ти предложа "мръсни" идеи.
Успех !

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

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

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

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

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

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

@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
както казах проблема е наследен, нямам си и най-малка представа как е бил настоен. Понеже машината е в Рак ще трябва първо да се извади и нагласи...

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

Има много нормална причина за това, когато пишеш нещо във файл, нищо не се 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.



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

@nemanema

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

@gat3way

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

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

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

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

пусни един:

hdparm -tT /dev/sda

да видим какво ще даде


може да пробваш и:

http://www.coker.com.au/bonnie++/ ($2)

@gat3way

Ок - значи. Активирам sync, рестартирам и тествам пак?

@jet

hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   6202 MB in  2.00 seconds = 3103.49 MB/sec
 Timing buffered disk reads: 202 MB in  3.01 seconds =  67.20 MB/sec

Както казах нямам проблем при четене.

time dd of=/dev/null if=/home/neshto_si.txt bs=1M count=600
600+0 records in
600+0 records out
629145600 bytes (629 MB) copied, 11.1767 s, 56.3 MB/s

real   0m11.213s
user   0m0.000s
sys   0m0.432s

Обаче записа ме срива... а паралелни операции (четене/запис) направо го сриват.

 

Не е чак толкова бавно. Днешните масови SATA дискове са по-бързички де, но няма нещо драстично бавно. Но това е просто sequential четене.

Това с бавното писане е интересно. Дали RAID контролера ги прави тези мизерии или има някакъв грозен бъг в ядрото не знам. Трябва да пробваш да четеш и пишеш от/върху блоковото устройство. Нямаш ли място за един нов тестов дял на масива?

Може разбира се да монтираш файловата система със sync и да четеш и пишеш във файл, но така минаваш през VFS слоя и ако се окаже че е там проблема, може погрешно да обвиним контролера или пък драйвера за него.

То всъщност бавното писане го открих когато почнах да импортвам базите данни (почти гигабайт дъмпове) и ми отне само на едната около 3-4 часа да се импортне. Какво ли не правих - оптимизирах, настройвах и т.н.
След седмица ми писна и я импортнах на локалната машина и като открих разликата в производителността щях да падна от стола.

Не - нямам дял за тестове уви.

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# /dev/sda2       /               ext3    errors=remount-ro 0       1
UUID=971b700a-72e0-4032-9823-0052c88f82ae       /               ext3    errors=remount-ro 0       1
# /dev/sda1       none            swap    sw              0       0
UUID=348a44a5-223e-4351-9ce4-03b6ed089a76       none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0

Ей това е fstab-a.

Напротив - имаш :)

Изключи swap-a (swapoff -a), осери swap дяла с колкото искаш тестове, после му дай mkswap /dev/sda1 и swapon -a:)

Добре де... как да тествам на блоковото устройство? Пак dd?

Въобще се опитай да разкараш swap-a с

vm.swappiness = 0

в sysctl

Ахъм - само че вместо файл, върху устройството.

След последните коментари продължавам да съм на мнение, че е настройка от контролер.
Във WebHOST BIOS interfaces е отговора. Трябва да се конфигурира правилно за да се изцеди максималната производителност на железарията.

Аз също поддържам това мнение, но както по-горе обясних съм насаден на пачи яйца...