Solaris, libmalloc et libmtmalloc

JKB <knatschke@koenigsberg.fr> wrote:

Je m'aperçois avec pstat qu'au fur et à mesure, certains threads (en
nombre croissant) perdent du temps de calcul effectif jusqu'à 10% de
USER et 90% de LOCK ! J'ai regardé mon code sans rien trouver. Un coup de
plockstat me donne :

Que penses tu de ceci:
http://ekschi.com/technology/2009/06/26/mtmalloc-vs-umem/



--

Michel TALON

Le 03-05-2010, ? propos de
Re: Solaris, libmalloc et libmtmalloc,
Michel Talon ?crivait dans fr.comp.os.unix :

JKB <knatschke@koenigsberg.fr> wrote:

Je m'aperçois avec pstat qu'au fur et à mesure, certains threads (en
nombre croissant) perdent du temps de calcul effectif jusqu'à 10% de
USER et 90% de LOCK ! J'ai regardé mon code sans rien trouver. Un coup de
plockstat me donne :

Que penses tu de ceci:
http://ekschi.com/technology/2009/06/26/mtmalloc-vs-umem/

Je connaissais, mais ça n'aide pas vraiment dans le cas présent.
J'ai utilisé depuis hier soir libmalloc en lieu et place de
mtlibmalloc et ça fonctionne mieux. En revanche, le free() de
libmalloc() ne renvoie pas la mémoire au système mais à
l'application, ce qui fait que la machine se met de plus en plus à
swapper. Là, tout de suite, j'en suis à :

prstat -avl 1
...
88 bertrand 34G 7016M 87% 188:23:29 23%

soit 34 Go de swap utilisé pour une application qui n'a aucune fuite
mémoire (j'ai un debugger interne qui râle lorsqu'une zone mémoire
n'est pas libérée et surtout, sous Linux ou NetBSD, le même
programme se comporte décemment et reste cantonné dans 2 Go de
mémoire).

Je vais peut-être essayer la libumem pour voir. Question de fond :
comment faire sous Solaris (et sans utiliser mmap() parce que dans
mon cas, ce n'est pas utilisable en raison de l'alignement des
blocs) pour qu'un free() renvoie la mémoire au système et non au tas
de l'application ?

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 03-05-2010, ? propos de
Re: Solaris, libmalloc et libmtmalloc,
Michel Talon ?crivait dans fr.comp.os.unix :

JKB <knatschke@koenigsberg.fr> wrote:

Je m'aperçois avec pstat qu'au fur et à mesure, certains threads (en
nombre croissant) perdent du temps de calcul effectif jusqu'à 10% de
USER et 90% de LOCK ! J'ai regardé mon code sans rien trouver. Un coup de
plockstat me donne :

Que penses tu de ceci:
http://ekschi.com/technology/2009/06/26/mtmalloc-vs-umem/

Bon... libmalloc et libumem donnent grosso-modo le même résultat. Je
pense que le problème provient de la fragmentation de la mémoire.
Comment limiter cette fragmentation ? Est-ce qu'un outil comme
jemalloc est efficace ? Ce qui est amusant (enfin, si on peut dire),
c'est que libmtmalloc n'induit pas une utilisation du swap,
simplement une latence supplémentaire. Libmalloc et libumem
provoquent une augmentation plus que significative de l'espace
d'adressage du processus.

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB <knatschke@koenigsberg.fr> wrote:

Le 03-05-2010, ? propos de
Re: Solaris, libmalloc et libmtmalloc,
Michel Talon ?crivait dans fr.comp.os.unix :
> JKB <knatschke@koenigsberg.fr> wrote:
>> Je m'aperçois avec pstat qu'au fur et à mesure, certains threads (en
>> nombre croissant) perdent du temps de calcul effectif jusqu'à 10% de
>> USER et 90% de LOCK ! J'ai regardé mon code sans rien trouver. Un coup de
>> plockstat me donne :
>>>
>
>
> Que penses tu de ceci:
> http://ekschi.com/technology/2009/06/26/mtmalloc-vs-umem/

Bon... libmalloc et libumem donnent grosso-modo le même résultat. Je
pense que le problème provient de la fragmentation de la mémoire.
Comment limiter cette fragmentation ? Est-ce qu'un outil comme
jemalloc est efficace ? Ce qui est amusant (enfin, si on peut dire),

Tu as essayé de faire tourner ton programme sur FreeBSD? si ça passe
bien, c'est que jemalloc est efficace ...

Il me semblait que tous les malloc allouent de la mémoire à un
processus, et que le free la rend au processus et non pas au système.
Eventuellement le système récupère de la mémoire plus tard quand il
trouve des pages non utilisées. Donc la performance dépend aussi de
celle du système de mémoire virtuelle. Maintenant les truc comme
jemalloc qui sont conçus pour des programmes multithreadés avec des
allocations indépendantes pour chaque thread de façon à ne pas avoir à
poser des verrous, fonctionnent en utilisant plusieurs pools de mémoire
(par exemple un par thread) et donc vont être plus consommateurs de
mémoire que des allocateurs avec un seul pool. Si ton programme utilise
en réalité peu de concurrence, il est possible que l'utilisation d'un
malloc à l'ancienne soit préférable en dépit des coûts de
synchronisation. Clairement les allocateurs modernes ont été conçus pour
des programmes fortement multithreadés avec une forte concurrence dans
l'allocation de mémoire. Dans ce cas diviser les coûts de verrouillage
est important.

Ceci peut t'intéresser:
http://benjamin.smedbergs.us/blog/tag/jemalloc/



--

Michel TALON

Le 04-05-2010, ? propos de
Re: Solaris, libmalloc et libmtmalloc,
Michel Talon ?crivait dans fr.comp.os.unix :

JKB <knatschke@koenigsberg.fr> wrote:

Le 03-05-2010, ? propos de
Re: Solaris, libmalloc et libmtmalloc,
Michel Talon ?crivait dans fr.comp.os.unix :
> JKB <knatschke@koenigsberg.fr> wrote:
>> Je m'aperçois avec pstat qu'au fur et à mesure, certains threads (en
>> nombre croissant) perdent du temps de calcul effectif jusqu'à 10% de
>> USER et 90% de LOCK ! J'ai regardé mon code sans rien trouver. Un coup de
>> plockstat me donne :
>>>
>
>
> Que penses tu de ceci:
> http://ekschi.com/technology/2009/06/26/mtmalloc-vs-umem/

Bon... libmalloc et libumem donnent grosso-modo le même résultat. Je
pense que le problème provient de la fragmentation de la mémoire.
Comment limiter cette fragmentation ? Est-ce qu'un outil comme
jemalloc est efficace ? Ce qui est amusant (enfin, si on peut dire),

Tu as essayé de faire tourner ton programme sur FreeBSD? si ça passe
bien, c'est que jemalloc est efficace ...

Il me semblait que tous les malloc allouent de la mémoire à un
processus, et que le free la rend au processus et non pas au système.

J'ai fait des tests. Sous Linux, la mémoire est renvoyée au système
(sauf peut-être lorsqu'elle est allouée sur le tas). Sous NetBSD et
FreeBSD, je n'ai pas fait de tests poussés, mais je suis sûr que le
programme en question tourne correctement.

Eventuellement le système récupère de la mémoire plus tard quand il
trouve des pages non utilisées. Donc la performance dépend aussi de
celle du système de mémoire virtuelle. Maintenant les truc comme
jemalloc qui sont conçus pour des programmes multithreadés avec des
allocations indépendantes pour chaque thread de façon à ne pas avoir à
poser des verrous, fonctionnent en utilisant plusieurs pools de mémoire
(par exemple un par thread) et donc vont être plus consommateurs de
mémoire que des allocateurs avec un seul pool. Si ton programme utilise
en réalité peu de concurrence, il est possible que l'utilisation d'un
malloc à l'ancienne soit préférable en dépit des coûts de
synchronisation. Clairement les allocateurs modernes ont été conçus pour
des programmes fortement multithreadés avec une forte concurrence dans
l'allocation de mémoire. Dans ce cas diviser les coûts de verrouillage
est important.

Ceci peut t'intéresser:
http://benjamin.smedbergs.us/blog/tag/jemalloc/

Merci, déjà lu ;-)

Sous Solaris, j'ai déjà testé libmalloc, libbsdmalloc, libumem et
libmtmalloc. Tous se comportent de manières différentes, mais aucun
ne donne satisfaction. libmtmalloc n'utilise pas de swap mais pose
des verrous qui grèvent les performances, libmalloc et libumem se
mettent à swapper...

Je vais essayer LD_PRELOAD avec la libjemalloc...

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB wrote:

J'ai fait des tests. Sous Linux, la mémoire est renvoyée au système

J'ai déjà eu le gag d'un programme qui faisait une boucle contenant
essentiellement free(malloc(taille)); et sous linux passait son temps en
appel système à demander et rendre la mémoire. Il faut quand même des
patterns d'allocation rares pour que la fragmentation cause une
occupation mémoire qui augmente ainsi.

Sous Solaris, j'ai déjà testé libmalloc, libbsdmalloc, libumem et
libmtmalloc.

umem et mtmalloc ont des options qui peuvent jouer. umem a quelque chose
comme UMEM_OPTIONSºckend=mmap, et mtmalloc MTCHUNKSIZEP. Aucune idée
de si ça aurait un effet dans ce cas particulier.

Tous se comportent de manières différentes, mais aucun
ne donne satisfaction. libmtmalloc n'utilise pas de swap mais pose
des verrous qui grèvent les performances, libmalloc et libumem se
mettent à swapper...

Ça sent le bug quelque part, mtmalloc est précisément censé ne pas
locker, et malloc (et umem) utiliser moins de mémoire...

Le 04-05-2010, ? propos de
Re: Solaris, libmalloc et libmtmalloc,
Marc ?crivait dans fr.comp.os.unix :

JKB wrote:

J'ai fait des tests. Sous Linux, la mémoire est renvoyée au système

J'ai déjà eu le gag d'un programme qui faisait une boucle contenant
essentiellement free(malloc(taille)); et sous linux passait son temps en
appel système à demander et rendre la mémoire. Il faut quand même des
patterns d'allocation rares pour que la fragmentation cause une
occupation mémoire qui augmente ainsi.

Peut-être, mais je viens de lancer la même chose avec la
libptmalloc3 et ça passe. La libjemalloc est assez mal écrite pour
ne pas être portable. Au bout d'un certain temps, les perfs
baissent (145h de temps CPU sur 32 threads) parce que l'allocateur
best fit passe du temps à chercher le meilleur bloc disponible, mais
mon processus reste en-dessous de 2,5 Go de mémoire utilisée, ce qui
est sa taille normale.

Sous Solaris, j'ai déjà testé libmalloc, libbsdmalloc, libumem et
libmtmalloc.

umem et mtmalloc ont des options qui peuvent jouer. umem a quelque chose
comme UMEM_OPTIONSºckend=mmap, et mtmalloc MTCHUNKSIZEP. Aucune idée
de si ça aurait un effet dans ce cas particulier.

Tous se comportent de manières différentes, mais aucun
ne donne satisfaction. libmtmalloc n'utilise pas de swap mais pose
des verrous qui grèvent les performances, libmalloc et libumem se
mettent à swapper...

Ça sent le bug quelque part, mtmalloc est précisément censé ne pas
locker, et malloc (et umem) utiliser moins de mémoire...

Il y a un verrou dans libmtmalloc, même s'il est moins pénalisant
que celui de la libmalloc. En tout cas, il y en a un dans la version
de Nexenta.

Concernant maintenant l'odeur de bug, je serais largement moins
affirmatif. Je comprends tout à fait que l'utilisation qui est faite
de malloc/free dans ce programme puisse dérouter les allocateurs de
base. Ce qui me pose problème, c'est le comportement par défaut de
l'allocateur de Solaris. J'ai pas mal googlisé aujourd'hui et j'ai
trouvé un certain nombre de pages parlant de ce genre de problème
avec MySQL, PostgreSQL, Ruby et Python. Avec MySQL, la solution est
de lier avec libmtmalloc. Avec les autres, la solution est de lier
avec la libptmalloc3 ou quelque chose d'équivalent.

D'autre part, le programme en question entretient déjà un cache (il
travaille essentiellement sur des listes chaînées de longueurs
variables) pour réduire au maximum les opérations d'allocation et de
libération. Je ne vois donc pas ce que je peux faire de plus (sauf
me triturer les neurones pour écrire une routine de
défragmentation...), mais je suis preneur de toutes les idées ;-)

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB wrote:

La libjemalloc est assez mal écrite pour ne pas être portable.

Il me semble que firefox 3.0 venait avec une libjemalloc.so. Maintenant
c'est inclus directement dans l'executable, mais c'est quand même du côté
de firefox que je chercherais des sources portables de jemalloc. (dans
mes tests c'était toujours l'implémentation de malloc la plus lente, mais
visiblement on n'a pas les mêmes conditions d'utilisation)

Avec les autres, la solution est de lier
avec la libptmalloc3 ou quelque chose d'équivalent.

C'est un peu pénible parce qu'à ma connaissance elle n'est pas livrée
avec l'OS, et ça serait bien de pouvoir se contenter de celles qui sont
là par défaut...

Je ne vois donc pas ce que je peux faire de plus

Bon courage.

Le 05-05-2010, ? propos de
Re: Solaris, libmalloc et libmtmalloc,
Marc ?crivait dans fr.comp.os.unix :

JKB wrote:

La libjemalloc est assez mal écrite pour ne pas être portable.

Il me semble que firefox 3.0 venait avec une libjemalloc.so. Maintenant
c'est inclus directement dans l'executable, mais c'est quand même du côté
de firefox que je chercherais des sources portables de jemalloc. (dans
mes tests c'était toujours l'implémentation de malloc la plus lente, mais
visiblement on n'a pas les mêmes conditions d'utilisation)

C'est bien ces sources que j'utilisais. Par contre, elles sont
inutilisables car elles dépendent d'un tas de choses de mozilla. On
ne peut pas directement les récupérer.

Avec les autres, la solution est de lier
avec la libptmalloc3 ou quelque chose d'équivalent.

C'est un peu pénible parce qu'à ma connaissance elle n'est pas livrée
avec l'OS, et ça serait bien de pouvoir se contenter de celles qui sont
là par défaut...

Je suis bien d'accord. Maintenant, si les allocateurs par défaut
sont moisis sous Solaris, il faut bien que je trouve quelque chose
de moins pire.

Je ne vois donc pas ce que je peux faire de plus

Bon courage.

Merci... Je viens d'augmenter la mémoire cache de l'allocateur déjà
présent dans le programme (16384 maillons de liste chaînée à la
place de 1024) et de remplacer l'allocateur. On va tester, mais
chaque test prend cinq à six heures de temps de calcul :-(

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Bonjour à tous,

Je progresse sur mon problème de mémoire et j'avoue ne plus
comprendre comment Solaris 10 (sparc) gère sa mémoire.

Historique :

1/ j'ai testé les différents allocateurs disponibles par défaut dans
Solaris, thread safe ou non (pour libbsd, j'ai utilisé une macro
posant un mutex autour de chaque malloc/free) : libmalloc,
libbsdmalloc, libumem et libmtmalloc.
2/ le seul allocateur qui fonctionne à peu près est celui de la
libmtmalloc, mais les performances sont moindres que celles de
ptmalloc3. J'utilise donc ptmalloc3.
3/ Libmalloc, libbsdmalloc et libumem provoquent une explosion du
swap.

J'ai enfin compris pourquoi certains allocateurs (bizarrement les
allocateurs first fit) provoquent une explosion du swap : Solaris
balance dans le swap toutes les données et comme les allocateurs
first fit allouent prioritairement des zones de pages en mémoire, le
tas associé au processus n'arrête pas d'augmenter avec de plus en
plus de zones vides. J'ai écrit une routine dessinant l'occupation
de la mémoire et j'obtiens un superbe morceau de gruyère, pardon
d'emmenthal parce que tout le monde sait que le gruyère n'a pas de
trous... Les allocateurs best fit se débrouillent donc largement mieux.

En revanche, j'ai une question simple qui n'a pas encore trouvé de
réponse. La machine en question est une T1000 avec un processeur à 8
coeurs (et 32 threads) et 8 Go de mémoire vive. En régime de
croisième, l'utilisation moyenne de la mémoire (tous processus
confondus) est de 4 Go. Un prstat me signale que mon processus de calcul
utilise :

PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
2847 bertrand 2896M 2725M cpu18 22 0 267:02:52 21% serveur.rpl/66

NLWP USERNAME SWAP RSS MEMORY TIME CPU
103 bertrand 3778M 3623M 45% 149:57:02 21%
167 root 89M 54M 0,7% 3:03:46 0,0%
55 noaccess 149M 132M 1,6% 6:29:47 0,0%
7 optim 23M 21M 0,3% 0:16:14 0,0%
10 webservd 129M 32M 0,4% 0:00:03 0,0%
1 nobody 1088K 2120K 0,0% 0:00:01 0,0%
1 smmsp 1496K 7144K 0,1% 0:01:05 0,0%
14 daemon 5648K 9136K 0,1% 0:00:43 0,0%

ce qui est tout à fait normal si on oublie le pourcentage du CPU
consommé. Ce qui l'est nettement moins, c'est la vue en détail des
ressources utilisées où on voit que le problème vient des défauts
de pages.

PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID
2847 bertrand 88 0,0 12 0,0 0,0 0,0 0,0 0,0 0 11 0 0 serveur.rpl/1297
2847 bertrand 15 9,6 0,0 0,0 50 0,0 25 0,2 134 9 2K 0 serveur.rpl/1291
2847 bertrand 13 11 0,0 0,0 56 0,0 20 0,3 136 6 1K 0 serveur.rpl/1283
2847 bertrand 12 8,8 0,0 0,0 64 7,4 7,2 0,3 149 9 1K 0 serveur.rpl/1267
2847 bertrand 14 6,7 0,0 0,0 74 1,3 3,7 0,3 163 10 982 0 serveur.rpl/1209
2847 bertrand 14 6,8 0,0 0,0 62 0,9 16 0,2 171 10 1K 0 serveur.rpl/1219
2847 bertrand 13 7,3 0,0 0,0 69 0,0 10 0,4 151 14 1K 0 serveur.rpl/1247
2847 bertrand 14 6,6 0,0 0,0 62 0,6 17 0,2 152 10 1K 0 serveur.rpl/1179
2847 bertrand 13 7,3 0,0 0,0 74 0,1 5,0 0,3 159 13 1K 0 serveur.rpl/1245
2847 bertrand 14 6,3 0,0 0,0 68 3,2 9,1 0,3 137 10 1K 0 serveur.rpl/1239
2847 bertrand 12 7,9 0,0 0,0 69 4,2 6,8 0,3 145 16 978 0 serveur.rpl/1243
2847 bertrand 14 5,8 0,1 0,0 73 1,3 6,1 0,3 178 15 979 0 serveur.rpl/1191
2847 bertrand 13 6,5 0,0 0,0 74 0,0 6,4 0,2 157 8 977 0 serveur.rpl/1185
2847 bertrand 13 5,7 0,1 0,0 73 0,0 7,4 0,3 163 8 976 0 serveur.rpl/1197
2847 bertrand 13 6,2 0,0 0,0 52 9,5 19 0,2 156 13 1K 0 serveur.rpl/1263
2847 bertrand 13 5,6 0,0 0,0 75 0,0 6,0 0,3 164 11 977 0 serveur.rpl/1229
2847 bertrand 12 7,2 0,0 0,0 49 0,0 32 0,3 122 9 1K 0 serveur.rpl/1271
2847 bertrand 11 7,8 0,0 0,0 44 11 26 0,2 121 13 1K 0 serveur.rpl/1295
2847 bertrand 13 5,5 0,1 0,0 67 8,2 6,0 0,2 154 13 983 0 serveur.rpl/1199
2847 bertrand 12 6,4 0,0 0,0 74 0,0 7,5 0,2 136 15 977 0 serveur.rpl/1171
2847 bertrand 13 5,5 0,0 0,0 72 0,0 9,0 0,3 155 13 978 0 serveur.rpl/1207
2847 bertrand 13 5,3 0,0 0,0 72 3,0 6,5 0,2 149 13 942 0 serveur.rpl/1225
2847 bertrand 13 5,5 0,0 0,0 66 1,8 13 0,3 152 13 978 0 serveur.rpl/1201
2847 bertrand 8,9 9,2 0,0 0,0 37 1,2 44 0,2 95 6 1K 0 serveur.rpl/1289
2847 bertrand 9,6 8,4 0,0 0,0 51 0,0 31 0,1 91 8 1K 0 serveur.rpl/1287
2847 bertrand 13 5,2 0,0 0,0 76 0,0 5,8 0,3 142 9 939 0 serveur.rpl/1217
2847 bertrand 13 5,0 0,0 0,0 73 2,5 6,8 0,3 143 11 940 0 serveur.rpl/1215
2847 bertrand 12 5,4 0,0 0,0 61 9,4 12 0,3 137 13 1K 0 serveur.rpl/1277
2847 bertrand 11 6,1 0,0 0,0 57 1,5 24 0,3 112 9 1K 0 serveur.rpl/1275
2847 bertrand 12 5,1 0,0 0,0 77 1,8 4,3 0,3 149 16 528 0 serveur.rpl/1223
2847 bertrand 10 6,0 0,0 0,0 60 9,1 15 0,4 116 17 983 0 serveur.rpl/1259
2847 bertrand 9,8 6,3 0,0 0,0 70 0,1 13 0,4 119 7 529 0 serveur.rpl/1195
2847 bertrand 7,8 0,0 0,0 0,0 0,0 17 76 0,0 20 2 12 0 serveur.rpl/1

Pour information, la page man de prstat stipule :

DFL

The percentage of time the process has spent processing
data page faults.

Effectivement, l'activité du swap semble anormale :

tchaikovski:[~/rpl/build/src] > iostat -Pxn
extended device statistics
r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
0.0 0.0 0.0 0.0 0.0 0.0 7.5 72.1 0 0 c0t0d0s0
0.4 0.1 3.4 12.9 0.0 0.0 0.7 26.6 0 0 c0t0d0s1
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c0t0d0s2
0.0 0.0 0.0 0.0 0.0 0.0 7.3 72.4 0 0 c0t1d0s0
0.4 0.1 3.4 12.9 0.0 0.0 0.7 26.2 0 0 c0t1d0s1
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c0t1d0s2

La taille du swap est normale (j'ai collé un volume raid1/SAS rien que
pour lui parce que je suis contraint de traiter de temps en temps
des volumes de données énormes par bloc, mais il faut que tout
tienne en mémoire... Des histoires de cartographie...). Son
utilisation ne l'est absolument pas. Il n'y a aucune raison d'avoir
un tel trafic alors même qu'il reste 3 Go de mémoire vive disponible
en continu sur cette machine.

Les données sur lesquelles tournent ce programme représentent
1 à 2 Go en fonction des calculs, mais peuvent parfaitement entrer
dans la mémoire de la machine. J'ai fait un test, le même programme
tourne parfaitement sur ma machine de développement qui est un Linux
avec 4 Go même si je désactive le swap.

La question est donc : pourquoi ce #@{#@^@^{[@#^# de Solaris
décide d'autorité de mettre en mémoire virtuelle des données qui
sont très souvent utilisées alors même qu'il reste à peu près 4 Go
de mémoire disponible ? Comment configurer la chose si c'est
possible ? Je n'ai rien trouvé de probant (sauf virer totalement le
swap, mais ce n'est pas une solution avec Solaris).

Je précise tout de suite que ce n'est pas un problème de 32 bits ou
de taille de pointeurs vu que le programme qui tourne est :

tchaikovski:[~/rpl/cvs/optimisation] > file /usr/local/bin/rpl
/usr/local/bin/rpl: ELF 64 bits MSB exécutable SPARCV9 Version 1,
avec liens dynamiques, fichier intégral

et que rien d'autre ne tourne actuellement sur cette machine qui
contraindrait des données à être mises dans le swap.

J'ai essayé un ulimit -v sans que ce soit vraiment probant. Si
quelqu'un avait une idée ou un début d'explication ou quelque chose
pour contourner le problème... sachant que ce problème commence à
m'énerver sérieusement vu qu'il ne commence à être visible qu'après
une bonne journée de temps de CPU...

Cordialement,

JKB