ALZ's questions

Estou enfrentando uma queda significativa de desempenho ao usar o "rsync" para copiar arquivos pela rede de dentro de um contêiner ou cgroup com limites de memória no Oracle Linux 9.2. O problema ocorre com o Red Hat Compatible Kernel (RHCK) 5.14.0-284.11.1.el9_2.x86_64, mas não com o Unbreakable Enterprise Kernel (UEK) 5.15.0-101.103.2.1.el9uek.x86_64.

Detalhes: Configuração: Oracle Linux 9.2 com contêineres/cgroups com limites de memória. Problema: A velocidade de cópia de arquivos pela rede cai drasticamente quando os limites de memória são atingidos, especialmente quando o cache de páginas (arquivos inativos) fica cheio. Testes:

• Usando "rsync" de dentro de um contêiner ou um cgroup para copiar dados de uma fonte remota.
• Utilizando a replicação de dados PostgreSQL "pg_basebackup" entre dois contêineres PG (Líder vs. Réplica). Resultados:
• As altas velocidades iniciais (~100 MBps) caem significativamente (para ~1 MBps) quando os limites de memória são atingidos.

Comandos para reproduzir:

1. Crie um cgroup com limite de memória e execute o rsync: sudo systemd-run --scope --property=MemoryMax=1G rsync -av --progress rsync://<source_ip>/files /destination_path

2. Teste com drop_caches no sistema operacional de hospedagem durante rsync lento: free && sync && echo 3 > /proc/sys/vm/drop_caches && free Após o cache ser descartado, o rsync fica rápido novamente até que o limite de MEM seja atingido novamente

Observações:

• Quando o limite de memória do contêiner é atingido, o cache de páginas (arquivos inativos) fica cheio, levando à degradação da largura de banda da rede.
• Isso afeta, por exemplo, a replicação do PostgreSQL, causando atraso e potencial perda de dados.

Alguém mais já passou por esse problema? Quaisquer dicas ou sugestões sobre como lidar com isso corretamente (ou talvez soluções alternativas) seriam muito apreciadas!

Eu preciso exibir na GUI para a memória usada pelo operador vs disponível no Linux Server

Então, qual seria o valor logicamente correto para exibir como uso?

[root@host ~]# free
              total        used        free      shared  buff/cache   available
Mem:      131753676   110324960     1433296     4182648    19995420    16240640
Swap:       2097148      652076     1445072

usedou ( total- available)?

A diferença é: 110324960 vs 115513036 ou 5188076 kb ~= ~5 GB Então o que há com esses 5 GB eles são efetivamente usados ​​ou disponíveis ou indisponíveis e nem usados? O que é mais correto exibir para usado no uso de memória %?

Isto é para CentOS 7.3 PC, executando 2 serviços java

Mas há uma imagem totalmente diferente no PostgreSQL Server

[root@postgres_server1 ~]# free
              total        used        free      shared  buff/cache   available
Mem:      131753684     7364056    77736740    15598120    46652888   107942020
Swap:       2097148           0     2097148

onde a diferença entre usede ( total- available) é muito maior: 16447608 kb ~=15,7 GB

Eu tenho um processo, shell. Sua máscara de afinidade é 1 (eu tenho 3 CPUs) Na máquina redundante (quase espelhada - são 7 - TODAS as CPUs) Quem está decidindo qual máscara definir ou onde ela será configurada?

[root@h1-nms ~]# ps $$
  PID TTY      STAT   TIME COMMAND
 7605 pts/2    Ss     0:00 -bash
[root@h1-nms ~]# taskset -p $$
pid 7605's current affinity mask: 1

Aqui está a saída de nprocvs nproc --alle outro comando encontrado na internet. Eu ainda não consigo entender o porquê. É uma VM QEMU\KVM com CentOS 6.5 rodando sob outro CentOS 6.5.

Abaixo estão as saídas de alguns outros comandos:

[root@h1-nms ~]# nproc
1
[root@h1-nms ~]# nproc --all
3
[root@h1-nms ~]# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                3
On-line CPU(s) list:   0-2
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             3
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 13
Stepping:              3
CPU MHz:               2194.710
BogoMIPS:              4389.42
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              4096K
NUMA node0 CPU(s):     0-2
[root@h1-nms ~]# getconf _NPROCESSORS_ONLN
3
[root@h1-nms ~]# cat /proc/$$/limits
Limit                     Soft Limit           Hard Limit           Units
Max cpu time              unlimited            unlimited            seconds
Max file size             unlimited            unlimited            bytes
Max data size             unlimited            unlimited            bytes
Max stack size            10485760             unlimited            bytes
Max core file size        unlimited            unlimited            bytes
Max resident set          unlimited            unlimited            bytes
Max processes             32000                32000                processes
Max open files            64000                64000                files
Max locked memory         65536000             65536000             bytes
Max address space         unlimited            unlimited            bytes
Max file locks            unlimited            unlimited            locks
Max pending signals       191509               191509               signals
Max msgqueue size         819200               819200               bytes
Max nice priority         0                    0
Max realtime priority     0                    0
Max realtime timeout      unlimited            unlimited            us
[root@h1-nms ~]# grep "" /sys/devices/system/cpu/cpu*/online
/sys/devices/system/cpu/cpu1/online:1
/sys/devices/system/cpu/cpu2/online:1
[root@h1-nms ~]# uname -a
Linux h1-nms 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[root@h1-nms ~]# cat /etc/*-release
CentOS release 6.5 (Final)
CentOS release 6.5 (Final)
CentOS release 6.5 (Final)
[root@h1-nms ~]#