Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

consommation excessive de la mémoire par samba

6 réponses
Avatar
Eric Belhomme
Bonjour,

J'ai un serveur de fichier et d'impression sous Debian Sarge qui me
consomme un quantité astronomique de mémoire :

srvpdf:~# free
total used free shared buffers cached
Mem: 255852 252304 3548 0 2684 21756
-/+ buffers/cache: 227864 27988
Swap: 682752 682744 8

%MEM VIRT RES PID USER PR NI SHR S %CPU TIME+ COMMAND
27.9 399m 69m 16114 ICSB2K+c 16 0 14m S 0.0 2:05.55 smbd
24.6 287m 61m 6026 ICSB2K+n 16 0 14m S 0.0 4:59.61 smbd
23.7 195m 59m 16139 ICSB2K+m 16 0 14m S 0.0 1:50.84 smbd
1.2 16796 3040 19409 root 16 0 14m S 0.0 0:03.88 smbd
1.1 7892 2768 18400 root 16 0 4232 S 0.0 0:17.72 cupsd
1.0 11376 2528 19522 ICSB2K+v 16 0 9564 S 0.0 0:00.21 smbd
0.9 11184 2320 2350 root 16 0 6840 S 0.0 19:33.42 winbindd
0.6 10528 1484 19521 root 16 0 8944 S 0.0 0:00.17 smbd
0.6 3068 1484 19534 root 15 0 2708 S 0.0 0:00.05 bash
0.5 11044 1368 9377 root 16 0 9332 S 0.0 0:02.21 smbd
0.5 8200 1180 2351 root 16 0 6844 S 0.0 0:36.40 winbindd
0.4 22768 1112 2385 root 16 0 14m S 0.0 23:20.87 smbd

Du coup, le serveur n'a pas d'autre recours que de faire appel au oom-
killer... Pas terrible !

Ce que je voudrais savoir, c'est comment se fait-il que samba me consomme
autant de mémoire, et comment l'en empecher ?

--
Rico

6 réponses

Avatar
Sébastien Monbrun aka TiChou
Dans le message <news:,
*Eric Belhomme* tapota sur f.c.o.l.configuration :

Bonjour,

J'ai un serveur de fichier et d'impression sous Debian Sarge qui me
consomme un quantité astronomique de mémoire :


[...]

Ce que je voudrais savoir, c'est comment se fait-il que samba me consomme
autant de mémoire,


Avant de savoir pourquoi Samba consomme autant, il faudrait nous en dire
plus sur le nombre de partages et leur contenu, le nombre moyen de clients
connectés, le nombre et la taille moyenne des fichiers transférés, etc.
Parce que si vous avez 100 clients connectés, 100 répertoires partagés
contenant des milliers de fichiers et des Go de données transférées en
écriture, il n'y a alors rien d'étonnant qu'avec seulement 256Mo de mémoire
vive on soit face un goulot d'étranglement.

et comment l'en empecher ?


En limitant le nombre de connexions simultanées (max connections) qui par
défaut est illimité, en limitant le nombre maximum de fichier ouvert (max
open files), en limitant la queue d'impression (max print jobs).
En paramétrant au mieux les options de cache (write cache size, stat cache
et getwd cache) et les options de synchronisation d'écriture (sync always).

--
Sébastien Monbrun aka TiChou

Avatar
Eric Belhomme
=?iso-8859-15?Q?Sébastien_Monbrun_aka_TiChou?=
wrote in news::

Avant de savoir pourquoi Samba consomme autant, il faudrait nous en
dire plus sur le nombre de partages et leur contenu, le nombre moyen
de clients connectés, le nombre et la taille moyenne des fichiers
transférés, etc. Parce que si vous avez 100 clients connectés, 100
répertoires partagés contenant des milliers de fichiers et des Go de
données transférées en écriture, il n'y a alors rien d'étonnant
qu'avec seulement 256Mo de mémoire vive on soit face un goulot
d'étranglement.



En fait, c'est un serveur d'impression avec samba/cups :
- une imprimante réseau administrée par cups via ipp, et partagée pour
les postes windows via samba
- une imprimante "virtuelle" qui me génère des pdf (driver cups-pdf)
partagée pour les postes windows par samba. Les fichiers pdf générés se
retrouvent dans un partage de samba nommé tres commodément "impressions"

Le serveur samba est membre d'un domaine AD (donc auth kerberos, winbind,
et tout le toutim...)

Si tu regardes les copier/coller de ps que j'ai fait on constate que j'ai
3 utilisateurs qui à eux seuls me pouffent 90% de la mémoire disponible !
Mon idée, c'est que c'est des spools d'impression qui sont restés coincés
à un moment ou à un autre au niveau de samba.
Ceci dit, ce matin mon swap est à nouveau vide, et mes ennôôôrmes
processes smbd se sont terminés comme des grands, sans que oom-killer ait
à frapper à nouveau...

En limitant le nombre de connexions simultanées (max connections) qui
par défaut est illimité, en limitant le nombre maximum de fichier
ouvert (max open files), en limitant la queue d'impression (max print
jobs). En paramétrant au mieux les options de cache (write cache size,
stat cache et getwd cache) et les options de synchronisation
d'écriture (sync always).

est-ce que tu peux me parler un peu plus de ces options de cache et de

syncro ?

--
Rico

Avatar
Sébastien Monbrun aka TiChou
Dans le message <news:,
*Eric Belhomme* tapota sur f.c.o.l.configuration :

En limitant le nombre de connexions simultanées (max connections) qui
par défaut est illimité, en limitant le nombre maximum de fichier
ouvert (max open files), en limitant la queue d'impression (max print
jobs). En paramétrant au mieux les options de cache (write cache size,
stat cache et getwd cache) et les options de synchronisation
d'écriture (sync always).

est-ce que tu peux me parler un peu plus de ces options de cache et de

syncro ?


stat cache c'est le cache qui sera utilisé pour mémoriser les informations
des fichiers parcourus. Par défaut, ce cache a une taille illimitée. Si
Samba parcoure un grand nombre de fichiers et de répertoires, ce cache peut
vite devenir gros.

write cache c'est la mémoire réservée pour stocker un fichier en écriture
avant qu'il soit « flushé » sur le disque, c'est-à-dire avant qu'il soit
réellement écrit sur le disque. L'écriture sur le disque se fait quand le
fichier est fermé ou quand le client le demande. Par défaut, la taille de ce
cache est illimitée. Si un client ouvre beaucoup de fichiers en écriture, le
cache peut vite devenir gros.

getwd cache est par défaut à on, mais en fait ne devrait pas impacter
l'utilisation mémoire. Il vaut mieux le laisser à on de toute manière.

sync always c'est pour forcer l'écriture des fichiers sur le disque au lieu
de les stocker temporairement en mémoire. Ça peut réduire l'utilisation en
mémoire, mais au détriment de la rapidité d'accès aux fichiers.

--
Sébastien Monbrun aka TiChou


Avatar
Eric Belhomme
=?iso-8859-15?Q?Sébastien_Monbrun_aka_TiChou?=
wrote in news::


stat cache c'est le cache qui sera utilisé pour mémoriser les
informations des fichiers parcourus. Par défaut, ce cache a une taille
illimitée. Si Samba parcoure un grand nombre de fichiers et de
répertoires, ce cache peut vite devenir gros.

write cache c'est la mémoire réservée pour stocker un fichier en
écriture avant qu'il soit « flushé » sur le disque, c'est-à-dire avant
qu'il soit réellement écrit sur le disque. L'écriture sur le disque se
fait quand le fichier est fermé ou quand le client le demande. Par
défaut, la taille de ce cache est illimitée. Si un client ouvre
beaucoup de fichiers en écriture, le cache peut vite devenir gros.

getwd cache est par défaut à on, mais en fait ne devrait pas impacter
l'utilisation mémoire. Il vaut mieux le laisser à on de toute manière.

sync always c'est pour forcer l'écriture des fichiers sur le disque au
lieu de les stocker temporairement en mémoire. Ça peut réduire
l'utilisation en mémoire, mais au détriment de la rapidité d'accès aux
fichiers.

Extraits "Samba, Installation et mise en oeuvre" de chez O'Reilly :


stat cache = bolléen - défaut yes
Demande au serveur Samba de mettre en cache le nom des clients pour une
résolution plus rapide. Ne doit pas être modifié.

stat cache size = nombre - défaut 50
Détermine le nombre de noms de clients mis en cache pour une résolution
plus rapide. Ne doit pas être modifié.

write cache size = nombre - défaut 0 (désactivé)
Alloue un tampon d'écriture à la taille spécifiée dans lequel Samba
accumule les données avant de les écrire sur le disque. Cette option peut
être employée pour garantir que chaque écriture a la taille optimale pour
un système de fichier donné. Utilisé classiquement avec des lecteurs en
RAID qui possèdent une taille d'écriture favorite et des systèmes qui ont
beaucoup de mémoire et des disques lents.

sync always = booléen - défaut no
Si elle égale à YES, Samba force le vidage des données vers le disque via
fsync (3) après chaque écriture. A éviter hormis pour le débogage des
serveurs défaillants.

Bref, ca n'a rien à voir avec ce que tu suggères...

--
Rico

Avatar
Sébastien Monbrun aka TiChou
Dans le message <news:,
*Eric Belhomme* tapota sur f.c.o.l.configuration :

stat cache c'est le cache qui sera utilisé pour mémoriser les
informations des fichiers parcourus. Par défaut, ce cache a une taille
illimitée. Si Samba parcoure un grand nombre de fichiers et de
répertoires, ce cache peut vite devenir gros.

write cache c'est la mémoire réservée pour stocker un fichier en
écriture avant qu'il soit « flushé » sur le disque, c'est-à-dire avant
qu'il soit réellement écrit sur le disque. L'écriture sur le disque se
fait quand le fichier est fermé ou quand le client le demande. Par
défaut, la taille de ce cache est illimitée. Si un client ouvre
beaucoup de fichiers en écriture, le cache peut vite devenir gros.

getwd cache est par défaut à on, mais en fait ne devrait pas impacter
l'utilisation mémoire. Il vaut mieux le laisser à on de toute manière.

sync always c'est pour forcer l'écriture des fichiers sur le disque au
lieu de les stocker temporairement en mémoire. Ça peut réduire
l'utilisation en mémoire, mais au détriment de la rapidité d'accès aux
fichiers.


Extraits "Samba, Installation et mise en oeuvre" de chez O'Reilly :

stat cache size = nombre - défaut 50
Détermine le nombre de noms de clients mis en cache pour une résolution
plus rapide. Ne doit pas être modifié.


man smb.conf

stat cache (G)
This parameter specifies the maximum amount of memory (in kilobytes
) smbd will use for the stat cache that speeds up case insensitive
name mappings. If set to zero (the default) there is no limit.
Change this if your smbd processes grow too large when servicing
something like a back-up application.

Default: stat cache = 0

write cache size = nombre - défaut 0 (désactivé)
Alloue un tampon d'écriture à la taille spécifiée dans lequel Samba
accumule les données avant de les écrire sur le disque. Cette option peut
être employée pour garantir que chaque écriture a la taille optimale pour
un système de fichier donné. Utilisé classiquement avec des lecteurs en
RAID qui possèdent une taille d'écriture favorite et des systèmes qui ont
beaucoup de mémoire et des disques lents.


man smb.conf

write cache size (S)
If this integer parameter is set to non-zero value, Samba will
create an in-memory cache for each oplocked file (it does not do
this for non-oplocked files). All writes that the client does
not request to be flushed directly to disk will be stored in
this cache if possible. The cache is flushed onto disk when a
write comes in whose offset would not fit into the cache or when
the file is closed by the client. Reads for the file are also
served from this cache if the data is stored within it.

This cache allows Samba to batch client writes into a more effi-
cient write size for RAID disks (i.e. writes may be tuned to be
the RAID stripe size) and can improve performance on systems
where the disk subsystem is a bottleneck but there is free mem-
ory for userspace programs.

The integer parameter specifies the size of this cache (per
oplocked file) in bytes.

Default: write cache size = 0

Example: write cache size = 262144 # for a 256k cache size per
file


sync always = booléen - défaut no
Si elle égale à YES, Samba force le vidage des données vers le disque via
fsync (3) après chaque écriture. A éviter hormis pour le débogage des
serveurs défaillants.


man smb conf

sync always (S)
This is a boolean parameter that controls whether writes will
always be written to stable storage before the write call
returns. If this is no then the server will be guided by the
client's request in each write call (clients can set a bit indi-
cating that a particular write should be synchronous). If this
is yes then every write will be followed by a fsync() call to
ensure the data is written to disk. Note that the strict sync
parameter must be set to yes in order for this parameter to have
any affect.

Default: sync always = no


Bref, ca n'a rien à voir avec ce que tu suggères...


Gniii ?! À part pour l'histoire du stat cache (mea culpa) où dans mes
souvenirs il me semblait qu'il s'agissait d'un cache fstat et où O'Reilly
n'est même pas en accord avec ce que décrit la documentation officielle de
Samba, le reste de ce que j'ai décrit est exactement ce que dit la
documentation de Samba et à peu de chose près ce qu'indique la documentation
d'O'Reilly.
Donc « rien à voir » ? Hmmm, des explications ? :-)

--
Sébastien Monbrun aka TiChou


Avatar
Calimero
Sébastien Monbrun aka TiChou wrote:


man smb.conf

stat cache (G)
This parameter specifies the maximum amount of memory (in kilobytes
) smbd will use for the stat cache that speeds up case insensitive
name mappings. If set to zero (the default) there is no limit.
Change this if your smbd processes grow too large when servicing
something like a back-up application.

Default: stat cache = 0


Moi j'ai ca:

stat cache (G)
This parameter determines if smbd(8) will use a cache
in order to speed up case insensitive name mappings. You should never
need to change
this parameter.

Default: stat cache = yes


max stat cache size (G)
This parameter limits the size in memory of any stat
cache being used to speed up case insensitive name mappings. This
parameter is the num-
ber of kilobyte (1024) units the stat cache can use.
The default is zero, which means unlimited. You should not need to
change this parame-
ter.

Default: max stat cache size = 0

Example: max stat cache size = 1024


Pour la write cache et la syncro, les choses sont claires par contre.

Mon samba : 3.0.22.


Ca tourne un peu à fr.comp.os.linux.manpages ! ;)

--
@+
Calimero