Fórum Ubuntu Linux - PT
Suporte Técnico => Internet, Redes e Segurança => Tópico iniciado por: g4p em 08 de Junho de 2015, 15:26
-
Olá, olha eu mais uma vez!
Aqui na rede da empresa todas as placas de rede das estações, servidores, switch, roteadores são Gigabit. Até sexta-feira estava normal a velocidade. Hoje, o pessoal começou a se queixar de estar lento, quando fui verificar, realmente estava bem lento, transferindo à 8~11mb/s. Há algum motivo pra ter acontecido isso, absolutamente do nada? o.O
-
Primeira coisa a verificar é se todo mundo está realmente conectando em modo gigabit. Nas estações windows [7 em diante], vc verifica isso nas propriedades da conexão local. No servidor linux, vc verifica isso com o "sudo ethtool ethX".
Depois, verifique se não há tráfego anormal em sua rede. Verifique as estatísticas de tráfego das interfaces, em particular a taxa de broadcasts, que se estiver muito alta pode ser indício de um loop de comutação --- tempestade de broadcasts. Um sistema de gerência, tipo NMIS ou NAGIOS pode te ajudar nessa tarefa.
-
Uma das máquinas tem a placa de rede gigabit, porém não trabalha em 1000Base-T, bem estranho. Ela pode está prejudicando as outras?
-
Olha a interface do servidor:
[editora@editora]\ [~] $ ifconfig
em1 Link encap:Ethernet HWaddr 80:c1:6e:a7:a6:20
inet addr:192.168.100.120 Bcast:192.168.100.255 Mask:255.255.255.0
inet6 addr: fe80::82c1:6eff:fea7:a620/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1175884242 errors:0 dropped:0 overruns:0 frame:0
TX packets:675632985 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1548101337337 (1.5 também) TX bytes:625319964012 (625.3 GB)
Interrupt:16
-
Uma das máquinas tem a placa de rede gigabit, porém não trabalha em 1000Base-T, bem estranho. Ela pode está prejudicando as outras?
1000BaseT (gigabit em CAT6) ou 1000BaseTX (gigabit em CAT5E)? Isso explicaria o pq dessa máquina estar lenta, principalmente se for um servidor, mas não faria todas ficarem lentas (a menos que seja o servidor, e todo mundo depender dela pra trabalhar, é claro).
Essa máquina está ligada a um switch gigabit?
Seus switches são gerenciáveis?
-
Todas as máquinas aqui são ligadas a switch gigabit e os cabos são CAT6.
Ontem tava fazendo um backup de 3TB de um outro servidor local pra esse com rsync.
Pode ser isso?
-
Se o rsync ainda estiver rodando, pode ser sim. Ainda está?
-
Não está não. Estranho demais, até sexta-feira estava tranquilo.
O que aconteceu de lá pra cá foi o seguinte:
Sábado fui a empresa, tirei um HD que estava ruim (badblock) e adicionei mais 2. Nisso, formatei usando GPT e em ext4 os 2. E já deixei fazendo backup de um outro servidor pra esses 2 HDs.
No entanto, não estão sendo nesses HDs que o pessoal notou e eu verifiquei lentidão.
-
Hoje reiniciei o roteador, switch, troquei as portas dos cabos de rede do servidor e nada de resolver..
Decidi agora pouco, na hora do almoço, reiniciar o servidor e problema resolvido! PORÉM, agora quando o pessoal voltou a trabalhar.. a transferência caiu novamente pra 8~9mb/s.
O que pode ser? o.O
-
Como está o uso de memória do seu servidor?
-
Esta bem tranquilo.
http://postimg.org/image/5fykh3r41/
-
Tem certeza? Eu vi uns 10 processos java, cada um consumindo 10% da memória. De onde eu vim, 10x10% = 100%...
Tem C E R T E Z A de que sua máquina não está fazendo swap?
-
Isso é o openfire, geralmente pessoal troca arquivos por ele.
Talvez pode ser isso?
-
Se estiver tomando toda a memória do servidor, e ele estiver fazendo swap, com certeza vai deixar a máquina [muito] mais lenta.
Confirma pra gente lá:
free -m
Se o total usado do swap estiver acima de 0, vc tem que parar e verificar quem está consumindo, e porquê.
Aliás, processos java podem ser grandes glutões de memória. Por sorte vc pode controlar tanto a quantidade de processos, quanto o total de memória que cada um pode consumir.
-
Até que não..
total used free shared buffers cached
Mem: 3910 3647 263 0 535 2293
-/+ buffers/cache: 817 3092
Swap: 4059 79 3980
De ontem pra hoje já normalizou, do nada. Até agora não entendi porque causou essa lentidão.
-
Se ocorrer de novo, olhe nesse comando, se a linha/coluna "Swap/Used" está com valor alto.
-
Aconteceu de novo e o servidor não está com o swap alto.
Swap: 4059 95 3964
Que estranho..
-
Observações adicionais e úteis:
Testei a transferência em outro HD, que está sendo compartilhado no mesmo servidor e a taxa de transferência está ótima! Passando os 100mb/s.
Comecei a desconfiar do HD em si, mas é estranho.. Isso começou depois que adicionei 2 HDs no servidor esse final de semana. Apenas isso!
O fato de serem modelos diferentes pode interferir? Não, né?
Todos nosso HD trabalham em 7200RPM.
-
O fato de serem modelos diferentes pode interferir? Não, né?
Só se estivessem em RAID. Estão?
-
- Já descartei ser problema de rede, visto que um outro HD compartilhado no Samba do mesmo servidor alcança 100mbps.
Vou verificar agora se o problema está no Samba ou no HD, fazendo os seguintes testes:
- Instalar um server de FTP e transferir localmente de alguma estação. Se bater os 100mbps, podemos considerar que o problema está no samba, caso continue bem baixa (10mbps aproximadamente) concluímos que o HD está querendo morrer.
Fiz alguns testes com o hdparm:
O HD que está com a taxa lenta no Samba (e me parece que não só no Samba)
[editora@editora]\ [/var/log/samba] $ sudo hdparm -Tt /dev/sdc
/dev/sdc:
Timing cached reads: 18880 MB in 2.00 seconds = 9447.25 MB/sec
Timing buffered disk reads: 20 MB in 3.12 seconds = 6.40 MB/sec
O HD que testei no mesmo servidor e alcançou 100mb/s:
[editora@editora]\ [/var/log/samba] $ sudo hdparm -Tt /dev/sdb1
[sudo] password for editora:
/dev/sdb1:
Timing cached reads: 25170 MB in 2.00 seconds = 12597.93 MB/sec
Timing buffered disk reads: 480 MB in 3.00 seconds = 159.91 MB/sec
-
g4p, a saída do comando hdparm indica que esse HD está pra lá de Bagdá! Fez o teste com o smart? Tenha o smartmontools instalado e depois testa aí né! Faz o teste curto primeiro, se tiver baleado vai mostrar logo.
Como usuário root:
smartctl -t short /dev/dispositivo
Aguarde 3 minutos e depois execute:
smartctl -H /dev/dispositivo
Para saber se ele passou no teste.
Se quiser resultados detalhados:
smartctl -l selftest /dev/dispositivo
smartctl -a /dev/dispositivo
Você não respondeu a pergunta do zekkerj. Está em RAID?
-
Respondendo a pergunta do zekkerj: não esta em raid.
Vamos lá.. Fiz o seguinte teste agora:
- Transferi via SCP de uma máquina para o servidor no diretório que está montado o HD e alcançou os 100mbps. Ou seja, podemos descartar problemas no HD?
PORÉM, no teste com o hdparm ele retorna, drasticamente, diferente, como mostrei no quote anterior.
Perguntas que ficou no ar:
- Por que na transferência via SCP ele envio com uma taxa de transferência NORMAL, igual os outros HDs, enquanto no teste com hdparm ele mostra aquela diferença drástica?
- Pensei na possibilidade de ser problema realmente da configuração do Samba. Mas, e o teste do hdparm, que ele indica essa diferença em relação ao outro HD?
Que mistério! :\
-
ATUALIZAÇÕES
1) Ontem quando disse que a transferência para o diretório onde esse HD está montado via FTP foi NORMAL, estava enganado. Foi devido ao HD ter voltado a trabalhar normalmente (ele está assim)
2) Como dito a cima. Há momentos que o HD volta ao normal sozinho e passa a trabalhar normalmente, mesmo o pessoal tudo trabalhando. Nesse caso a taxa de down e up para o diretório desse HD, tanto via FTP como Explorer (samba) é normal.
3) O que pode está causando essa instabilidade no HD? Uma hora ele está trabalhando bem, outra hora ele fica lento? Levando em consideração que a maior parte do tempo ele está lento em down e up.
Perguntas:
- Pode ser a quantidade de usuários trabalhando em cima deles? obs: Antes não era assim!
- Pode ser alguma máquina com problema enviando pacotes indevidos?
- Pode ser o HD fragmentado?
-
Segue o teste que o galactus pediu:
[editora@editora]\ [~] $ sudo smartctl -t short /dev/sdc
[sudo] password for editora:
smartctl 6.2 2013-04-20 r3812 [x86_64-linux-3.11.0-12-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 1 minutes for test to complete.
Test will complete after Sat Jun 13 14:43:47 2015
Use smartctl -X to abort test.
[editora@editora]\ [~] $ sudo smartctl -l selftest /dev/sdc
smartctl 6.2 2013-04-20 r3812 [x86_64-linux-3.11.0-12-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Self-test routine in progress 10% 11751 -
[editora@editora]\ [~] $ sudo smartctl -H /dev/sdc
smartctl 6.2 2013-04-20 r3812 [x86_64-linux-3.11.0-12-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
-
Olá g4p,
Parece que esse teu HD tá subindo o telhado. Programe-se para substituí-lo.
-
Olá g4p,
Parece que esse teu HD tá subindo o telhado. Programe-se para substituí-lo.
Zekkerj, faz sentido a taxa de transferência reduzi quando há varias conexões em cima dele, caso ele esteja ruim, mesmo?
Cheguei a desconfiar do HD também..
-
Programei hoje, após o expediente para trocar a entrada SATA do HD no servidor.
Caso isso não resolva, vou inseri outro HD, meter o rsync e testar.
-
Bom dia!
Olhem isso:
[editora@editora]\ [~] $ sudo hdparm -Tt /dev/sdb
[sudo] password for editora:
/dev/sdb:
Timing cached reads: 27336 MB in 2.00 seconds = 13682.93 MB/sec
Timing buffered disk reads: 546 MB in 3.00 seconds = 181.73 MB/sec
Comparem com o que eu havia mandado antes:
[editora@editora]\ [/var/log/samba] $ sudo hdparm -Tt /dev/sdc
/dev/sdc:
Timing cached reads: 18880 MB in 2.00 seconds = 9447.25 MB/sec
Timing buffered disk reads: 20 MB in 3.12 seconds = 6.40 MB/sec
Depois de testar TUDO, desde rede até desempenho do servidor: usei iperf, htop, iotop, hdparm, acompanhei o syslog, smblog, sniffei a rede pra verificar algum pacote estranho.. e nada de uma luz no final do túnel. Até.. que decidi remover o HD e trocar a entrada SATA na controladora. Nessa ocasião aproveitei pra pincelar todo o HD, inclusive os conectores, tanto do HD como da controladora. E.. quando ligo o servidor e faço o teste dou de cara com essa mudança drástica. :D
Surge a pergunta: Poeira realmente faz tanto estrago assim? Essa me surpreendeu.. o.o
Acredito que agora está tudo sobre conformes. Vou esperar o final do dia pra vê o desempenho e volto aqui pra dizer a vocês se realmente resolveu.
-
Até.. que decidi remover o HD e trocar a entrada SATA na controladora.
Você trocou a porta SATA do HD? É isso? Se foi isso o que você fez taí seu problema. Nem todas as portas SATA de uma placa mãe são nativas do Chipset! Você sestá com todas as portas ocupadas? Já tive problemas com portas SATA não nativas, o desempenho é pior, mas nunca tinha visto uma diferença tão grande assim!
-
Até.. que decidi remover o HD e trocar a entrada SATA na controladora.
Você trocou a porta SATA do HD? É isso? Se foi isso o que você fez taí seu problema. Nem todas as portas SATA de uma placa mãe são nativas do Chipset! Você sestá com todas as portas ocupadas? Já tive problemas com portas SATA não nativas, o desempenho é pior, mas nunca tinha visto uma diferença tão grande assim!
Sim, isso galactus. Mas, antes eu limpei os conectores, tanto do HD como da controladora do servidor. Descarto a possibilidade ser pelo fato da porta SATA não dispor o mesmo desempenho que outras, pois TODOS HDs agora estão trabalhando normalmente como mostro nos logs a baixo. Ah, e isso só aconteceu após ser adicionado 2 HDs na controladora, pois antes o HD ficava na mesma PORTA SATA e sempre trabalhou normal.
Como cheguei a essa conclusão?
Ta aqui o teste com hdpam do HD que foi para a tal porta SATA:
/dev/sdc:
Timing cached reads: 26462 MB in 2.00 seconds = 13245.20 MB/sec
Timing buffered disk reads: 482 MB in 3.00 seconds = 160.41 MB/sec
Restantes dos HDs:
/dev/sdb:
Timing cached reads: 26588 MB in 2.00 seconds = 13308.58 MB/sec
Timing buffered disk reads: 582 MB in 3.00 seconds = 193.78 MB/sec
/dev/sdd:
Timing cached reads: 26712 MB in 2.00 seconds = 13371.20 MB/sec
Timing buffered disk reads: 470 MB in 3.00 seconds = 156.62 MB/sec
Informações do HD:
[editora@editora]\ [~] $ sudo hdparm -i /dev/sdb
/dev/sdb:
Model=ST3000DM001-1CH166, FwRev=CC27, SerialNo=Z1F3ZPC8
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=8
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=5860533168
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: unknown setting WriteCache=disabled
Drive conforms to: Reserved: ATA/ATAPI-4,5,6,7
[editora@editora]\ [~] $ sudo hdparm -i /dev/sdc
/dev/sdc:
Model=Hitachi HDS723030ALA640, FwRev=MKAOA5C0, SerialNo=MK0301YHGWRW3A
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=56
BuffType=DualPortCache, BuffSize=unknown, MaxMultSect=16, MultSect=8
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=5860533168
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=disabled
Drive conforms to: unknown: ATA/ATAPI-2,3,4,5,6,7
[editora@editora]\ [~] $ sudo hdparm -i /dev/sdd
/dev/sdd:
Model=Hitachi HDS723030ALA640, FwRev=MKAOA5C0, SerialNo=MK0301YHGSPVDA
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=56
BuffType=DualPortCache, BuffSize=unknown, MaxMultSect=16, MultSect=8
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=5860533168
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=disabled
Drive conforms to: unknown: ATA/ATAPI-2,3,4,5,6,7
Se perceber, o que estava apresentando problemas de lentidão é o que está com melhor desempenho agora.
Bom, dou como problema resolvido e fica aí o registro para futuras consultas de quem passar pelo mesmo problemas. Obrigado pela ajuda zekkerj e galactus.
Tamos aí, abraço!