O Samba come RAM?

Question

Eu realmente não sei o que está acontecendo no momento:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 1272 root      20   0 3829868 3.312g   1860 D   0.7 93.0 512:39.94 smbd

free -m informa:

             total       used       free     shared    buffers     cached
Mem:          3644       3560         84          7          0         25
-/+ buffers/cache:       3533        110 <--- this is what bugs me
Swap:         4292       2146       2146

Definições de serviço:

[global]
        server role = standalone server
        map to guest = Bad User
        obey pam restrictions = Yes
        pam password change = Yes
        passwd program = /usr/bin/passwd %u
        passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
        unix password sync = Yes
        syslog = 0
        log file = /var/log/samba/log.%m
        max log size = 1000
        dns proxy = No
        usershare allow guests = Yes
        panic action = /usr/share/samba/panic-action %d
        idmap config * : backend = tdb


[homes]
        comment = Home Directories
        valid users = %S
        create mask = 0700
        directory mask = 0700
        browseable = No


[printers]
        comment = All Printers
        path = /var/spool/samba
        create mask = 0700
        printable = Yes
        print ok = Yes
        browseable = No


[print$]
        comment = Printer Drivers
        path = /var/lib/samba/printers

#I don't really know what's this, but... it was a working share in its time
[media]
        path = /rem/media/


[rem]
        path = /rem/
        force user = <rem owner username here>
        read only = No
        create mask = 0660
        directory mask = 0770

EDITAR: Reiniciar o serviço smbd parece resolver o problema, MAS ele continua voltando aprox. 2 horas depois disso.

EDIT2: Depois de encerrar o serviço smbd , tudo parece estar bem:

             total       used       free     shared    buffers     cached
Mem:          3644        123       3521          8          3         36
-/+ buffers/cache:         83       3561
Swap:         4292        230       4062

EDIT3: Aqui estão mais alguns detalhes (perguntados por Daniel B ):

• A pergunta é: Por que o samba está comendo tanto carneiro?
• Distro: debian no caso de você não conseguir ler as tags: P
• Versão: 4.2.10-Debian
• Padrão de acesso? Não faço ideia do que é isso: P
• Arquivos grandes: não muito, apenas 2-3 unidades. de arquivos de 4GB Arquivos pequenos: MUITO.

EDIT4: Parece que o samba não está realmente lendo / escrevendo nada enquanto come RAM:

  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 1351 be/4 root        0.00 B/s    3.95 K/s  0.00 %  0.00 % smbd -D

EDIT5: O problema é parcialmente resolvido usando o aviso de Hastur . Agora estamos aguardando que os clientes prossigam e indexem / escaneiem / façam o que quiserem com o compartilhamento de samba.

Estado atual:

18992 root      20   0  283140   8916   6584 S   1.0  0.2   0:00.32 smbd
18983 root      20   0  284048  14964  11752 S   0.7  0.4   0:00.16 smbd

EDIT6: Que interessante:

18983 root      20   0 2964080 2.564g   6044 R  92.1 72.0 853:58.94 smbd

Agora consome memória E CPU. Alguém, por favor ajude! :)

EDIT7: Tudo bem, limitamos o número de bloqueios de arquivos & conexões, mas ainda não mudar. Come minha RAM como um louco! Bem, pelo menos, de repente parou de comer CPU.

24606 root      20   0 3768932 3.325g   2332 D  17.3 93.4   1441:50 smbd

Qualquer ajuda é realmente apreciada. Estou muito perto de escrever um cron job reiniciando o smbd a cada 24 horas.

    

Answer 1

SOLUÇÃO TEMPORÁRIA! Esta não é a maneira real de resolver este problema, mas funciona perfeitamente para mim.

1. (sudo) crontab -e .
2. Escolha nano ou vim de acordo com sua preferência. (Se você ainda não escolheu)
3. No arquivo, adicione a linha 0 [whatever hour (0-23) you want here] * * * service smbd restart

Isso reiniciará o serviço smbd (daemon do Samba) todos os dias.

Como eu disse, esta não é a solução final , então, se alguém tiver soluções melhores, ENTÃO aceito uma resposta.