Service snmpd chama gettimeofday syscall muitas vezes

Question

Recentemente, estou enfrentando um problema com o serviço snmpd. Eu tenho uma caixa Linux rodando o CentOS 6.9, quando eu emito um snmpwalk no localhost normalmente tudo que eu obtenho é um timeout, então eu tento adicionar um valor de timeout de 10 segundos, o resultado é melhor mas ainda dolorosamente lento. Eu decidi ir mais fundo no kernel usando strace e descobri que o serviço snmpd tenta chamar gettimeofday várias vezes antes de responder à solicitação snmp. Comparando com outras caixas Linux que estão rodando Debian 8 e Centos 6.3, seu serviço snmpd não chama gettimeofday de jeito nenhum. Aqui está o resultado que eu tenho:

rpm --query centos-release
centos-release-6-9.el6.12.3.x86_64

service snmpd status
snmpd (pid  28244) is running...

strace -r -e trace=gettimeofday -p 28244
Process 28244 attached
     0.000000 gettimeofday({1516589055, 372419}, NULL) = 0
     0.000048 gettimeofday({1516589055, 372448}, NULL) = 0
     0.000015 gettimeofday({1516589055, 372463}, NULL) = 0
     0.000015 gettimeofday({1516589055, 372477}, NULL) = 0
     0.003271 gettimeofday({1516589055, 375751}, NULL) = 0

0.000013 munmap(0x7f1950abf000, 4096) = 0
     0.000086 open("/proc/sys/net/ipv6/conf/eth3/forwarding", O_RDONLY) = 11
     0.000028 fstat(11, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
     0.000015 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1950abf000
     0.000015 read(11, "0\n", 1024)     = 2
     0.000017 close(11)                 = 0
     0.000012 munmap(0x7f1950abf000, 4096) = 0
     0.000017 open("/proc/sys/net/ipv6/neigh/eth3/base_reachable_time_ms", O_RDONLY) = 11
     0.000017 fstat(11, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
     0.000013 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1950abf000
     0.000014 read(11, "30000\n", 1024) = 6
     0.000016 close(11)                 = 0
     0.000012 munmap(0x7f1950abf000, 4096) = 0
     0.000015 read(9, "", 1024)         = 0
     0.000026 close(9)                  = 0
     0.000015 munmap(0x7f1950ac0000, 4096) = 0
     0.000014 close(10)                 = 0
     0.000028 gettimeofday({1516099695, 497691}, NULL) = 0
     0.000015 gettimeofday({1516099695, 497705}, NULL) = 0
     0.000012 gettimeofday({1516099695, 497718}, NULL) = 0
     0.000016 gettimeofday({1516099695, 497734}, NULL) = 0
     0.000012 gettimeofday({1516099695, 497746}, NULL) = 0
     0.000013 gettimeofday({1516099695, 497758}, NULL) = 0

Comparando com o resultado strace do serviço snmpd em outra caixa Linux rodando o CentOS 6.3:

rpm --query centos-release
centos-release-6-3.el6.centos.9.x86_64

Process 4566 attached - interrupt to quit
     0.000000 select(10, [4 6 7 9], [], [], {1, 160003}) = 0 (Timeout)
     1.161298 open("/proc/diskstats", O_RDONLY) = 10
     0.000109 fstat(10, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
     0.000245 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6e1d035000
     0.000047 read(10, "   1       0 ram0 0 0 0 0 0 0 0 "..., 1024) = 1024
     0.000109 read(10, "0 sda 240731 163874 8048386 2853"..., 1024) = 611
     0.000061 read(10, "", 1024)        = 0
     0.000023 close(10)                 = 0
     0.000064 munmap(0x7f6e1d035000, 4096) = 0
     0.000036 open("/proc/stat", O_RDONLY) = 10
     0.000034 read(10, "cpu  3775592 27347 3516548 70619"..., 4095) = 866
     0.000056 close(10)                 = 0
     0.000028 open("/proc/vmstat", O_RDONLY) = 10
     0.000031 read(10, "nr_free_pages 75722\nnr_inactive_"..., 4095) = 1964
     0.000042 close(10)                 = 0
     0.000037 select(10, [4 6 7 9], [], [], {4, 999068}) = 0 (Timeout)
     5.003442 open("/proc/diskstats", O_RDONLY) = 10
     0.000082 fstat(10, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
     0.000034 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6e1d035000
     0.000029 read(10, "   1       0 ram0 0 0 0 0 0 0 0 "..., 1024) = 1024
     0.000126 read(10, "0 sda 240731 163874 8048386 2853"..., 1024) = 611
     0.000045 read(10, "", 1024)        = 0
     0.000023 close(10)                 = 0
     0.000076 munmap(0x7f6e1d035000, 4096) = 0
     0.000036 open("/proc/stat", O_RDONLY) = 10
     0.000037 read(10, "cpu  3775592 27347 3516551 70619"..., 4095) = 866
     0.000084 close(10)                 = 0
     0.000045 open("/proc/vmstat", O_RDONLY) = 10
     0.000035 read(10, "nr_free_pages 75722\nnr_inactive_"..., 4095) = 1964
     0.000100 close(10)                 = 0
     0.000055 select(10, [4 6 7 9], [], [], {2, 88417}

Existe alguma configuração específica que eu possa não saber para o serviço snmpd chamar gettimeofday muitas vezes antes de responder a uma requisição?

Obrigado antecipadamente.

    

Answer 1

Aparentemente, há problemas em ter seu conjunto de variáveis TZ capaz de economizar milhares de chamadas do sistema devido à forma como as bibliotecas de tempo são codificadas.

Eles realmente estão relacionados ao seu problema e, como tal, precisaremos de feedback.

De Como configurar o ambiente TZ variável evita milhares de chamadas do sistema

To avoid extra system calls on server processes where you won’t be updating the timezone (or can restart processes when you do) simply set the TZ environment variable to :/etc/localtime (or some other timezone file of your choice) for a process. This will cause glibc to avoid making extra (and unnecessary) system calls.

It turns out that the localtime function in glibc will check if the TZ environment variable is set. If it is not set (the two Ubuntus I’ve tested do not set it), then glibc will use the stat system call every time localtime is called.

In other words: your system supports calling the time system call via the Linux kernel’s vDSO to avoid the cost of switching to the kernel. But, as soon as your program calls time, it calls localtime immediately after, which invokes a system call anyway. So, you’ve eliminated one system call with the vDSO, but replaced it with another.

Esteja ciente de que os acessos a arquivos também costumam usar chamadas do sistema relacionadas ao tempo. Tente usar nos arquivos de configuração do MIBS numérico do SNMP em vez de seus nomes. (pode ter impacto apenas em snmpd tempo de início e não fazer muita diferença depois disso).

À medida que novos acessos a arquivos fazem uso de chamadas de sistema relacionadas ao tempo, é normal que você veja alguns deles ao iniciar snmpd - você pode estar comparando um sistema sem MIBs instalados com outro com MIBs instalados.