MikeKulls's questions

Temos 8 servidores Cisco com 12 discos giratórios para dados e 2 SSDs para sistema operacional. Os 2 SSDs estão no software Linux RAID 1. Todos os SSDs têm seu indicador de desgaste em um dígito e alguns daqueles que atingiram o valor 1 falharam. Estou trocando todos eles pelas peças sobressalentes (um processo longo e cansativo), mas notei que o indicador de desgaste está caindo 1 ou 2% por semana (não fiz medições exatas). Há um único aplicativo em execução nesses servidores e o fornecedor me deu algumas ideias vagas, mas eu realmente preciso encontrar os diretórios nos quais ele está gravando. Dessa forma, posso realmente destacar o problema e pressionar o fornecedor para uma solução. Pesquisei um pouco, mas não consegui encontrar muito. iotop, por exemplo, mostra a taxa de transferência completa do disco, incluindo os 12 discos giratórios. O SO é Redhat 7.9

Em resposta a algumas das perguntas:

• os discos são "SSD SATA de 480 GB e 2,5 polegadas Enterprise Value 6 Gb"
• o ID do produto é "UCS-SD480GBKS4-EB"
• os discos foram fornecidos como padrão com os servidores em 2018
• O desgaste parece ter acelerado recentemente (agora estou registrando o desgaste, então terei uma resposta melhor sobre isso em alguns dias)
• Substituí a maioria dos discos por discos idênticos adquiridos talvez alguns anos depois.
• iotop está mostrando uma gravação constante de 8 MB/s.
• o sistema está executando o hadoop em 8 servidores. O sistema de arquivos hadoop está em discos giratórios, portanto não deve tocar nos SSDs
• Reduzi consideravelmente o IO do disco por sugestão do fornecedor, embora ainda pareça alto (8 MB/s)

Temos um servidor que executa vários aplicativos headless, como Java. Ele processa para transmitir dados, scripts python diários, etc. De tempos em tempos, alguns de nossos aplicativos ficam out of memory errors.

O problema que temos é que o monitoramento mostra que há muita memória RAM. Aumentamos de 128 GB para 192 GB e não resolveu o problema. Nosso monitoramento faz uma leitura a cada 20 segundos e mostra a memória mínima disponível de 132 GB nos últimos 2 dias. Mas alguns aplicativos falharam com erros de falta de memória esta manhã. É possível obter OOM com bastante RAM disponível?

EDIT: Resposta às perguntas de David

• sim, os 192 GB são apenas a memória RAM alocada para o sistema operacional. É uma VM
• O monitoramento lerá ram livre/disponível para o sistema operacional, não temos nenhum monitoramento por processo
• A maioria dos processos java não especifica requisitos de memória na CLI (por exemplo, Xmx, etc.)
• A exceção é "Exceção no encadeamento "principal" java.lang.OutOfMemoryError: impossível criar novo encadeamento nativo"

Eu acrescentaria que vários processos falham ao mesmo tempo. Para mim, isso indicaria que não é um problema com o processo em si, mas algo a ver com o sistema. Alguns dos aplicativos que falham fazem a mesma coisa o dia todo, todos os dias, que é processar um fluxo de dados bastante consistente. Não é como se eles pudessem ser inundados com um grande número de solicitações.

Configuramos 12 servidores redhat e os juntamos ao nosso domínio de diretório ativo do Windows. Inicialmente, usamos o redhat 7.4 e estava tudo bem, mas o fornecedor veio e nos disse que seu aplicativo suporta apenas 7.3. Então reinstalamos todos os 12 servidores como 7.3 e os conectamos ao domínio. Todos funcionando, exceto os usuários, agora obtêm UID aleatório em cada servidor. Isso não vai funcionar, pois temos um sistema de arquivos compartilhado entre os 12 servidores.

Nós configuramos isso usando sssd. A instalação foi bem fácil, acabamos de instalar alguns pacotes e executamos este comando para ingressar:

realm join --user=xxxxxx--computer-ou="ou=EpicWorkloads,ou=EPIC,dc=core,dc=dir,dc=xxxxxx,dc=com" core.dir.xxxxx.com

Em seguida, alterou algumas configurações em /etc/sssd/sssd.conf para trabalhar com um domínio grande:

ldap_idmap_default_domain = core.dir.xxxxx.com
ldap_idmap_autorid_compat = true
ldap_idmap_range_min = 200000
ldap_idmap_range_max = 2000200000
ldap_idmap_range_size = 1000000

O problema parece ser esse último valor. Em 7.4, poderíamos configurá-lo para 128.000.000. Em 7.3, ele falha se definirmos mais de 1 milhão.

Alguém sabe o que está acontecendo?

Temos uma máquina virtual executando o Windows Server 2008R2. Quando alocamos 200 GB de RAM, ele é incrivelmente estável e funciona para sempre sem problemas.

Aumentamos para 350 GB e imediatamente ficou instável. Os serviços paravam ou paravam de responder e exibiam uma tela azul após 2 dias. Ele estava rodando sob KVM e pensamos que KVM era o problema. Então, mudamos para o VMware, criamos uma nova VM a partir do modelo OVF, mas ainda temos exatamente o mesmo problema.

Eu levantei o suporte com a Cisco e eles culparam o VMWare. Quando levantei o suporte com a VMware, eles culparam a MS. Estou começando a pensar que eles estão corretos porque era o mesmo problema no KVM.

Alguém sabe de um problema com a alocação de mais de 200 GB de RAM para o Windows 2008R2?

BTW, ele está executando o SP1 no momento, mas temos alguns erros com a instalação de atualizações, portanto ainda não possui todos os patches mais recentes.

Eu tenho uma máquina rodando em KVM que não está funcionando muito bem. Tenho tentado pesquisar no Google uma maneira de determinar se uma VM está usando VT-x. Posso encontrar muitos links sobre como determinar se o seu processador suporta VT-x e se está ativado no BIOS, mas como posso verificar se minha VM o está usando? O servidor suporta vtx e está ativado.

Resultado do ps machado | grep kvm

2039 ? S 0:00 [kvm-irqfd-clean] 21158 ? Sl 50:43 /usr/libexec/qemu-kvm -name cws-QV1 -S -M rhel6.6.0 -cpu SandyBridge,+erms,+smep,+fsgsbase,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -enable-kvm -m 200000 -realtime mlock=off -smp 32,sockets=2,cores=16,threads=1 -uuid ea794c0c-2f56-9eae-1859-98be632e44df -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/cws-QV1.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -drive file=/kvm/cws-QV1/SAD_SOE_W2008-R2-ENT-x64.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/var/lib/libvirt/images/cws-QV1.img,if=none,id=drive-ide0-0-1,format=qcow2,cache=none -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/var/lib/libvirt/images/cws-QV1-1.img,if=none,id=drive-ide0-1-1,format=qcow2,cache=none -device ide-drive,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -netdev tap,fd=23,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:81:1e:c7,bus=pci.0,addr=0x3 -netdev tap,fd=24,id=hostnet1,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:8f:39:e5,bus=pci.0,addr=0x4 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga std -device intel-hda,id=sound0,bus=pci.0,addr=0x5 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on

Estou tentando capturar aproximadamente 20mbit/s de tráfego continuamente com o tshark. Se eu capturar pacotes com tshark no CentOS 6.5, recebo cerca de 4% a 66% de pacotes descartados. Se eu fizer a mesma coisa no CentOS 7, ele nunca relatará nenhum pacote descartado. Na verdade, tentei fazer com que ele descartasse pacotes fazendo coisas malucas, como enviar grandes quantidades de tráfego para xml. Tanto quanto eu posso dizer, não está perdendo pacotes. Minha pergunta é: o CentOS 7 possui algum tipo de recurso que impossibilita a eliminação de pacotes? Ou está descartando pacotes e não me avisando?

Como exemplo, executo comandos como este:

tshark -i ens224 -c 100000 -w /tmp/delme.pcap
tshark -i ens224 -c 100000 -T pdml > /tmp/delme.pcap

Para o primeiro comando, o CentOS 6 relata 4% de pacotes descartados, o CentOS 7 não relata nenhum. Para o segundo comando, o CentOS relata 66% de pacotes descartados, mas o CentOS 7 não relata nenhum.

Observe que ambas as máquinas estão executando o tshark 1.12.7 compilado a partir do código-fonte.

Estamos fazendo uma captura de pacotes de dentro do nosso software de teste usando a linha de comando:

tshark -V -i vlan2091 -R "bootp.hw.mac_addr contains "00:17:33:00:00:00""

O problema que temos é que uma das opções de DHCP é exibida em hexadecimal e abreviada. Existe uma maneira de parar de cortar a saída? Embora hexadecimal esteja OK, existe uma maneira de exibi-lo em ASCII?

Option: (t=82,l=50) Agent Information Option Option: (82) Agent Information Option Length: 50 Value: 0130535443335F332D4E32354B2D31324D2D51312D535542... Agent Circuit ID: 535443335F332D4E32354B2D31324D2D51312D5355424142... End Option

No Windows Server 2003 R2 64 bits SP2, tenho um aplicativo que usará apenas a porta 8080, mas algo já está usando. Eu ficaria feliz em matar o que quer que esteja usando, mas não consigo descobrir o que é. Executei o TCPView e ele mostrou um PID de 3216 com um processo de "". Eu tentei taskkill /pid 3216, mas diz:

ERRO: O processo "3216" não foi encontrado."

Se eu navegar para http://127.0.0.1:8080, obtenho um dos erros abaixo, então parece um pouco com algum tipo de servidor da web. Se eu tentar matar o processo no TCPView, nada acontece. Alguém pode fazer outras sugestões?

Proibido. Você não tem permissão para acessar / neste servidor.

Erro do Servidor Interno. O servidor encontrou um erro interno ou configuração incorreta e não pôde concluir sua solicitação. Entre em contato com o administrador do servidor, [email protected] e informe a hora em que o erro ocorreu e qualquer coisa que você possa ter feito que possa ter causado o erro. Mais informações sobre esse erro podem estar disponíveis no log de erros do servidor.