Acabei de instalar o teste Debian na minha nova área de trabalho e não estou muito feliz com o desempenho - quando executo uma operação intensiva de disco, por exemplo, pacotes de atualização no sistema, tudo parece congelar, por ex. mudar de abas no Iceweasel leva 3 segundos. Eu corro o Debian no meu Thinkpad X60 de 3 anos ultra-portátil, e eu não tenho esses problemas. (cada único parâmetro do laptop é muito pior que o desktop).
Estou usando o kernel e os scripts empacotados padrão.
eu corro
hdparm -t /dev/sda1
E eu tenho cerca de 96GB / s, o que é esperado. O que mais posso tentar fazer com que funcione melhor?
EDITAR :
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 : Até minha esposa disse "neste novo computador eu não posso fazer nada quando copio as fotos da câmera e é muito pior do que no antigo". Então deve ser sério.
EDIT3 : Atualizado para 2.6.32, mas ainda sem melhorias
EDIT4 : esqueci de mencionar que o novo disco é ext4, o antigo era ext3.
EDIT5 : ainda não resolvido. Eu tenho uma placa P43 ASUS P5QL-E. Linhas do dmesg que parecem relevantes:
[ 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
Isso está finalmente resolvido! Como apontou @Rachel, o problema de fato foi com o alinhamento aos setores de 4kb, mas infelizmente o artigo ligado estava incorreto: (
A maneira correta de alinhar as partições é aqui: link
E este artigo fornece uma boa referência para que você possa verificar se a tabela de partições está correta: link
Em uma nota lateral, se você tiver esta unidade e usar o Linux, você também DEVE aumentar um dos temporizadores ociosos como descrito aqui: link
Verifique o deslocamento da partição - precisa ser divisível por 4 para EARS, pois eles têm a tecnologia 4096. Se não for - reparticioná-lo para obter o alinhamento e os problemas de desempenho devem desaparecer (as unidades EARS desalinhadas farão muito mais gravações setoriais por op).
Eu tive um problema semelhante de congelamento ao fazer vários IOs de disco. Durante um backup, a área de trabalho ficou congelada por alguns segundos várias vezes até que o backup fosse concluído.
Não foi relacionado a nenhum alinhamento nem a qualquer ajuste do hdparm (embora eu concorde que ajudará).
O bloqueio do sistema foi causado pelo agendador de IO, o que atrasa muitos IOs exigidos por aplicativos mais interativos (Firefox, KDE ou qualquer outro). O agendador de IO com falha estava cfg .
Para resolver o problema, você precisa usar o agendador de IO de prazo. Você o ativa em um disco com o seguinte comando que você pode adicionar em /etc/rc.local :
echo deadline > /sys/block/sda/queue/scheduler
Verifique Resolvendo o travamento do sistema Linux quando a E / S de disco intensiva é executada para obter mais informações.
É um tiro no escuro, mas eu tive um problema assim há um tempo atrás, e a causa acabou sendo que o kernel não suportou completamente o chipset e o DMA foi desligado. Verifique com
hdparm -i /dev/sda
se um dos modos de DMA está ativado.
(A solução nesse caso era obter um novo kernel.)
Eu tive problemas onde as operações que realizam muitas chamadas fsync (2) causam uma grande lentidão no sistema. No meu caso, estou executando com minha partição raiz contida no LVM contido no LUKS. Você está usando LVM ou LUKS?
Uma ferramenta que pode ajudar a identificar o que especificamente está mastigando seus discos (em vez de apenas "instalar pacotes") é chamada de iotop . Eu sugiro executá-lo enquanto você executa uma dessas tarefas, e isso pode indicar algum outro processo em segundo plano que pode estar sendo acionado ao mesmo tempo e sugando toda a sua taxa de transferência de E / S.
sudo fdisk -u / dev / sda
Isso deve fornecer o deslocamento inicial. Eu 'acho' que você pode criar a partição usando fdisk -o 64 ou algo assim - eu teria que pesquisar no Google, então vou deixar você fazer o googling no fdisk e manualmente configurar o offset da partição (o padrão é 63, o que não é bom). p>
e sim o disco mostrará com 512b setores como ele pretende ser como tal para o sistema operacional - Vista / W7 lidar com isso, definindo o deslocamento correto, mas XP e acho que perto de todas as distribuições linus não :( manualmente é o único da maneira que parece (a minha é apenas uma unidade de armazenamento e criada no win7 / ntfs, então não há problema para mim)
Editar: - Encontrei um bom post no wdc - isso deve colocá-lo em funcionamento em pouco tempo :)
Apenas uma foto aleatória, o que parece estúpido, dado que você usa o Debian ... mas descobri que isso ajudou alguém com o mesmo modelo de HDD: você tentou atualizar sua BIOS?
Como regra geral, se você pode usar o hdparm no dispositivo, é a interface ATA "antiga", em comparação com a interface SATA / SCSI mais recente. Se for esse o caso, o problema é provavelmente que as operações de disco durante as interrupções não estão ativadas por padrão. Este é um problema comum em algumas máquinas usando a interface ATA mais antiga e degradará o desempenho do disco ou do sistema durante operações pesadas de E / S.
Você realmente deveria tentar isso:
sudo hdparm -t -T /dev/sda
sudo hdparm -a8 -c3 -u1 /dev/sda
sudo hdparm -t -T /dev/sda
Se você não vê uma melhora no desempenho na segunda execução de tempo (o terceiro comando), então há algo mais acontecendo.
Outro fator é esperar que o modo UDMA6 trabalhe em um cabo não-UDMA (supondo que não seja uma interface SATA). Se você estiver usando um cabo ATA de 80 pinos, tudo bem; Se você estiver usando um mais antigo de 40 pinos, você terá todos os tipos de tristeza. Se o cabo for o mais antigo de 40 pinos, você precisará reduzir a taxa de transferência para algo que possa ser suportado "com segurança". ATENÇÃO: ajustar a interface IDE pode travar a unidade e / ou a interface, e se a unidade for o seu sistema de arquivos raiz, todo o sistema irá travar com ela!
Se você precisar diminuir a taxa de transferência para corresponder ao hardware, tente o seguinte:
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
Novamente, o segundo momento (terceiro comando emitido) deve mostrar uma melhoria.
Por fim, a própria unidade pode ser marginal, mas sem o relatório da SMART, talvez você não perceba o problema (até que seja tarde demais). Eu realmente recomendaria instalar o pacote smartmontools para ajudá-lo, especialmente se você tiver uma unidade mais antiga que precisará de um pouco de TLC de vez em quando.
sudo apt-get update && apt-get install smartmontools
SE tudo falhar, procure em /var/log/messages por erros de E / S no disco.
Atualização:
Parece que você não está sozinho. Há quadros de mensagens em todo o 'net reportando todos os tipos de mágoa com essas unidades.
Também há menção à unidade usando um tamanho de setor de 4k vs. o tamanho de 512 bytes "tradicional". Eu só posso imaginar que tipo de problema isso deve estar causando.
Por último, olhando para a sua saída novamente, parece que o segmento de registro no diário está praticamente amarrando o sistema. Um sistema de arquivos não com diário pode aliviar temporariamente o problema, mas é profilático na melhor das hipóteses e não corrige o problema na pior das hipóteses.
Tags performance hard-drive debian linux