디스크 작업 정지 데비안

방금 새 데스크탑에 데비안 테스트를 설치했는데 성능이 마음에 들지 않습니다. 디스크 집약적 인 작업 (예 : 시스템에서 패키지 업그레이드)을 수행하면 모든 것이 정지하는 것처럼 보입니다. 예를 들어 Iceweasel의 탭을 변경하는 데 3 초가 걸립니다. 3 년 된 Thinkpad X60 울트라 포터블에서 데비안을 실행하는데 이러한 문제가 없습니다. (노트북의 모든 단일 매개 변수는 데스크탑보다 훨씬 나쁩니다).

기본 패키지 커널 및 스크립트를 사용하고 있습니다.

난 달린다

hdparm -t /dev/sda1

그리고 약 96GB / s를 얻었습니다. 더 잘 작동 시키려면 어떻게해야합니까?

편집 :

grzes:/home/ga# hdparm -i /dev/sda

/dev/sda:

 Model=WDC WD15EARS-00Z5B1, FwRev=80.00A80, SerialNo=WD-WMAVU1362357
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
 BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=2930277168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode

EDIT2 : 아내조차도 "이 새로운 컴퓨터에서는 카메라에서 사진을 복사 할 때 아무것도 할 수 없으며 이전 카메라보다 훨씬 나쁩니다"라고 말했습니다. 따라서 심각해야합니다.

EDIT3 : 2.6.32로 업데이트되었지만 여전히 개선되지 않았습니다.

EDIT4 : 새 디스크는 ext4, 이전 디스크는 ext3입니다.

EDIT5 : 여전히 해결되지 않았습니다. P43 ASUS P5QL-E 보드가 있습니다. 관련성이있는 dmesg의 라인 :

[    0.370850] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)                              
[    0.370852] io scheduler noop registered                                                                      
[    0.370853] io scheduler anticipatory registered                                                              
[    0.370854] io scheduler deadline registered                                                                  
[    0.370876] io scheduler cfq registered (default)
...
[    0.908233] ata_piix 0000:00:1f.2: version 2.13                                                               
[    0.908243] ata_piix 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19                                 
[    0.908246] ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]                                                        
[    0.908275] ata_piix 0000:00:1f.2: setting latency timer to 64                                                
[    0.908316] scsi0 : ata_piix                                                                                  
[    0.908374] scsi1 : ata_piix                                                                                  
[    0.909180] ata1: SATA max UDMA/133 cmd 0xa000 ctl 0x9c00 bmdma 0x9480 irq 19                                 
[    0.909183] ata2: SATA max UDMA/133 cmd 0x9880 ctl 0x9800 bmdma 0x9488 irq 19                                 
[    0.909199] ata_piix 0000:00:1f.5: PCI INT B -> GSI 19 (level, low) -> IRQ 19                                 
[    0.909202] ata_piix 0000:00:1f.5: MAP [ P0 -- P1 -- ]                                                        
[    0.909228] ata_piix 0000:00:1f.5: setting latency timer to 64                                                
[    0.909279] scsi2 : ata_piix                                                                                  
[    0.909326] scsi3 : ata_piix                                                                                  
[    0.910021] ata3: SATA max UDMA/133 cmd 0xb000 ctl 0xac00 bmdma 0xa480 irq 19                       

파티션의 오프셋을 확인하십시오. 4096 기술을 사용하므로 EARS의 경우 4로 나눌 수 있어야합니다. 그렇지 않으면 정렬 및 성능 문제를 해결하기 위해 파티션을 다시 분할해야합니다 (오정렬 된 EARS 드라이브는 op 당 더 많은 섹터 쓰기를 수행함).

많은 디스크 IO를 수행 할 때 비슷한 동결 문제가있었습니다. 백업하는 동안 백업이 완료 될 때까지 데스크톱이 몇 초 동안 정지되었습니다.

정렬이나 hdparm 조정과 관련이 없습니다 (도움이 될 것이라고 동의하지만).

시스템 잠금은 IO 스케줄러에 의해 야기되었는데, 이는 더 많은 대화 형 응용 프로그램 (Firefox, KDE 또는 기타)에 필요한 너무 많은 IO를 지연시킵니다. 결함이있는 IO 스케줄러는 cfg 입니다.

이 문제를 해결하려면 최종 기한 IO 스케줄러를 사용해야합니다. /etc/rc.local에 추가 할 수있는 다음 명령을 사용하여 디스크에서 활성화합니다 .

echo deadline >  /sys/block/sda/queue/scheduler

자세한 정보 는 집중 디스크 I / O가 수행 될 때 Linux 시스템 잠금 해결을 확인 하십시오.

그것은 어두운 곳에서 촬영되었지만 얼마 전에 이와 같은 문제가 있었으며 그 원인은 커널이 칩셋을 완전히 지원하지 않고 DMA가 꺼 졌기 때문입니다. 확인

hdparm -i /dev/sda

DMA 모드 중 하나가 활성화되어 있는지 여부

(이 경우 해결책은 최신 커널을 얻는 것입니다.)

많은 fsync (2) 호출을 수행하는 작업으로 인해 시스템이 크게 느려지는 문제가 발생했습니다. 제 경우에는 LUKS에 포함 된 LVM에 포함 된 루트 파티션으로 실행 중입니다. LVM 또는 LUKS를 사용하고 있습니까?

"패키지 설치"가 아니라 디스크를 씹고있는 것을 정확히 찾아내는 데 도움이되는 도구를라고 iotop합니다. 이러한 작업 중 하나를 수행하는 동안 실행하는 것이 좋습니다. 동시에 트리거되고 모든 I / O 처리량을 빨아들이는 다른 백그라운드 프로세스가 지적 될 수 있습니다.

sudo fdisk -u / dev / sda

시작 오프셋이 표시됩니다. fdisk -o 64 또는 무언가를 사용하여 파티션을 만들 수 있다고 생각합니다 .Google은 fdisk에서 인터넷 검색을 수행하고 수동으로 파티션 오프셋을 설정하도록 허용해야합니다 (기본값은 63이므로 좋지 않습니다).

그리고 예 디스크는 OS와 같은 척하는 것처럼 512b 섹터로 표시됩니다-Vista / W7은 올바른 오프셋을 설정하여이를 처리하지만 XP와 나는 모든 linus 배포판이 거의 없다고 생각합니다. (광산은 단지 저장 장치 드라이브이며 win7 / ntfs에서 만들어 지므로 아무런 문제가 없습니다)

편집 :-wdc에서 좋은 게시물을 찾았습니다-이것은 당신을 즉시 실행시켜야합니다 :)

http://community.wdc.com/t5/Desktop/Problem-with-WD-Advanced-Format-drive-in-LINUX-WD15EARS/mp/10920#M631

임의의 샷, 데비안을 사용한다는 점에서 어리석은 것처럼 보이지만 같은 HDD 모델을 가진 사람에게 도움이된다는 것을 알았습니다 .BIOS를 업데이트하려고 했습니까?

일반적으로 장치에서 hdparm을 사용할 수있는 경우 "이전"ATA 인터페이스와 최신 SATA / SCSI 인터페이스가 있습니다. 이 경우 인터럽트 중 디스크 작동이 기본적으로 활성화되어 있지 않은 것입니다. 이는 이전 ATA 인터페이스를 사용하는 일부 시스템에서 일반적인 문제이며 과도한 I / O 작업 중 디스크 또는 시스템의 성능을 저하시킵니다.

당신은 정말로 이것을 시도해야합니다 :

sudo hdparm -t -T /dev/sda
sudo hdparm -a8 -c3 -u1 /dev/sda
sudo hdparm -t -T /dev/sda

두 번째 타이밍 실행 (세 번째 명령)에서 성능이 향상되지 않으면 다른 문제가 발생하는 것입니다.

또 다른 요소는 UDMA6 모드가 비 UDMA 케이블을 통해 작동 할 것으로 예상합니다 (SATA 인터페이스가 아니라고 가정). 80 핀 ATA 케이블을 사용하고 있다면 괜찮습니다. 구형 40 핀을 사용하는 경우 모든 종류의 슬픔이 생깁니다. 케이블이 구형 40 핀인 경우 전송 속도를 "안전하게"지원할 수있는 수준으로 낮추어야합니다. 경고 : IDE 인터페이스를 조정하면 드라이브 및 / 또는 인터페이스가 중단 될 수 있으며 드라이브가 루트 파일 시스템 인 경우 전체 시스템이 중단됩니다!

하드웨어와 일치하도록 전송 속도를 낮추어야하는 경우 다음을 시도하십시오.

sudo hdparm -t -T /dev/sda
sudo sync; sleep 3 ; sync    
sudo hdparm -d 1 -X mdma2 /dev/sda
sudo hdparm -t -T /dev/sda

다시, 두 번째 타이밍 (세 번째 명령 발행)은 개선을 보여 주어야합니다.

마지막으로 드라이브 자체는 한계가 있지만 SMART보고가 없으면 문제가 발생하지 않을 수 있습니다 (너무 늦을 때까지). smartmontools특히 약간의 TLC가 필요한 구형 드라이브가있는 경우 특히 도움이 되도록 패키지를 설치하는 것이 좋습니다 .

sudo apt-get update && apt-get install smartmontools

다른 모든 방법이 실패하면 /var/log/messages디스크 I / O 오류를 찾으십시오 .

최신 정보:

당신이 혼자가 아닌 것 같습니다. 인터넷에는 온갖 종류의 상심을보고하는 게시판이 있습니다.

• http://community.wdc.com/t5/Desktop/WDC-WD15EARS-00Z5B1-awful-performance/mp/5242
• http://www.readynas.com/forum/viewtopic.php?f=21&t=40279
• http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg33347.html

4k 섹터 크기와 "전통적인"512 바이트 크기를 사용하는 드라이브에 대한 언급도 있습니다. 나는 이것이 어떤 종류의 문제를 일으키는 지 상상할 수 있습니다.

마지막으로, 결과를 다시 보면 저널링 스레드가 시스템을 거의 묶고있는 것으로 보입니다. 저널링되지 않은 파일 시스템은 일시적으로 문제를 완화시킬 수 있지만 최선의 예방책이며 최악의 경우 문제를 해결하지는 않습니다.

이것은 마침내 수정되었습니다! @Rachel이 지적했듯이 문제는 실제로 4kb 섹터와 일치하는 것이었지만 불행히도 연결된 기사는 잘못되었습니다.

파티션을 정렬하는 올바른 방법은 다음과 같습니다. http://www.linuxconfig.org/linux-wd-ears-advanced-format

그리고이 기사는 파티션 테이블이 올바른지 확인할 수 있도록 아주 좋은 벤치 마크를 제공합니다 .http : //article.gmane.org/gmane.linux.utilities.util-linux-ng/2955

참고로,이 드라이브가 있고 Linux를 사용하는 경우 여기에 설명 된대로 유휴 타이머 중 하나를 늘려야합니다. http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp .PHP? p_faqid = 5357 & p_created = 1,266,947,046 및 p_sid = Os7DQL2k 및 p_accessibility = 0 p_redirect = p_srch = 1 p_lva = P_SP = cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9NTEsNTEmcF9wcm9kcz0yMjcsMjk0JnBfY2F0cz0xMzAmcF9wdj0yLjI5NCZwX2N2PTEuMTMwJnBfcGFnZT0x 및 p_li = p_topview = 1