Re: [sympa-fr] wwsympa.fcgi : consommation mémoire sous FreeBSD

[Alban Rodriguez <adresse@cachée>]

Le 20 janv. 2021 à 12:11, Éric Mauger <adresse@cachée> a écrit :

Bonjour,

Je fais tourner sympa (installation par les packages 6.2.56 puis mis à jour en 6.2.60) sur un FreeBSD 12.1
J'ai régulièrement des messages 'out of swap space' liés à une consommation
mémoire excessive de wwsympa.fcgi.
La moindre opération provoque une augmentation de la taille mémoire du process perl.

Au démarrage du process, il utilise 181Mo
sympa   15527   2.0  1.0 181944 166120  -  Ss   11:39        0:04.16 /usr/local/bin/perl /usr/local/libexec/sympa/wwsympa.fcgi

Après une dizaine de requêtes : 1,5Go
sympa   15527   0.0  9.4 1598040 1574372  -  Is   11:39 1:12.96 /usr/local/bin/perl /usr/local/libexec/sympa/wwsympa.fcgi

J'utilise spawn-fcgi comme indiqué dans la doc, mais je ne pense pas que cela ait une influence ...

Je joins ci-dessous le résultat du perl -V

perl -V
Summary of my perl5 (revision 5 version 32 subversion 0) configuration:

  Platform:
    osname=freebsd
    osvers=12.1-release-p12
    archname=amd64-freebsd-thread-multi
    uname='freebsd 121amd64-quarterly-job-02 12.1-release-p12 freebsd 12.1-release-p12 amd64 '
    config_args='-Darchlib=/usr/local/lib/perl5/5.32/mach -Dcc=cc -Dcf_by=mat -adresse@cachée -Dcf_time=Sat Jun 20 20:39:10 UTC 2020 -Dinc_version_list=none -Dlibperl=libperl.so.5.32.0 -Dman1dir=/usr/local/lib/perl5/5.32/perl/man/man1 -Dman3dir=/usr/local/lib/perl5/5.32/perl/man/man3 -Dprefix=/usr/local -Dprivlib=/usr/local/lib/perl5/5.32 -Dscriptdir=/usr/local/bin -Dsitearch=/usr/local/lib/perl5/site_perl/mach/5.32 -Dsitelib=/usr/local/lib/perl5/site_perl -Dsiteman1dir=/usr/local/lib/perl5/site_perl/man/man1 -Dsiteman3dir=/usr/local/lib/perl5/site_perl/man/man3 -Dusenm=n -Duseshrplib -sde -Ui_iconv -Ui_malloc -Uinstallusrbinperl -Alddlflags=-L/wrkdirs/usr/ports/lang/perl5.32/work/perl-5.32.0 -L/usr/local/lib/perl5/5.32/mach/CORE -lperl -Dshrpldflags=$(LDDLFLAGS:N-L/wrkdirs/usr/ports/lang/perl5.32/work/perl-5.32.0:N-L/usr/local/lib/perl5/5.32/mach/CORE:N-lperl) -Wl,-soname,$(LIBPERL:R) -Doptimize=-O2 -pipe -fstack-protector-strong -fno-strict-aliasing  -Dusedtrace -Ui_gdbm -Dusemultiplicity=y -Duse64bitint -Dusemymalloc=n -Dusethreads=y -Accflags=-DUSE_THREAD_SAFE_LOCALE'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=define
    usemultiplicity=define
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
    bincompat5005=undef
  Compiler:
    cc='cc'
    ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -DUSE_THREAD_SAFE_LOCALE -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_FORTIFY_SOURCE=2'
    optimize='-O2 -pipe -fstack-protector-strong -fno-strict-aliasing '
    cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -DUSE_THREAD_SAFE_LOCALE -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
    ccversion=''
    gccversion='4.2.1 Compatible FreeBSD Clang 8.0.1 (tags/RELEASE_801/final 366581)'
    gccosandvers=''
    intsize=4
    longsize=8
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=3
    ivtype='long'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='off_t'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='cc'
    ldflags ='-pthread -Wl,-E  -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/lib /usr/local/lib /usr/lib/clang/8.0.1/lib /usr/lib
    libs=-lpthread -lm -lcrypt -lutil
    perllibs=-lpthread -lm -lcrypt -lutil
    libc=
    so=so
    useshrplib=true
    libperl=libperl.so.5.32.0
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs
    dlext=so
    d_dlsymun=undef
    ccdlflags='  -Wl,-R/usr/local/lib/perl5/5.32/mach/CORE'
    cccdlflags='-DPIC -fPIC'
    lddlflags='-shared  -L/usr/local/lib/perl5/5.32/mach/CORE -lperl -L/usr/local/lib -fstack-protector-strong'


Characteristics of this binary (from libperl):
  Compile-time options:
    HAS_TIMES
    MULTIPLICITY
    PERLIO_LAYERS
    PERL_COPY_ON_WRITE
    PERL_DONT_CREATE_GVSV
    PERL_IMPLICIT_CONTEXT
    PERL_MALLOC_WRAP
    PERL_OP_PARENT
    PERL_PRESERVE_IVUV
    USE_64_BIT_ALL
    USE_64_BIT_INT
    USE_ITHREADS
    USE_LARGE_FILES
    USE_LOCALE
    USE_LOCALE_COLLATE
    USE_LOCALE_CTYPE
    USE_LOCALE_NUMERIC
    USE_LOCALE_TIME
    USE_PERLIO
    USE_PERL_ATOF
    USE_REENTRANT_API
    USE_THREAD_SAFE_LOCALE
  Built under freebsd
  @INC:
    /usr/local/lib/perl5/site_perl/mach/5.32
    /usr/local/lib/perl5/site_perl
    /usr/local/lib/perl5/5.32/mach
    /usr/local/lib/perl5/5.32


Cordialement,

--
Eric Mauger | Administrateur système et réseau
IGF UMR5203 | https://www.igf.cnrs.fr

Bonjour Eric,

Nous avons ce problème aussi sous Linux SLES12 SP5 avec Perl en version 5.18.2 (un peu vieux mais toujours supporté !)

Nous avions déjà ce problème avec des version antérieures de l’OS et de Perl et alors que la partie web de Sympa était gérée avec Apache + mod_fcgid.

La solution de contournement avaient été à l’époque de limiter la durée de vie des worker processes avec les paramètres fcgid:

maxRequestsPerProcess 10

maxProcessLifeTime 900

Fast forward jusqu’au remplacement d’Apache par Nginx + Socket Systemd + Multiwatch (c’est à dire l’architecture décrite sur cette page du manuel: https://sympa-community.github.io/manual/install/configure-http-server-systemdsocket.html) -> cf le thread «  Très grosse utilisation mémoire de wwsympa depuis mise à jour en 6.2.44 » 

Et toujours ces problèmes de mémoire.

Je dirais que c’est encore plus flagrant depuis que nous avons mis à jour Sympa en version 6.2.60 et nous sommes actuellement en 6.2.62

Ce qui est étrange, c’est que cela ne semble pas être un problème largement rencontré.

Quelques recherches ont montré que c’est plus probablement un module Perl qui serait à l’origine du problème plutôt que Perl lui même et il semble que DBI ou DBD:mysql revienne souvent dans les pages trouvées à ce sujet.

N’étant pas développeur Perl, partir sur du profiling dans l’espoir de trouver où se trouve la fuite ma paraît assez incertain :-\

J’ai bien entendu mis à jour tous mes modules Perl mais aucun effet.

A noter que nous avons la portlet Esup-sympa dans notre ENT que donc, chaque utilisateur affichant la page (indépendamment de l’utiliser ou pas) génère une requête au serveur SOAP de Sympa et donc à WWSympa. Nous avons donc très régulièrement des requêtes sur WWSympa ce qui fait inexorablement croitre l’occupation mémoire des processus Perl.

Ma solution «  à deux balles » : implémenter le même contournement qu’avec mod_fcgid en modifiant quelques lignes dans wwsympa.fcgi:

Déclaration de deux nouvelles variables globales:

+# FCGI process lifetime control parameters
+my $maxRequestsPerProcess = 10;
+my $maxProcessLifeTime = 900;

On cherche ensuite la boucle principale dans laquelle on peut remarquer deux variables existantes $loop_count et $start_time qui vont servir à tester si l'on n'a pas atteint les limites définies par les deux variables globales $maxRequestsPerProcess et $maxProcessLifeTime

# Main loop.
my $loop_count = 0;
my $start_time = time;
while ($query = Sympa::WWW::FastCGI->new) {
    $loop_count++;
 
	...

Il suffit alors de chercher le texte '# Exit if wwsympa.fcgi itself has changed.' en toute fin de cette boucle et qui montre justement une condition de sortie dans le cas où le script aurait été modifié depuis que WWSympa a été lancé et d’y ajouter deux nouvelles conditions de sortie

 # Exit if wwsympa.fcgi itself has changed.
    if (defined $birthday) {
        my $age = [stat $PROGRAM_NAME]->[9];
        if (defined $age and $birthday != $age) {
            $log->syslog(
                'notice',
                'Exiting because %s has changed since FastCGI server started',
                $PROGRAM_NAME
            );
            exit(0);
        }
    }
+    # Exit if maxRequestsPerProcess has been exceeded 
+    if ( $loop_count > $maxRequestsPerProcess ) {
+        $log->syslog(
+            'notice',
+            'Exiting %s because maxRequestsPerProcess has been exceeded',
+            $PROGRAM_NAME
+        );
+        exit(0);
+    }
+
+    # Exit if current process lifetime has exceeded maxProcessLifeTime
+    if ( (time - $start_time) > $maxProcessLifeTime ) {
+        $log->syslog(
+            'notice',
+            'Exiting %s because process lifetime has exceeded maxProcessLifeTime',
+            $PROGRAM_NAME
+        );
+        exit(0);
+    }
}

Une fois Sympa redémarré, on peut observer le log et confirmer que les processus sont bien arrêté (et de nouveaux démarrés par Multiwatch)

2021-06-07T15:21:01.903972+02:00 sympa wwsympa[19535]: notice main:: Exiting /Sympa/apps/sympa/bin/wwsympa.fcgi because process lifetime has exceeded maxProcessLifeTime
2021-06-07T15:21:02.396046+02:00 sympa wwsympa[21521]: info main:: WWSympa started, process 21521

L’inconvénient et qu’il faut à nouveau modifier le code après chaque mise à jour mais un bon vieux fichier patch fait l’affaire et j’avais déjà une modification maison que j’appliquais à chaque fois, alors ...

Au final, c’est peut-être une très mauvaise idée de faire ça mais depuis, l’utilisation de la mémoire reste stable.

Ça tiendra jusqu’à la prochaine réinstallation complète ...

Alban