scsii load serwera przy operacjach dyskowych

[ednet 136]

Mam serwer posiadający dysk serial ata 2 i narazie calkowity brak obciążeń. Load 0.00.

Przy zwyklym kopiowaniu plików z jednego katlogu do drugiego load systemu rosnie do 2.

Serwer: Athlon 64 3200+/2GB ram + Centos5.

Wiadomo ze przy wiekszym obciązeniu to moze byc problem.

 

czy dyski SCSI tez tak reagują na zwykle kopiowanie?

 

Ed

[nginxq 0]

wrzuc tu hdparm -tT /dev/sda1

[beliq 442]

Jeśli kopiujesz z katalogu/partycji do katalogu/partycji w obrębie tego samego fizycznego dysku,

wtedy operacja kopiowania będzie bardziej obciążająca dla systemu z oczywistych względów,

nie mniej jednak skąd Ty wziąłeś ten LA ~ 2 to ja nie wiem.

Masz w tym systemie coś pewnie nieźle powalone.

[ednet 136]

[root@host~]# cat /etc/fstab
/dev/sda1			   /					   ext3	defaults,noatime,nodiratime,usrquota,grpquota					  1 1
/dev/sda2			   /tmp					ext3	defaults,noatime,nodiratime,usrquota,grpquota					  1 2
/dev/sda3			   swap					swap	defaults														   0 0
/dev/sdb1			   /home				   ext3	defaults,nosuid,nodev,noatime,nodiratime,usrquota,grpquota		 1 2
devpts				  /dev/pts				devpts  gid=5,mode=620													 0 0
proc					/proc				   proc	defaults,noexec,nosuid,nodev									   0 0
sysfs				   /sys					sysfs   defaults,noexec,nosuid,nodev									   0 0
#tmpfs				  /dev/shm				tmpfs   defaults,noexec,nosuid,nodev									   0 0

[root@host~]# hdparm -tT /dev/sda1

/dev/sda1:
Timing cached reads:   1992 MB in  2.00 seconds = 995.31 MB/sec
Timing buffered disk reads:  204 MB in  3.02 seconds =  67.59 MB/sec

[root@host~]# hdparm -tT /dev/sdb1

/dev/sdb1:
Timing cached reads:   2012 MB in  2.00 seconds = 1005.77 MB/sec
Timing buffered disk reads:  224 MB in  3.01 seconds =  74.42 MB/sec

 

load przed kopiowaniem: 0.00 (serwer jeszcze się nudzi)

 

cp plik_2GB.tar.gz plik_2GB_kopia.tar.gz

kopiowanie pliku 2GB w tym samym katalogu - 181 sek

srednio: 11 MB/sek

load pod koniec kopiowania 3.6

 

cp plik_2GB.tar.gz /home/plik_2GB_kopia.tar.gz

kopiowanie pliku 2GB na drugi dysk - 92 sek

srednio: 21 MB/sek

load pod koniec kopiowania 4.6

 

Kiepsko to wyglada

 

 

Ed

[ednet 136]

Czy macie jakieś pomysły?

 

Czy zgłosić do firmy gdzie dzierżawię serwer ze jest problem sprzętowy? Czy może taki load w czasie kopiowania to normalna rzecz?

 

 

Ed

[marekxbx 71]

Ed wiadomo ze load podnosi sie podczas kopiowania ale aby az tak skakal to jest niepokojace.

[moron 0]

moze sprawdz jak podczas kopiowania zachowuje sie pamiec?

[cyberluk 0]

Odpal podczas kopiowania iostat -m 1 i wklej kilka linijek jak już w systemie load podskoczy. Wyszukaj w logach (np. dmesg) wszystko co dotyczy inicjalizacji kontrolera i wklej tutaj.

Ja tak miałem 2 dni temu z płytą Intela na i965 i Core2 Duo. Do tego dorzucili jakiegoś pseudoPromisa i dopiero ostatni kernel pomógł... Kernel nie potrafił pogodzić obsługi przerwań z 2 corami, zaraz potem wykopywało się DMA i dysk chodził jak stacja dyskietek.

[ednet 136]

Odpal podczas kopiowania iostat -m 1 i wklej kilka linijek jak już w systemie load podskoczy. Wyszukaj w logach (np. dmesg) wszystko co dotyczy inicjalizacji kontrolera i wklej tutaj.

 

iostat -m 1

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
	   0,00	0,00   18,00   82,00	0,00	0,00

Device:			tps	MB_read/s	MB_wrtn/s	MB_read	MB_wrtn
sda			 303,00		32,25		 0,13		 32		  0
sdb			   0,00		 0,00		 0,00		  0		  0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
	   0,00	0,00	5,05   94,95	0,00	0,00

Device:			tps	MB_read/s	MB_wrtn/s	MB_read	MB_wrtn
sda			 124,24		 7,83		13,57		  7		 13
sdb			   0,00		 0,00		 0,00		  0		  0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
	   0,00	0,00	0,99   99,01	0,00	0,00

Device:			tps	MB_read/s	MB_wrtn/s	MB_read	MB_wrtn
sda			  68,32		 0,00		16,08		  0		 16
sdb			   0,00		 0,00		 0,00		  0		  0

 

 

dmessg:

Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
Linux agpgart interface v0.101 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE-CK804: IDE controller at PCI slot 0000:00:06.0
NFORCE-CK804: chipset revision 242
NFORCE-CK804: not 100% native mode: will probe irqs later
NFORCE-CK804: 0000:00:06.0 (rev f2) UDMA133 controller
ide0: BM-DMA at 0xfb00-0xfb07, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xfb08-0xfb0f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
Probing IDE interface ide1...
Probing IDE interface ide0...
Probing IDE interface ide1...
ide-floppy driver 0.99.newide
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3200+ processors (1 cpu cores)
powernow-k8:	0 : fid 0xc (2000 MHz), vid 0x8
powernow-k8:	1 : fid 0xa (1800 MHz), vid 0x8
powernow-k8:	2 : fid 0x2 (1000 MHz), vid 0x12
Using IPI No-Shortcut mode
ACPI: (supports S0 S1 S4 S5)
Freeing unused kernel memory: 220k freed
Write protecting the kernel read-only data: 387k
Time: tsc clocksource has been installed.
USB Universal Host Controller Interface driver v3.0
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
SCSI subsystem initialized
libata version 2.21 loaded.
sata_nv 0000:00:07.0: version 3.4
ACPI: PCI Interrupt Link [APSI] enabled at IRQ 23
ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 23 (level, low) -> IR
sata_nv 0000:00:07.0: Using ADMA mode
ACPI: PCI Interrupt Link [APSI] enabled at IRQ 23
ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 23 (level, low) -> IR
sata_nv 0000:00:07.0: Using ADMA mode
PCI: Setting latency timer of device 0000:00:07.0 to 64
scsi0 : sata_nv
scsi1 : sata_nv
ata1: SATA max UDMA/133 cmd 0xf8806480 ctl 0xf88064a0 bmdma 0x0001f600 irq 217
ata2: SATA max UDMA/133 cmd 0xf8806580 ctl 0xf88065a0 bmdma 0x0001f608 irq 217
ata1: SATA link down (SStatus 0 SControl 300)
ata2: SATA link down (SStatus 0 SControl 300)
ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [APSJ] -> GSI 22 (level, low) -> IR
sata_nv 0000:00:08.0: Using ADMA mode
PCI: Setting latency timer of device 0000:00:08.0 to 64
scsi2 : sata_nv
scsi3 : sata_nv
ata3: SATA max UDMA/133 cmd 0xf881c480 ctl 0xf881c4a0 bmdma 0x0001f100 irq 225
ata4: SATA max UDMA/133 cmd 0xf881c580 ctl 0xf881c5a0 bmdma 0x0001f108 irq 225
ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata3.00: ATA-7: SAMSUNG HD082GJ, JE100-19, max UDMA7
ata3.00: 156301488 sectors, multi 16: LBA48 NCQ (depth 31/32)
ata3.00: configured for UDMA/133
ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata4.00: ATA-7: SAMSUNG HD082GJ, JE100-19, max UDMA7
ata4.00: 156301488 sectors, multi 16: LBA48 NCQ (depth 31/32)
ata4.00: configured for UDMA/133
 Vendor: ATA	   Model: SAMSUNG HD082GJ   Rev: JE10
 Type:   Direct-Access					  ANSI SCSI revision: 05
ata3: bounce limit 0xFFFFFFFFFFFFFFFF, segment boundary 0xFFFFFFFF, hw segs 61
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write through
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write through
sda: sda1 sda2 sda3
sd 2:0:0:0: Attached scsi disk sda
 Vendor: ATA	   Model: SAMSUNG HD082GJ   Rev: JE10
 Type:   Direct-Access					  ANSI SCSI revision: 05
ata4: bounce limit 0xFFFFFFFFFFFFFFFF, segment boundary 0xFFFFFFFF, hw segs 61
SCSI device sdb: 156301488 512-byte hdwr sectors (80026 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write through
SCSI device sdb: 156301488 512-byte hdwr sectors (80026 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write through
sdb: sdb1
sd 3:0:0:0: Attached scsi disk sdb
kjournald starting.  Commit interval 5 seconds

 

 

Ed

[cyberluk 0]

Z iostata ładnie widać, że faktycznie system leży na I/O Wait. Są dwie możliwości:

1. Kernel nie obsługuje Ci poprawnie kontrolera, postaraj się zrobić upgrade. Nie wiem, który masz kernel, ale przy moich problemach z i965 wystarczył z 2.6.18 na 2.6.22.

2. Trafiłeś na lewe dyski. Mam w domu WDka 80GB, który chodzi jak krew z nosa. Taka seria dysków wyszła sobie, która wszystkie operacje odczytu rozbija na bardzo małe requesty I/O. Koniec końców, dysk dobija do 280tpsów, system jest zajechany, a transfery słabe. Sprawdzałem go na wielu kontrolerach, płytach i system operacyjnych - zawsze to samo. W końcu znalazłem info, że chłopaki mają błąd w firmwarze i... no i ten dysk tak ma. 300tpsów przy odczycie jednego dużego pliku to baaaardzo dużo. Jak jeszcze to przełożysz na 32MB/sec, to już w ogóle porażka...

Sprawdź nowy kernel na początek, a jak nie, to zostaje lipa z dyskami.

[ednet 136]

Z iostata ładnie widać, że faktycznie system leży na I/O Wait. Są dwie możliwości:

1. Kernel nie obsługuje Ci poprawnie kontrolera, postaraj się zrobić upgrade. Nie wiem, który masz kernel, ale przy moich problemach z i965 wystarczył z 2.6.18 na 2.6.22.

2. Trafiłeś na lewe dyski. Mam w domu WDka 80GB, który chodzi jak krew z nosa. Taka seria dysków wyszła sobie, która wszystkie operacje odczytu rozbija na bardzo małe requesty I/O. Koniec końców, dysk dobija do 280tpsów, system jest zajechany, a transfery słabe. Sprawdzałem go na wielu kontrolerach, płytach i system operacyjnych - zawsze to samo. W końcu znalazłem info, że chłopaki mają błąd w firmwarze i... no i ten dysk tak ma. 300tpsów przy odczycie jednego dużego pliku to baaaardzo dużo. Jak jeszcze to przełożysz na 32MB/sec, to już w ogóle porażka...

Sprawdź nowy kernel na początek, a jak nie, to zostaje lipa z dyskami.

 

dzięki za pomoc.

Dam znac jak usunąłem problem.

 

Ed

[ednet 136]

dostalem odpowiedz z firmy gdzie dzierżąwię serwer że "dyski SATA II tak sie zachowuja przy kopiowaniu plikow, za to

spisuja sie lepiej z bazami danych"

 

Czy faktycznie tak moze być? Tak się zachwowują dyski SATA II czy kiepski kontroler?

 

Czy może ktoś sprawdzic jak na swoim serwerze z dyskami SATA II kopiowanie duzego pliku obciąża system?

 

 

 

Ed

[kaczy 0]

dostalem odpowiedz z firmy gdzie dzierżąwię serwer że "dyski SATA II tak sie zachowuja przy kopiowaniu plikow, za to spisuja sie lepiej z bazami danych"

Oj... może czas zmienić nie tylko dysk twardy, ale także serwerownię skoro jej obsługa pisze takie rzeczy? W przypadku baz danych wydajność dysku ma niebagatelne znaczenie, ja sam do MySQL'a używam na serwerze dysków SCSI po 15krpm. Dyski SATA (ze względu na stosunek cena/pojemność) są dobre, ale do obsługi statycznego contentu, nie do baz danych.

[ednet 136]

Oj... może czas zmienić nie tylko dysk twardy, ale także serwerownię skoro jej obsługa pisze takie rzeczy? W przypadku baz danych wydajność dysku ma niebagatelne znaczenie, ja sam do MySQL'a używam na serwerze dysków SCSI po 15krpm. Dyski SATA (ze względu na stosunek cena/pojemność) są dobre, ale do obsługi statycznego contentu, nie do baz danych.

 

Wiadomo ze SCSI jest lepsze, mercedes tez jest lepszy od Łady ale bierze się to co powinno wystarczyć. Być może w tej firmie montuje się do serwerów kiepskie kontrolery. Koszt serwera też był nie za duży, więc nie mozna się spodziewać cudów, ale żeby zwykłe kopiowanie pliku potrafiło kompletnie zamulić serwer to przegięcie.

 

Będę wdzięczny jak sprawdzicie na Waszych serwerkach jak kopiowanie obciąża system i zapodacie wynik o ile wzrósł load.

 

Ed

[malu 460]

Hi

 

ATA SAMSUNG HD403LJ - Na tym dysku działa wszystko dobrze.Load wzrasta minimalnie jednak to normalnie.Jutro zobaczę w firmie na SAS 15k rpm.Jednak zapewne jest tak jak mówi cyberluk warto było by sprawdzic kernel jeżeli nie to poprosić o nowe dyski i markowy kontroler , jednak to na pewno wymaga inwestycji.

[ednet 136]

W moim serwerze są 2 dyski SAMSUNG HD082GJ.

 

U mojego kumpla na jego sprzecie (nie wiem jakim) w czasie kopiowania też load wzrasta do 2 i więcej dlatego jestem ciekaw jaki load jest u Was.

 

Ed

[cyberluk 0]

Ja mam tak:

 

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
	   1,00	0,00	8,00   38,00	0,00   53,00

Device:			tps	MB_read/s	MB_wrtn/s	MB_read	MB_wrtn
sda			 188,00		18,64		18,21		 18		 18

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
	   1,99	0,00	7,96   64,18	0,00   25,87

Device:			tps	MB_read/s	MB_wrtn/s	MB_read	MB_wrtn
sda			 139,00		 9,51		25,79		  9		 25

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
	   1,50	8,50	4,50   45,00	0,00   40,50

Device:			tps	MB_read/s	MB_wrtn/s	MB_read	MB_wrtn
sda			 113,00		 1,52		16,74		  1		 16

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
	   0,51   33,84	4,04   10,61	0,00   51,01

 

22:56:43 up  3:46,  8 users,  load average: 0.59, 0.30, 0.25

[code][13604.576000] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[13604.576000] ata3.00: configured for UDMA/133
[13604.576000] ata3: EH complete
[13604.576000] sd 2:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB)
[13604.576000] sd 2:0:0:0: [sda] Write Protect is off
[13604.576000] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[13604.576000] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

 

Dodam, że jest to dysk w laptopie.

 

Przyszło mi do głowy jeszcze coś. Nie odpalił Ci się żaden trackerd/beagle albo coś podobnego? Bo to one mogą powodować taki duży load. To co ja kopiowałem do tych logów było indexowane przez tracker'a

[ednet 136]

Dodam, że jest to dysk w laptopie.

 

Przyszło mi do głowy jeszcze coś. Nie odpalił Ci się żaden trackerd/beagle albo coś podobnego? Bo to one mogą powodować taki duży load. To co ja kopiowałem do tych logów było indexowane przez tracker'a

 

 

w czasie kopiowania nie ma aktywnego zadnego procese z track lub beag w nazwie.

Aktywny za to jest w czasie kopiowania proces kjournald. Z tego co wiem to jest to proces jądra, czy można go wyłączyć?

 

Ed

[cyberluk 0]

I to on Ci pewnie zabija procka... Nie zapytałem o najważniejsze... Masz EXT3 na tych dyskach? Kjournald odpowiada za uaktualnianie zmian "dziennika" przy filesystemie, tzw. journala.

[ednet 136]

I to on Ci pewnie zabija procka... Nie zapytałem o najważniejsze... Masz EXT3 na tych dyskach? Kjournald odpowiada za uaktualnianie zmian "dziennika" przy filesystemie, tzw. journala.

 

Tak mam EXT3. Czy można wyłączyc Kjournald ?

Mam jeszcze aktywny proces pdflush.

 

 

Czy lepiej żeby tak pozostało?

 

PS. Znalazlem ciekawe info na temat tuningu ext3: http://www.it.imasters.pl/?q=tuning-systemu-plikow

Może się komuś przyda.

 

Ed

[nginxq 0]

Tego sie nie wyłącza;) Zrób update kernela.

[ednet 136]

Tego sie nie wyłącza;) Zrób update kernela.

 

Teraz ma 2.6.18-53.1.4.el5PAE #1 SMP i jest to najnowsza wersja dostępna przez yuma dla Centosa 5

Czy konieczne będzie kompilowanie ze zrodeł?

 

Ed

[Artur Pajkert 39]

Ja a propos odpowiedzi wcześniejszej chciałem dodać, że do intensywnych prac z bazami danych także polecam zawsze SCSI 15k lub SAS 15k. Chodzi tu o odpowiednie kolejkowanie zapytań i mechanikę dysków. Przy bazach istotny jest average seek time, czyli średni czas, po jakim głowica znajdzie się nad obszarem z danymi. W wypadku SAS jest on 3-krotnie niższy niż w wypadku SATA, jak to sobie pomnożysz przez wielu użytkowników i liczbę operacji na sekundę - to robi różnicę. Jeśli koniecznie musisz mieć duży zasób dyskowy i względy finansowe nie pozwalają na SCSI/SAS to polecam co najmniej 4 GB RAM'u - można wówczas zrobić odpowiednio wielkie bufory dla MySql'a, co zmniejszy ilość odwołań dyskowych. RAM do serwerów klasy 'entry' - obecnie zazwyczaj PC-5300 ECC jest stosunkowo niedrogi i taniej jest kupić dużo RAM'u niż duże dyski SCSI/SAS 15k.

 

Na koniec jeszcze 2 słowa o kontrolerach:

W tanich rozwiązaniach dyski SATA są podłączane do kontrolerów na płycie. Są to mało wydajne rozwiązania, które często mają też gorszą funkcjonalność od "pełnych" kontrolerów. Zazwyczaj nie mają także pamięci cache. Oznacza to, że operacje dyskowe nie są

cache'owane na poziomie kontrolera. Przy hurtowym kopiowaniu może nie ma to aż takiego znaczenia, jak przy pracy z wieloma drobnymi plikami, do których następują częste odwołania. Zwróć uwagę, że kontroler z pamięcią podręczną powinien też mieć zasilanie bateryjne. W serwerach do zapisu powinno się wyłączać cache na dysku i korzystać z podtrzymywanego bateryjnie cache kontrolera. Wynika to z faktu, że w razie padu zasilania dane, które zostały wysłane do dysku poprzez cache - mogą zniknąc z pamięci podręcznej, jeśli jest niepodtrzymywana. Możesz zapewne w BIOS'ie właczyć cache na zapisy, co nieznacznie przyspieszy operacje, ale jeśli nie masz podtrzymywania bateryjnego - licz się z ryzykiem utraty danych w razie przerwy w zasilaniu.

 

Moim zdaniem zastosowanie dysków SATA zawsze powinno iść w parze z RAID'ami innymi niż 0, ze względu na wyższą awaryjność takich dysków a także - uwaga - długi czas replikacji macierzy w wypadku pojemnych nośników. Np. na kontrolerze wbudowanym w płytę dysk SATA 500 GB potrafi się replikować 3 godziny, przy braku innych operacji (serwer nie ma załadowanego systemu operacyjnego, replikacja odbywa się z poziomu BIOS'u kontolera). Piszę o tym niezupełnie off-topic, albowiem przy niskiej wydajności systemu dyskowego SATA istnieje silna pokusa łączenia dysków w RAID 0 - wolę więc wcześniej zwrócić uwagę na tę kwestię. Mam nadzieję, że uda Ci się osiągnąć satysfakcjonującą wydajność.

[cyberluk 0]

Teraz ma 2.6.18-53.1.4.el5PAE #1 SMP i jest to najnowsza wersja dostępna przez yuma dla Centosa 5

Czy konieczne będzie kompilowanie ze zrodeł?

 

Ed

 

Źródełka... Przynajmniej 2.6.22...