Estou produzindo dados (arquivos de 100GB) que finalmente são copiados para um servidor através do NFS v4.2, em uma rede de 10Gb. Esses arquivos são armazenados em vários HDDs, com formatação XFS (uma cópia por unidade de destino).
Quando as tarefas de cópia estão em execução:
- Há um enorme uso de memória no cliente(pode ter mais de 64 GB, ocupa o máximo de memória possível).
- Mas quase nenhuma memória RAM é usada no servidor.
Gostaria de reduzir o uso de memória nos clientes, pois eles produzem dados continuamente e isso os torna mais lentos. Pelo contrário, o servidor praticamente não é utilizado.
Acho que como o HDD fica lento no servidor, o cliente armazena em buffer o máximo de dados possível para tornar a cópia menos bloqueada. Não consigo alterar a configuração do hardware.
Existe alguma maneira de forçar o servidor a armazenar mais dados em cache? Eu preferiria priorizar o uso da memória do servidor em vez da memória do cliente.
A configuração do NFS:
10.0.3.1:/ /mnt/field nfs nfsvers=4.2,noatime,nodiratime,_netdev,noauto,x-systemd.automount,x-systemd.mount-timeout=10 0 0
/etc/exports:
/mnt 10.0.0.0/16(rw,async,fsid=0,no_subtree_check,crossmnt)
Configuração de NIC no servidor:
MTU 9000
rinbuffer tx 512, rx 1024
Configuração Nic no cliente:
MTU 9000
rinbuffer tx 1024, rx 512
Editar: Conforme solicitado, /proc/meminfo:
Servidor cliente ------ -------------------------
Um monitor do uso de memória neste cliente:
Uso da rede:
Nota: O cliente usa um grande tmpfs (100 GB) para calcular. Acho que esse tmpfs nunca é subtraído da contagem de memória disponível.
Editar2:
A correlação entre uso de rede e memória é mais óbvia no outro cliente (eu deveria ter começado com isso). Este cliente não usa nenhum tmpfs.
Responder1
Gostaria de reduzir o uso de memória nos clientes, pois eles produzem dados continuamente e isso os torna mais lentos.
Como você sabe disso? A maior parte da memória do cliente está no cache de páginas, o que é totalmente normal e mesmo melhorar o buffer no servidor não impedirá o cache agressivo desses dados do lado do cliente.
Você já tentou liberar o cache da página (como teste) e ver o desempenho do seu aplicativo sem o uso do cache da página?
O NFS tem o que é conhecido como consistência 'fechar para abrir', o que significa que o conteúdo dos dados e metadados só é realmente garantido como estável quando você não tem o arquivo aberto ativamente (ou seja, outro cliente pode alterar o arquivo em outro sistema e você não saberia).
Devido a essa limitação de consistência, o cache de página é utilizado pelos aplicativos de sistemas clientes NFS para garantir que os dados estejam disponíveis para leitura caso seja necessário.
Tudo o que foi dito, sem saber o que está acontecendo em seu /etc/exportsúnico método para descarregar mais dados no servidor, pode ser garantir a montagem do NFS em seus clientes com a syncopção de montagem e no seu servidor exportar os caminhos com a asyncopção de montagem.
Isto terá o efeito de garantir que as gravações sejam confirmadas no servidor do lado do cliente, enquanto o servidor sempre responderá 'concluído' antes de enviar os dados para o disco.
Isso afetará o rendimento dos clientes, pois você causará latência devido à validação de todas as solicitações no lado do cliente, mas o servidor armazenará em buffer muito mais dados, pois não esperará que os dados cheguem primeiro ao disco. Você provavelmente também desejaria mexer em dirty_write_centisecsoutros bits no servidor para permitir que ele armazene mais dados em write-back.
Mas aqui está o problema - isso provavelmente fará com que os clientes fiquem lentos e reduza a integridade dos servidores em caso de falha. Se o servidor travar, você poderá perder dados.
Além disso, isso não afetará o uso de memória para cache de página nos clientes sobre os quais o NFS não tem controle real.
Resumindo, sou cético que a redução do uso de memória dos clientes (se for o cache da página que você está medindo aqui) melhorará o desempenho dos seus clientes.
Responder2
Não, forçar o uso de menos memória provavelmente tornará as coisas mais lentas, e não mais rápidas. Você já está gastando energia com 188 GB de DRAM rápida, é melhor usá-la.
O host do cliente tem 188 GB de MemTotal e está usando 162 GB dele para cache. Na verdade, as demandas de memória são bastante baixas, observe 123 GB MemAvailable que pode ser liberado muito rapidamente. A maior parte dos 40 GB do Shmem são provavelmente tmpfs.
Como Cached + Shmem soma mais do que MemTotal, suspeito que tmpfs esteja sendo contado duas vezes, como memória compartilhada e em caches. Também explicaria como o cache menos Shmem é aproximadamente MemAvailable, os tmpfs sem armazenamento persistente não podem ser liberados.
Lado do servidor, 15 GB e alteração MemTotal, 13 GB em cache. Muita memória disponível neste host. Presumivelmente, a maior parte do que ele faz serve a arquivos, e não a muitas outras demandas de memória.
Sem evidência de sobrecarga, comoatividade vmscan pesadaou com pouco MemAvailable, não recomendo tomar medidas.