# [MEMOIRE] Cannot allocate memory avec plein de mémoire libre

## pums974

Bonjour,

Cela fait un moment que j'ai des problèmes mémoire, j'ai d'abord pensé que c'était dû a chromium (très consommateur) et j'ai ensuite penser à un problème matériel.

Mais je viens de tout changer (proc, ram et carte mère) et j'ai toujours les même problèmes.

Tout est dans le sujet, il me fait souvent des erreurs de type "cannot allocate memory" quand je compile chromium ou libreoffice par exemple.

Pourtant :

- Il n'utilise que 3 ou 4Go des 8Go de RAM (hors cache).

- Il n'utilise quasiment pas le swap (200Mo sur 5Go).

Autre chose qui n'a peut-être rien à voir, je ne peut pas non plus desactiver mon swap, même lorsqu'il me reste de la place en mémoire.

Par exemple : tout de suite, alors qu'un free -h me donne :

```

                  total       used       free     shared    buffers     cached

Mem:          7,8G       7,2G       599M         0B       1,0G       3,4G

-/+ buffers/cache:       2,8G       5,0G

Swap:         5,0G       174M       4,8G

```

Suis-je le seul a avoir ce genre de problèmes ?

Quelqu'un a t'il une idée de la cause ?

----------

## DuF

Bonjour,

Quelques précisions :

- Ce n'est pas parce que la mémoire "cache" est considéré comme libre qu'elle l'est, en fait on devrait plutôt la considérer comme "disponible si elle n'est pas utilisée". Donc si pour une raison ou une autre, les 3.4Go de "cache" sont utilisées et non libérables (gros fichiers ouverts, etc.) alors il ne faut pas le considérer comme de la mémoire libre.

- A partir du moment qu'il utilise un peu de swap, tu ne peux le désactiver que si les éléments mis en swap ne sont plus utilisés. S'il a mis en swap des éléments en cours d'utilisation ou appartenant à un process en cours d'exécution qui a marqué ces éléments comme non libérables le système peut ne pas t'autoriser à désactiver ton swap. C'est la même approche que lorsqu'on veut démonter un FS alors qu'un process accède toujours à des éléments du FS, il faut d'abord arrêter les opérations sur le FS pour le libérer.

Si je me souviens d'une discussion précédente, on se retrouve là, à la fois pour la mémoire et pour le swap, dans des cas particuliers.

J'aurai donc tendance à penser que tu as de la mémoire fortement utilisée et très peu de libre. Il faudrait donc identifier qui consomme de la mémoire :

La commande top (ou htop) peut aider avec classement par mémoire consommée et reste à faire les comptes sur les mémoires RSS et VSZ. Normalement tu devrais retomber sur les éléments qui font que le système te refuse de libérer le swap ou t’indique que tu n'as plus de mémoire à allouer disponible.

@+

----------

## pums974

Bonjour, merci d'avoir répondu

La remarque sur le SWAP n'est peut être pas lié à mon problème.

Cependant je ne comprend toujours pas pourquoi je ne peut pas compiler libroffice ou chromium avec mes 8G de RAM. Ca me semble pourtant largement suffisant...

Je viens de récupérer l'évolution de la mémoire au cour de la compilation :

- Il me reste toujours plus de 100Mo de dispo

- Il n'utilise pas de SWAP (20Mo d'alloué, du début à la fin)

Et toujours un crash Cannot allocate memory.

Peut être utilise trop de cache, comment peut-on limiter ?

Ou comment le forcer a utiliser le swap ?

----------

## Poussin

Tu fais du tmpfs?

----------

## DuF

 *pums974 wrote:*   

> Bonjour, merci d'avoir répondu
> 
> La remarque sur le SWAP n'est peut être pas lié à mon problème.
> 
> Cependant je ne comprend toujours pas pourquoi je ne peut pas compiler libroffice ou chromium avec mes 8G de RAM. Ca me semble pourtant largement suffisant...

 

On peut le dire, j'ai moitié moins et aucun problème pour compiler ces 2 programmes. Maintenant dire ça ne fait pas avancer l'histoire.

 *pums974 wrote:*   

> Je viens de récupérer l'évolution de la mémoire au cour de la compilation :
> 
> - Il me reste toujours plus de 100Mo de dispo
> 
> - Il n'utilise pas de SWAP (20Mo d'alloué, du début à la fin)

 

Quand tu parles d'évolution, je suppose que tu parles des activités de type si/so et bi/bo remontés par une commande vmstat par exemple. Parce que suivre l'espace disponible/occupé n'a aucun intérêt et ne montre en rien l'activité mémoire. Tu peux très bien avoir 100mo de disponible pendant une heure alors que pendant cette même heure des Go voir To ont été échangés en mémoire.

 *pums974 wrote:*   

> Et toujours un crash Cannot allocate memory.

 

Un petit copié/collé de la sortie d'erreur serait pas mal, ne serait-ce que pour savoir à quel moment ça arrive.

 *pums974 wrote:*   

> Peut être utilise trop de cache, comment peut-on limiter ?
> 
> Ou comment le forcer a utiliser le swap ?

 

Encore une fois, il n'utilise la mémoire cache que si possible et si besoin, si tu as besoin de mémoire, la cache est la première à partir en swap. Sauf si tu as touché aux éléments du noyau qui modifient le comportement par défaut, mais dans ce cas on risque fort de ne pouvoir t'aider. 

Je ne vois pas l'intérêt de le forcer à utiliser la mémoire swap car par défaut s'il a besoin de mémoire il l'utilisera. S'il ne le fait pas c'est que le problème est en amont, avant même qu'il se dise : "tiens je vais tout copier en swap".

Poussin pose la question du tmpfs, en soit avoir un tmpfs n'est pas rédhibitoire et portage vérifie l'espace de /var/tmp/portage : 

```
>>> Running pre-merge checks for app-office/libreoffice-3.5.6.2

 * Checking for at least 512 mebibytes RAM ...                                                                              [ ok ]

 * Checking for at least 6 gibibytes disk space at "/var/tmp/portage/app-office/libreoffice-3.5.6.2/temp" ...               [ ok ]

```

Mais vu que libreoffice et chromium prennent beaucoup de place en source c'est une piste à creuser.

----------

## scherz0

 *DuF wrote:*   

> 
> 
> - Ce n'est pas parce que la mémoire "cache" est considéré comme libre qu'elle l'est, en fait on devrait plutôt la considérer comme "disponible si elle n'est pas utilisée". Donc si pour une raison ou une autre, les 3.4Go de "cache" sont utilisées et non libérables (gros fichiers ouverts, etc.) alors il ne faut pas le considérer comme de la mémoire libre.
> 
> 

 

Confusion entre "cache" et "buffers" ?

----------

## DuF

 *scherz0 wrote:*   

>  *DuF wrote:*   
> 
> - Ce n'est pas parce que la mémoire "cache" est considéré comme libre qu'elle l'est, en fait on devrait plutôt la considérer comme "disponible si elle n'est pas utilisée". Donc si pour une raison ou une autre, les 3.4Go de "cache" sont utilisées et non libérables (gros fichiers ouverts, etc.) alors il ne faut pas le considérer comme de la mémoire libre.
> 
>  
> ...

 

Pourquoi donc, il me semble qu'avec mon exemple des fichiers ouverts il est certain que je parle de la "cached" ? Mais effectivement j'aurai sans doute dû maintenir le terme "cached" de la commande "free" pour assurer que je parle bien de cet élément.

On parle donc de la mémoire cache souvent dites "FS" indiquée par la commande "free -h" qu'il a exécuté et qui de manière générale correspond aux transferts vers et depuis le disque dur. Après c'est sûr qu'on peut parler de la mémoire qui sert comme cache de manière globale au système et là on devrait faire la somme de "buffers" et "cached" mais (dans mon esprit) je trouve que ça porterait encore plus à confusion.

Pour résumer, et c'est tout l'intérêt de la commande free qui ajoute la ligne "-/+ buffers/cache", la mémoire indiquée dans les zones "buffers" et "cached" est considéré par le système comme disponible.

Dans son cas le système lui dit qu'il a 5Go de libre dont 4.4Go est "potentiellement disponible", je pense donc que le problème est ailleurs  :Smile: 

NB : Je ne suis pas persuadé d'être bon pédagogue ceci pouvant expliquer cela  :Smile: 

----------

## pums974

 *Poussin wrote:*   

> Tu fais du tmpfs?

 

Non, du moins par pour mon /tmp (en revanche, c'est le cas pour /run, /dev/shm et /sys/fs/cgroup)

 *Quote:*   

> Quand tu parles d'évolution, je suppose que tu parles des activités de type si/so et bi/bo remontés par une commande vmstat par exemple. Parce que suivre l'espace disponible/occupé n'a aucun intérêt et ne montre en rien l'activité mémoire. Tu peux très bien avoir 100mo de disponible pendant une heure alors que pendant cette même heure des Go voir To ont été échangés en mémoire. 

 

Oui effectivement, mais je ne regardais que l'évolution de l'utilisation mémoire, pour voir si, quand j'ai le dos tourné, il utilisait toute la mémoire au point d'en manquer, mais ce n'est pas le cas.

 *Quote:*   

> Un petit copié/collé de la sortie d'erreur serait pas mal, ne serait-ce que pour savoir à quel moment ça arrive. 

 

Le problème c'est que c'est très variable.

Par exemple pour libreoffice j'obtiens ca :

```

Error occurred during initialization of VM

Could not reserve enough space for object heap

Could not create the Java virtual machine.

```

Mais à chaque compilation, c'est à un moment différent :

par exemple :

```

ERROR: error 512 occurred while making /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/tail_build/prj

```

Ou alors :

```

ERROR: error 65280 occurred while making /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/extras/source/gallery/accessories/Photos/Celebration

ERROR: error 512 occurred while making /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/ridljar/prj

ERROR: error 512 occurred while making /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/l10ntools/prj

ERROR: error 65280 occurred while making /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/saxon

```

Pour chromium ce sera plutot

```

virtual memory exhausted: Ne peut allouer de la mémoire

```

Et pareil a des moments différents.

Sinon ca peut aussi être sandbox qui se plain pendant la compil (mais j'ai pas le message d'erreur sous la main, mais ca contient "Cannot allocate memory")

Ou alors un programme qui tourne en même temps (gros ou petit) qui vas crasher avec quelquechose du type

```

fork: Cannot allocate memory

```

Encore une fois c'est très variable mais ca tourne toujours autour de la même chose : Ne peut allouer de la mémoire

----------

## DuF

A la limite on peut essayer de déterminer ce que le système pourrait libérer sur ta machine. Que donne la commande free avant et après avoir forcé le vidage de la mémoire "cached" ?

```
echo 3 > /proc/sys/vm/drop_caches
```

EDIT : j'ai oublié de dire qu'après faut le remettre à zéro  :Wink: 

----------

## pums974

Donc là, j'ai killer gdm et toute ma session (je suis sur une machine distante)

je viens de retenter de compiler libreoffice, sans succé (ce qui m'a donné le message d'erreur dont je parlais dans mon message précedant)

J'ai maintenant :

```
free -h

             total       used       free     shared    buffers     cached

Mem:          7,8G       5,4G       2,4G         0B       498M       3,9G

-/+ buffers/cache:       1,0G       6,8G

Swap:         5,0G        26M       5,0G

```

Suite au drop_caches:

```
free -h

             total       used       free     shared    buffers     cached

Mem:          7,8G       239M       7,6G         0B       484K        14M

-/+ buffers/cache:       224M       7,6G

Swap:         5,0G        26M       5,0G
```

Et ca remonte rapidement

```
free -h

             total       used       free     shared    buffers     cached

Mem:          7,8G       621M       7,2G         0B       3,9M       392M

-/+ buffers/cache:       224M       7,6G

Swap:         5,0G        26M       5,0G
```

Maintenant je ne peut plus le mettre a 0

```
echo 0 > /proc/sys/vm/drop_caches

-bash: echo: erreur d'écriture : Argument invalide
```

----------

## DuF

 *pums974 wrote:*   

> Donc là, j'ai killer gdm et toute ma session (je suis sur une machine distante)
> 
> je viens de retenter de compiler libreoffice, sans succé (ce qui m'a donné le message d'erreur dont je parlais dans mon message précedant)
> 
> J'ai maintenant :
> ...

 

Quand tu tentes de compiler libreoffice avec les + de 7Go de libre ça te mets la même erreur ?

Pour le echo 0 qui échoue, quelle est ta version du noyau et drop_caches est à quelle valeur actuellement ? Sinon la modification n'étant pas persistante au prochain reboot il sera remis à sa valeur par défaut.

Si on prend le problème de libreoffice, c'est lorsqu'il veut lancer une JVM, ne compilant pas libreoffice avec java, je ne sais pas combien de place il essaie de prendre. Indique-t-il la taille qu'il souhaite allouer quand il créé la HEAP ?

Sinon quels sont tes paramètres de compilation (CFLAGS, makeopts, etc.) ?

@+

----------

## pums974

 *Quote:*   

> Quand tu tentes de compiler libreoffice avec les + de 7Go de libre ça te mets la même erreur ? 

 

Oui

 *Quote:*   

> quelle est ta version du noyau et drop_caches est à quelle valeur actuellement ?

 

Mon noyau est un 3.5.4 et drop_caches est resté à 3

 *Quote:*   

> Indique-t-il la taille qu'il souhaite allouer quand il créé la HEAP ? 

 

Non

Mon emerge --info est le suivant

```
Portage 2.1.11.23 (default/linux/amd64/10.0/desktop, gcc-4.6.3, glibc-2.15-r3, 3.5.4-gentooPerso x86_64) 

================================================================= 

System uname: Linux-3.5.4-gentooPerso-x86_64-Intel-R-_Core-TM-_i7-2600_CPU_@_3.40GHz-with-gentoo-2.2 

Timestamp of tree: Sun, 30 Sep 2012 11:45:01 +0000 

ccache version 3.1.8 [disabled] 

app-shells/bash:          4.2_p37 

dev-java/java-config:     2.1.12 

dev-lang/python:          2.7.3-r2, 3.2.3-r1 

dev-util/ccache:          3.1.8 

dev-util/cmake:           2.8.9 

dev-util/pkgconfig:       0.27.1 

sys-apps/baselayout:      2.2 

sys-apps/openrc:          0.10.5 

sys-apps/sandbox:         2.6 

sys-devel/autoconf:       2.13, 2.69 

sys-devel/automake:       1.9.6-r3, 1.10.3, 1.11.6, 1.12.4 

sys-devel/binutils:       2.22.90 

sys-devel/gcc:            4.6.3 

sys-devel/gcc-config:     1.7.3 

sys-devel/libtool:        2.4.2 

sys-devel/make:           3.82-r4::gnome 

sys-kernel/linux-headers: 3.5 (virtual/os-headers) 

sys-libs/glibc:           2.15-r3 

Repositories: gentoo desktop-effects eva gamerlay-stable games kde laurentb multimedia portato retroshare-overlay science systemd ubuntu voyageur x11 vmware virtualization qt mozilla kvm kde-sunset gentoo-guis gnome Local 

ACCEPT_KEYWORDS="amd64 ~amd64" 

ACCEPT_LICENSE="*" 

CBUILD="x86_64-pc-linux-gnu" 

CFLAGS="-march=native -O2 -pipe " 

CHOST="x86_64-pc-linux-gnu" 

CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/openvpn/easy-rsa" 

CONFIG_PROTECT_MASK="${EPREFIX}/etc/gconf /etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" 

CPPFLAGS="-march=native -O2 -pipe " 

CXXFLAGS="-march=native -O2 -pipe " 

DISTDIR="/usr/portage/tree/../distfiles" 

EMERGE_DEFAULT_OPTS="--complete-graph y --with-bdeps y --autounmask y --misspell-suggestions y -D" 

FCFLAGS="-O2 -pipe" 

FEATURES="assume-digests binpkg-logs candy config-protect-if-modified distlocks ebuild-locks fixlafiles metadata-transfer news parallel-fetch parallel-install protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch usersandbox xattr" 

FFLAGS="-O2 -pipe" 

GENTOO_MIRRORS="ftp://ftp.free.fr/mirrors/ftp.gentoo.org/ http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" 

LANG="fr_FR.UTF-8" 

LDFLAGS="-Wl,-O1 -Wl,--as-needed " 

LINGUAS="fr en" 

PKGDIR="/usr/portage/tree/../packages" 

PORTAGE_COMPRESS="bzip2" 

PORTAGE_COMPRESS_FLAGS="-9" 

PORTAGE_CONFIGROOT="/" 

PORTAGE_RSYNC_EXTRA_OPTS="" 

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" 

PORTAGE_TMPDIR="/var/tmp" 

PORTDIR="/usr/portage/tree" 

PORTDIR_OVERLAY="/var/lib/layman/desktop-effects /var/lib/layman/eva /var/lib/layman/gamerlay /var/lib/layman/games /var/lib/layman/kde /var/lib/layman/laurentb /var/lib/layman/multimedia /var/lib/layman/portato /var/lib/layman/retroshare-overlay /var/lib/layman/science /var/lib/layman/systemd /var/lib/layman/ubuntu /var/lib/layman/voyageur /var/lib/layman/x11 /var/lib/layman/vmware /var/lib/layman/virtualization /var/lib/layman/qt /var/lib/layman/mozilla /var/lib/layman/kvm /var/lib/layman/kde-sunset /var/lib/layman/gentoo-guis /var/lib/layman/gnome /usr/portage/local" 

SYNC="rsync://rsync.fr.gentoo.org/gentoo-portage" 

USE="32bit 64bit X a52 aac acl acpi alsa amd64 apache2 apm avahi bash-completion berkdb branding btrfs bzip2 cairo cli colord consolekit cxx dbus directfb dri emboss encode exif fam fat fbcon fbcondecor ffmpeg fftw firefox flac fontconfig fortran g3dvl gdbm gif git glew gnome gnome-keyring gpm gsl gstreamer gtk gtk3 iconv icu introspection ipv6 java joystick jpeg kde lcms libnatspec libnotify lm_sensors lto lzma mad minimal mmx mmxext mng modules mp3 mp4 mpeg mpi mpi-threads mudflap multilib mysql nautilus ncurses networkmanager nls nptl nsplugin nspluginwrapper ntfs nvidia offensive ogg opencl opengl openmp openvg pam pango pcre pdf pdo phonon php plasma pmu png policykit ppds pppd pulseaudio python python3 qt3support qt4 readline sdl semantic-desktop session smp spell sql sqlite sqlite3 sse sse2 sse3 sse4 sse4_1 sse4_2 ssl ssse3 startup-notification svg system-sqlite systemd tcpd theora threads tiff truetype udev udisks unicode upnp upower usb vdpau vorbis wayland webgl webkit wxwidgets x264 xattr xcb xinerama xml xulrunner xv xvid xvmc zeitgeist zeroconf zlib zsh-completion" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="flow karbon krita sheets stage words" ELIBC="glibc" GRUB_PLATFORMS="pc efi-64" INPUT_DEVICES="evdev mouse keyboard" KERNEL="linux" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="fr en" PHP_TARGETS="php5-3 php5-4" PYTHON_TARGETS="python3_2 python2_7" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby19" SANE_BACKENDS="lexmark" USERLAND="GNU" VIDEO_CARDS="nvidia fglrx" 

Unset:  CTARGET, INSTALL_MASK, LC_ALL, MAKEOPTS, PORTAGE_BUNZIP2_COMMAND, USE_PYTHON 
```

De plus, on m'as fait remarquer que /proc/buddyinfo montrais que ma mémoire etait particulièrement fragmenté (https://forums.gentoo.org/viewtopic-p-7151920.html#7151920, je suis désolé mais n'ayant pas eu de réponse à mon premier post avant dimanche, je me suis permis de poster dans la section anglaise...)

Cela peut éventuellement faire parti de la source du problème.

----------

## pums974

 *Quote:*   

> Cela peut éventuellement faire parti de la source du problème.

 

Je viens de remarquer que, quelques heures plus tard, les valeurs du buddyinfo sont revenu à la normale.

Du coup, c'est peut-être pas la source du problème mais un effet collateral.

----------

## DuF

Tu as bien fait de poser ta question sur le forum anglophone, la première réponse est intéressante (sur l'adressage d'une machine 32 bits).

Peux-tu tenter de compiler libreoffice sans le USE java juste histoire de savoir si le problème d'allocation est lié au démarrage de la heap ou si c'est autre chose.

Pour la fragmentation pourquoi pas, mais t'as quand même 7go de mémoire libre lors de certains tests, donc même si c'est fragmenté cela parait incongru que cela en soit la cause.

Sinon pourrais-tu tenter en fixant la variable makeopts à : MAKEOPTS="-j2" ?

Enfin, aurais-tu un kernel plus ancien (idéalement 3.2.x vu qu'elle est réputé stable, c'est pas moi qui le dit c'est Pat) pour tester ? 

@+

----------

## Poussin

Ca n'a plus que probablement aucun rapport, mais il y a une raiso particulière d'utiliser make de l'overlay gnome?

Perso, concernant MAKEOPTS, j'aurais plutôt dit de diminuer la valeur, mais vu que ce n'était pas défini... (étonnant avec un i7)

C'est bien étrange

----------

## pums974

 *Quote:*   

> Ca n'a plus que probablement aucun rapport, mais il y a une raiso particulière d'utiliser make de l'overlay gnome? 

 

Non pas de raison particulière, c'est juste que j'ai mis cet overlay pour avoir gnome 3 a l'époque et 3.4 maintenant et je n'ai pas fais le tri entre ce que j'y prend et ce que j'y prend pas.

 *Quote:*   

> Sinon pourrais-tu tenter en fixant la variable makeopts à : MAKEOPTS="-j2" ? 

 

J'ai essayer avec -j9 (j'ai 8 coeurs logiques) et sans fixer MAKEOPTS (d'où le make.conf) donc avec -j1. Même conclusions.

 *Quote:*   

> Enfin, aurais-tu un kernel plus ancien pour tester ? 

 

Euh non pas sous la main, mais c'est quelque chose que j'observe depuis très longtemps (au moins 1an). Mais comme je pensait que c’était un problème matériel, je m'en suis pas inquiété plus tôt.

----------

## geekounet

LO et Chrome ont des sources C++ qui peuvent prendre plusieurs GiB de ram pour compiler (oui le C++ c'est très gourmand à la compilation), donc si t'as un -jX élevé et que plusieurs compilations du genre se font en même temps, t'as vite saturé ta RAM, donc il faut le mettre à une valeur plus basse.

----------

## Poussin

Mais il est déjà à 1 (c'est bien la valeur par défaut quand MAKEOPTS n'est pas set?!) :/

----------

## scherz0

 *DuF wrote:*   

> 
> 
> Pourquoi donc, il me semble qu'avec mon exemple des fichiers ouverts il est certain que je parle de la "cached" ? Mais effectivement j'aurai sans doute dû maintenir le terme "cached" de la commande "free" pour assurer que je parle bien de cet élément.
> 
> 

 

Les 3.4Go dont tu parlais sont dans la catégorie cached, c'est à dire disponibles.  Ça ne correspond pas à de la mémoire "utilisée et non libérable" comme indiqué dans ton premier message.  Les fichiers ouverts que tu mentionnais sont classés dans buffers, pas dans cached.

----------

## DuF

 *scherz0 wrote:*   

>  *DuF wrote:*   
> 
> Pourquoi donc, il me semble qu'avec mon exemple des fichiers ouverts il est certain que je parle de la "cached" ? Mais effectivement j'aurai sans doute dû maintenir le terme "cached" de la commande "free" pour assurer que je parle bien de cet élément.
> 
>  
> ...

 

Oula... 

Dans mon premier message (vu qu'a priori c'est de ça dont il est question) je commence par dire que la mémoire "cache" est considéré comme libre mais qu'il me parait plus juste de la considérer comme "disponible si elle n'est pas utilisée" car tout dépend de l'activité à un instant T. Donc faut que tu m'expliques où tu comprends que j'associe cette mémoire à de la mémoire "utilisée non libérable" et si tel était mon raisonnement pourquoi j'indiquerai une commande qui permette de vider "les" caches mémoires ? D'un côté je dirai qu'elle n'est pas libérable et de l'autre je donnerai une commande pour la libérer ???  :Shocked: 

Pas très correcte tout ça, venir reprendre quelqu'un pourquoi pas mais si je ne peux pas répondre sans faire de raccourcis ou en devant citer les appels noyaux, le comportement de malloc... ça va être compliqué. Mais bon je peux éditer mon premier message pour corriger que la mémoire "cache" considérée comme libre, que j'estime plutôt "disponible si non utilisée" ne peut en aucun cas être qualifiée de "utilisée et non libérable".

Et non les fichiers ouverts ne sont pas classés dans "buffers", tout du moins ce n'est pas aussi simple et pour le coup c'est un raccourci aussi gros que ceux que j'utilise :

- buffers => fonctionnement en fifo (à vérifier pour les noyaux linux actuels mais ça doit toujours être du type données en file d'attente). Ce sont des données en attente (dans un espace temporaire) qu'un processus qui en a besoin travaille avec et envoi ces données traités ailleurs (autre zone mémoire, disque, réseau...)

- cached => fonctionnement par vieillissement/utilisation des données dont le but premier est la performance en mettant à disposition des données fréquemment sollicités en mémoire afin d'éviter les accès disques avec par exemple un mécanisme de prefetch (ou read-ahead). On parle souvent de cache disque/FS.

Si on veut être précis, faut aller regarder dans le code noyau actuel, moi j'admets volontiers que mes références datent du noyau 2.6.x.

Sinon pour revenir au sujet je dirai :

- je ferai un test avec MAKEOPTS à -j2, vu que c'est celle qu'on met pour un coeur. Sauf si le test sans fixer MAKEOPTS garanti qu'il n'y avait pas plusieurs compilations en parallèle comme le dit geekounet.

- pour le drop_caches je m'excuse mais je viens de voir qu'en noyau 3.x il est préconisé de faire un "sync" avant alors qu'en 2.6.x c'était pas utile. A retenir pour une prochaine fois.

----------

## pums974

 *Quote:*   

> LO et Chrome ont des sources C++ qui peuvent prendre plusieurs GiB de ram pour compiler (oui le C++ c'est très gourmand à la compilation), donc si t'as un -jX élevé et que plusieurs compilations du genre se font en même temps, t'as vite saturé ta RAM, donc il faut le mettre à une valeur plus basse.

 

J'en suis bien conscient, c'est pour ca qu'un de mes premiers test a consisté à enlever cette option.

 *Quote:*   

> Mais il est déjà à 1 (c'est bien la valeur par défaut quand MAKEOPTS n'est pas set?!) :/

 

Si, j'ai verifié, la commande lancé par emerge (dans le cas de LO en tout cas) est `make -j1 -jX ...` du coup quand c'est pas set c'est -j1 qui est pris en compte sinon -jX.Last edited by pums974 on Mon Oct 01, 2012 11:13 pm; edited 1 time in total

----------

## DuF

 *pums974 wrote:*   

>  *Quote:*   Mais il est déjà à 1 (c'est bien la valeur par défaut quand MAKEOPTS n'est pas set?!) :/ 
> 
> Si j'ai verifié, la commande lancé par emerge (dans le cas de LO) est `make -j1 -jX ...` du coup quand c'est pas set c'est -j1 qui est pris en compte sinon -jX

 

On va finir par être à sec d'idée  :Laughing: 

As-tu tester avec un noyau plus ancien (famille 3.2.x vu que Patrick Volkerding les considère comme stables   :Wink:  ) ou un noyau dont tu peux être sûr qu'il est stable et/ou sans fioritures (pas de trucs verbeux ou en debug) ?

----------

## pums974

 *Quote:*   

> As-tu tester avec un noyau plus ancien

 

Non, mais c'est un problème que j'ai depuis longtemps (je l'avais déjà avec la famille 2.6*). Comme je pensais que c'étais un problème matériel ce n'avais jamais creusé.

 *Quote:*   

> un noyau dont tu peux être sûr qu'il est stable

 

Non plus, mais je vais reconf mon kernel à partir d'un seed ce WE.

En esperant que faire le ménage dans certaines options que j'aurais activé pour rien fasse avancer le shmilblik.

Cette nuit j'ai vérifié que mon .config n'etais pas absurde (au sens ou, un soir, bourré, je l'aurais modifié à la main et oublié le lendemain) donc je suis parti d'un seed kernel et j'ai réactivé toutes les options de la précédante config. J'en ai profiter pour desactiver tous les _debug et _verbose.

Tout ceci n'ayant eu aucun effet sur mon problème.

----------

## DuF

 *pums974 wrote:*   

> Cette nuit j'ai vérifié que mon .config n'etais pas absurde (au sens ou, un soir, bourré, je l'aurais modifié à la main et oublié le lendemain) donc je suis parti d'un seed kernel et j'ai réactivé toutes les options de la précédante config. J'en ai profiter pour desactiver tous les _debug et _verbose.
> 
> Tout ceci n'ayant eu aucun effet sur mon problème.

 

Je viens de voir dans ton autre sujet en anglais des éléments aussi sur le kernel mais a priori sans succès de résolution. Un truc rapide pourrait être de faire un noyau avec genkernel.

Et sinon la compilation de LO sans java ça fait pareil ?

----------

## pums974

 *Quote:*   

> Et sinon la compilation de LO sans java ça fait pareil ?

 

Oui, oui, tout pareil. D'abord, j'ai ca qui apparait :

```
>>> Jobs: 0 of 1 complete, 1 failed                 Load avg: 4.41, 3.97, 2.54(null)*(null) ../../sandbox-2.6/libsandbox/libsandbox.c:resolve_path():184: failure (Ne peut allouer de la mémoire)
```

Ensuite il y a la sortie du merge qui fini comme ca :

```

...

[ build CXX ] xmlsecurity/source/framework/xmlsignaturetemplateimpl.cxx

[ build CXX ] xmlsecurity/source/framework/xsec_framework.cxx

/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/bin/idlc: starting preprocessor failed

virtual memory exhausted: Ne peut allouer de la mémoire

virtual memory exhausted: Ne peut allouer de la mémoire

virtual memory exhausted: Ne peut allouer de la mémoire

/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/as: out of memory allocating 524411 bytes after a total of 0 bytes

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/hwpfilter/source/hwpfile.o] Erreur 1

make[2]: *** Attente des tâches non terminées....

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/shell/source/backends/kde4be/kde4access.o] Erreur 1

/usr/lib64/libsandbox.so(+0xb931)[0x7f81e29c1931]

/usr/lib64/libsandbox.so(+0xb931)[0x7fd614ebd931]

/usr/lib64/libsandbox.so(+0xba2d)[0x7fd614ebda2d]

/usr/lib64/libsandbox.so(+0xba2d)[0x7f81e29c1a2d]

/usr/lib64/libsandbox.so(+0xc47f)[0x7fd614ebe47f]

/usr/lib64/libsandbox.so(+0xc47f)[0x7f81e29c247f]

/usr/lib64/libsandbox.so(+0x4615)[0x7fd614eb6615]

/usr/lib64/libsandbox.so(+0x4615)[0x7f81e29ba615]

/usr/lib64/libsandbox.so(+0x5211)[0x7fd614eb7211]

/usr/lib64/libsandbox.so(+0x5211)[0x7f81e29bb211]

/usr/lib64/libsandbox.so(open+0x94)[0x7fd614eb9a14]

/usr/lib64/libsandbox.so(open+0x94)[0x7f81e29bda14]

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/UnoApiPartTarget/oovbaapi/ooo/vba/msforms/idl.done] Erreur 99

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/configmgr/source/configurationprovider.o] Erreur 1

/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1plus[0xbfe2f9]

/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1plus[0xbfe2f9]

/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1plus(_cpp_find_file+0x443)[0xbff323]

/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1plus(_cpp_find_file+0x443)[0xbff323]

/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1plus(_cpp_stack_include+0x40)[0xbffb20]

/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1plus(_cpp_stack_include+0x40)[0xbffb20]

/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1plus[0xbf7b91]

/proc/16893/cmdline: /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1plus -quiet -I /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/sdext/source/presenter/ -I /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/inc/external -I /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/inc -I /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solenv/inc -I /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/inc/offapi -I /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/inc/udkapi -MMD /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/sdext/source/presenter/PresenterPaneContainer.d -MF /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/Dep/CxxObject/sdext/source/presenter/PresenterPaneContainer.d_ -MP -MT /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/sdext/source/presenter/PresenterPaneContainer.o -D_GNU_SOURCE -DCPPU_ENV=gcc3 -DENABLE_GRAPHITE -DENABLE_GTK -DENABLE_KDE4 -DGCC -DGXX_INCLUDE_PATH=/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4 -DHAVE_GCC_VISIBILITY_FEATURE -DHAVE_THREADSAFE_STATICS -DLINUX -DNDEBUG -DOPTIMIZE -DOSL_DEBUG_LEVEL=0 -DSUPD=360 -DUNIX -DUNX -DX86_64 -D_PTHREADS -D_REENTRANT -DPRESENTER_IMPL_IDENTIFIER="com.sun.PresenterScreen-linux_x86_64" -DLIBO_MERGELIBS -DEXCEPTIONS_ON /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/sdext/source/presenter/PresenterPaneContainer.cxx -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mavx -msse4.2 -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=corei7-avx -quiet -dumpbase PresenterPaneContainer.cxx -auxbase-strip /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/sdext/source/presenter/PresenterPaneContainer.o -O2 -O2 -Wall -Wendif-labels -Wextra -Wshadow -Wsign-promo -Woverloaded-virtual -Wnon-virtual-dtor -std=gnu++0x -fmessage-length=0 -fno-common -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fexceptions -fno-enforce-eh-specs -o - 

/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1plus[0xbf7b91]

/proc/16753/cmdline: /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1plus -quiet -I /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/sdext/source/presenter/ -I /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/inc/external -I /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/inc -I /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solenv/inc -I /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/inc/offapi -I /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/inc/udkapi -MMD /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/sdext/source/presenter/PresenterWindowManager.d -MF /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/Dep/CxxObject/sdext/source/presenter/PresenterWindowManager.d_ -MP -MT /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/sdext/source/presenter/PresenterWindowManager.o -D_GNU_SOURCE -DCPPU_ENV=gcc3 -DENABLE_GRAPHITE -DENABLE_GTK -DENABLE_KDE4 -DGCC -DGXX_INCLUDE_PATH=/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4 -DHAVE_GCC_VISIBILITY_FEATURE -DHAVE_THREADSAFE_STATICS -DLINUX -DNDEBUG -DOPTIMIZE -DOSL_DEBUG_LEVEL=0 -DSUPD=360 -DUNIX -DUNX -DX86_64 -D_PTHREADS -D_REENTRANT -DPRESENTER_IMPL_IDENTIFIER="com.sun.PresenterScreen-linux_x86_64" -DLIBO_MERGELIBS -DEXCEPTIONS_ON /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/sdext/source/presenter/PresenterWindowManager.cxx -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mavx -msse4.2 -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=corei7-avx -quiet -dumpbase PresenterWindowManager.cxx -auxbase-strip /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/sdext/source/presenter/PresenterWindowManager.o -O2 -O2 -Wall -Wendif-labels -Wextra -Wshadow -Wsign-promo -Woverloaded-virtual -Wnon-virtual-dtor -std=gnu++0x -fmessage-length=0 -fno-common -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fexceptions -fno-enforce-eh-specs -o - 

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/sdext/source/presenter/PresenterPaneContainer.o] Erreur 2

In file included from /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/inc/com/sun/star/uno/Any.h:31:0,

                 from /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/inc/udkapi/com/sun/star/lang/WrappedTargetException.hdl:7,

                 from /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/inc/udkapi/com/sun/star/beans/XPropertySet.hdl:8,

                 from /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/inc/udkapi/com/sun/star/beans/XPropertySet.hpp:6,

                 from /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/sdext/source/presenter/PresenterBitmapContainer.hxx:32,

                 from /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/sdext/source/presenter/PresenterTheme.hxx:32,

                 from /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/sdext/source/presenter/PresenterPaneContainer.hxx:32,

                 from /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/sdext/source/presenter/PresenterWindowManager.hxx:32,

                 from /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/sdext/source/presenter/PresenterWindowManager.cxx:32:

/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/inc/uno/any2.h:32:0: erreur interne du compilateur: Abandon

Veuillez soumettre un rapport complet d'anomalies,

avec le source pré-traité si nécessaire.

Consultez <http://bugs.gentoo.org/> pour plus de détail.

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/sdext/source/presenter/PresenterWindowManager.o] Erreur 1

/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/bin/idlc: starting preprocessor failed

/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/bin/idlc: starting preprocessor failed

/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/bin/idlc: starting preprocessor failed

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/UnoApiPartTarget/oovbaapi/ooo/vba/word/idl.done] Erreur 99

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/UnoApiPartTarget/oovbaapi/ooo/vba/powerpoint/idl.done] Erreur 59

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/UnoApiPartTarget/oovbaapi/ooo/vba/office/idl.done] Erreur 99

/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/solver/unxlngx6.pro/bin/idlc: starting preprocessor failed

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/UnoApiPartTarget/oovbaapi/ooo/vba/excel/idl.done] Erreur 99

virtual memory exhausted: Ne peut allouer de la mémoire

virtual memory exhausted: Ne peut allouer de la mémoire

virtual memory exhausted: Ne peut allouer de la mémoire

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/package/source/xstor/register.o] Erreur 1

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/shell/source/backends/gconfbe/gconfbackend.o] Erreur 1

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/package/source/xstor/ocompinstream.o] Erreur 1

virtual memory exhausted: Ne peut allouer de la mémoire

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/sdext/source/presenter/PresenterScrollBar.o] Erreur 1

virtual memory exhausted: Ne peut allouer de la mémoire

virtual memory exhausted: Ne peut allouer de la mémoire

virtual memory exhausted: Ne peut allouer de la mémoire

virtual memory exhausted: Ne peut allouer de la mémoire

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/sdext/source/presenter/PresenterSlideSorter.o] Erreur 1

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/sdext/source/presenter/PresenterTextView.o] Erreur 1

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/configmgr/source/broadcaster.o] Erreur 1

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/package/source/xstor/owriteablestream.o] Erreur 1

virtual memory exhausted: Ne peut allouer de la mémoire

cc1plus: out of memory allocating 16384 bytes after a total of 4603904 bytes

virtual memory exhausted: Ne peut allouer de la mémoire

virtual memory exhausted: Ne peut allouer de la mémoire

virtual memory exhausted: Ne peut allouer de la mémoire

virtual memory exhausted: Ne peut allouer de la mémoire

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/sdext/source/presenter/PresenterSlidePreview.o] Erreur 1

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/sdext/source/presenter/PresenterUIPainter.o] Erreur 1

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/lingucomponent/source/lingutil/lingutil.o] Erreur 1

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/configmgr/source/update.o] Erreur 1

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/configmgr/source/writemodfile.o] Erreur 1

make[2]: *** [/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CxxObject/package/source/xstor/xstorage.o] Erreur 1

rm /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/dict_word.brk /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/edit_word.brk /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/sent.brk /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/count_word.txt /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/count_word_fi.txt /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/dict_word_fi.brk /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/ExternalHeaders/Library/libXrender.so /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/count_word_fi.brk /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/ExternalHeaders/Library/libm.so /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/dict_word_ca.txt /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/line.brk /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/ExternalHeaders/Library/libSM.so /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/dict_word_ca.brk /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/char_in.txt /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/dict_word.txt /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/char_in.brk /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/char.brk /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/ExternalHeaders/Library/libX11.so /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/ExternalHeaders/Library/libGL.so /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/char.txt /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/count_word.brk /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/dict_word_fi.txt /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/dict_word_prepostdash.txt /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/ExternalHeaders/Library/libICE.so /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/dict_word_nodash.brk /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/dict_word_he.txt /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/dict_word_prepostdash.brk /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/edit_word_he.txt /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/line.txt /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/ExternalHeaders/Library/libXext.so /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/dict_word_hu.txt /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/sent.txt /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/ExternalHeaders/StaticLibrary/libxmlsec1-nss.a /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/edit_word_hu.brk /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/dict_word_he.brk /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/dict_word_hu.brk /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/edit_word_he.brk /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/ExternalHeaders/StaticLibrary/libxmlsec1.a /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/dict_word_nodash.txt /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/ExternalHeaders/Library/libGLU.so /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/edit_word_hu.txt /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/workdir/unxlngx6.pro/CustomTarget/i18npool/breakiterator/edit_word.txt

make[2] : on quitte le répertoire « /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/tail_build »

-----------------------------------------------------------------------

        Oh dear - something failed during the build - sorry !

  For more help with debugging build errors, please see the section in:

            http://wiki.documentfoundation.org/Development

  internal build errors:

ERROR: error 512 occurred while making /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2/tail_build/prj

 it seems that the error is inside 'tail_build', please re-run build

 inside this module to isolate the error and/or test your fix:

build_error.log should contain the captured output of the failed module(s)

-----------------------------------------------------------------------

To rebuild a specific module:

make tail_build.clean # not recommended, this will re-build almost everything

make tail_build

when the problem is isolated and fixed, re-run 'make'

make[1]: *** [build-packimages] Erreur 1

make[1] : on quitte le répertoire « /temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2 »

make: *** [build] Erreur 2

 * ERROR: app-office/libreoffice-3.6.2.2 failed (compile phase):

 *   (no error message)

 * 

 * Call stack:

 *     ebuild.sh, line  89:  Called src_compile

 *   environment, line 8995:  Called die

 * The specific snippet of code:

 *       make build || die

 * 

 * If you need support, post the output of `emerge --info '=app-office/libreoffice-3.6.2.2'`,

 * the complete build log and the output of `emerge -pqv '=app-office/libreoffice-3.6.2.2'`.

!!! When you file a bug report, please include the following information:

GENTOO_VM=  CLASSPATH="" JAVA_HOME="/etc/java-config-2/current-system-vm"

JAVACFLAGS="" COMPILER=""

and of course, the output of emerge --info

 * The complete build log is located at '/var/log/portage/app-office:libreoffice-3.6.2.2:20121002-112541.log'.

 * For convenience, a symlink to the build log is located at '/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/temp/build.log'.

 * The ebuild environment file is located at '/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/temp/environment'.

 * Working directory: '/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2'

 * S: '/temp/var/tmp/portage/app-office/libreoffice-3.6.2.2/work/libreoffice-core-3.6.2.2'
```

----------

## DuF

Juste pour être sûr, c'est pareil avec la dernière version stable de LibreOffice, la 3.6.1 ?

EDIT : Et si tu compiles avec FEATURES="-sandbox" ?

----------

## boozo

'alute

je pointe sans doute à tord mon museau sur ce sujet brulant mais ne vous focalisez-vous pas sur un pb de cache mémoire alors que le fs pourrait-être en cause ?

I.e. dans le fil anglophone tu indiques :

 *pums974 wrote:*   

> here is my df :
> 
> ```
> 
> Sys. fich.                                            1K-blocks     Util. Disponible Uti% Monté sur
> ...

 

Tu indiques par ailleurs, ne pas passer en tmpfs et les path dans les logs de portage indiquent que ton /var/tmp est hébergé sur ce /temp qui est 85% d'utilisation... il y a peut-être un lien de cause à effet non ?

Quel est le fs utilisé et la place disponible pour ce faire ? (de mémoire, fallait >10Go pour compiler ces machins-là *glups* vais vomir...)

C'est peut-être une piste en bois - le message d'erreur ne sembe pas aller dans ce sens en effet - mais quelque fois...   :Rolling Eyes: 

Edit: Je pense à un truc tout c** qui me causait des coredump et autres joyeusetés dans une autre vie : #ulimit -a rend quoi chez toi ?

----------

## pums974

Effectivement ca aurais pu être une piste. J'ai fais le ménage, j'ai maintenant 33G de libre sur /temp.

Et ca crash toujours...

En ce qui concerne ulimit -a

```

core file size          (blocks, -c) 0

data seg size           (kbytes, -d) unlimited

scheduling priority             (-e) 0

file size               (blocks, -f) unlimited

pending signals                 (-i) 63503

max locked memory       (kbytes, -l) 64

max memory size         (kbytes, -m) unlimited

open files                      (-n) 1024

pipe size            (512 bytes, -p) 8

POSIX message queues     (bytes, -q) 819200

real-time priority              (-r) 0

stack size              (kbytes, -s) 8192

cpu time               (seconds, -t) unlimited

max user processes              (-u) 63503

virtual memory          (kbytes, -v) unlimited

file locks                      (-x) unlimited

```

 *Quote:*   

> Juste pour être sûr, c'est pareil avec la dernière version stable de LibreOffice, la 3.6.1 ? 

 

Euh, il me semble que la dernière version stable est la 3.5.6.2. Pour tester je doit résoudre un certain nombre de blockages. je n'ai pas le temps de le faire tout de suite.

 *Quote:*   

>  Et si tu compiles avec FEATURES="-sandbox" ?

 

Toujours pareil. Et toujours pareil avec FEATURES="-sandbox -usersandbox"

----------

## DuF

 *pums974 wrote:*   

> 
> 
> Euh, il me semble que la dernière version stable est la 3.5.6.2. Pour tester je doit résoudre un certain nombre de blockages. je n'ai pas le temps de le faire tout de suite.
> 
> 

 

En fait pour la 3.6.1 j'ai regardé la dernière stable que libreoffice fournit sur leur site (et non ce qu'il y a dans portage). Bon toute façon ce ne serait sans doute pas ça vu que le problème n'est pas limité à libreoffice.

Et sinon si c'est toujours pareil avec sandbox inactif, il faudrait tester avec un kernel propre (conf avec le strict minimum quitte à seulement démarrer en console) ou un noyau fait avec genkernel ou en prenant le dernier liveDVD gentoo d'avril 2012.

----------

## pums974

Un ami a trouvé la solution.

J'avais "vm.overcommit_memory = 2" dans /etc/sysctl.conf. 

Je ne me souviens pas l'y avoir mis, et je ne comprend pas nonplus ce que ca fait là.

Le fait est que depuis que j'ai commenter cette ligne, je n'ai plus de probèmes pour compiler libreoffice (ce qui est, pour le moment, mon test ultime)

Quelqu'un pourrais m'expliquer ce que signifie cette option

Est-ce normal d'avoir des problème avec ?

En tout cas merci beaucoup pour votre aide.

----------

## DuF

 *pums974 wrote:*   

> Un ami a trouvé la solution.
> 
> J'avais "vm.overcommit_memory = 2" dans /etc/sysctl.conf. 
> 
> Je ne me souviens pas l'y avoir mis, et je ne comprend pas nonplus ce que ca fait là.
> ...

 

Je ne pense pas qu'il soit normal d'avoir des problèmes avec mais le principe de ce type de limitation c'est de protéger les machines, éviter les dépassements mémoires etc. Peut-être est-ce selinux ou un mécanisme équivalent dont le but était de protéger la mémoire allouée. Mais là je suppose car je ne connais pas des éléments qui viendraient toucher à ça. Ca doit aussi trouver du sens pour de la virtualisation je suppose.

Quelle est la valeur chez toi de :  /proc/sys/vm/overcommit_ratio

Car le positionnement de vm.overcommit_memory à 2 va indiquer quelle taille est adressable en espace utilisateur. Le calcul est le suivant : 

swap + mémoire vive physique*(valeur de overcommit_ratio /100)

On voit le résultat du calcul avec meminfo (chez moi) : 

```

[root@fedduf ~]# cat /proc/meminfo 

CommitLimit:     6714356 kB

Committed_AS:    2044072 kB

```

 *pums974 wrote:*   

> En tout cas merci beaucoup pour votre aide.

 

Merci d'avoir assuré le suivi en indiquant l'origine du problème et reste en bon terme avec ton ami  :Wink: 

EDIT : En écrivant la remarque sur meminfo, on aurait du te demander ton meminfo bien plus tôt  :Very Happy: 

----------

## pums974

```

#cat /proc/sys/vm/overcommit_ratio

 50

#cat /proc/meminfo 

MemTotal:        8205856 kB

MemFree:         5198996 kB

SwapTotal:       5242876 kB

SwapFree:        5242876 kB

CommitLimit:     9345804 kB

Committed_AS:    5016588 kB

```

Je n'ai pas compris. (MemTotal + SwapTotal)/2 n'est pas égal à CommitLimit.

Et si je remet vm.overcommit_memory à 2, mes valeurs ne changent pas (aucune valeur de meminfo ne change d'ailleur).

----------

## boozo

Je n'aurai jamais pensé a vérifier cela   :Shocked:  mais je le note pour le futur dans ma checklist.

Btw, je pense que l'orgine viens de là à travers l'article du linuxjournal sur ce point. Tu avais dû faire cette modif dans tes premiers tests (p.e. à cette époque ?)

Dans ton cas, depuis que tu as changé de matos, tu n'as plus du tout de partition swap c'est çà ?

----------

## pums974

Bien vu, et l'article a même le bon goût d'être clair.

Par contre ca doit dater d'avant, parce que je pense mes problèmes de l'époque étaient dû au même phénomène (d'ailleur DuF, désolé de ne pas t'avoir répondu sur ce fil, j'ai du subir un rush au boulot et ca m'est complètement sortie de la tête). 

Mais jusqu'a présent  je n'avais pas trop creuser parce que, pour une raison qui m'échappe encore, c'était un problème trop aléatoire pour être reproductible à volonté, et là, depuis que je suis passer de 4 à 8G de ram, libreoffice est devenu impossible à compiler, j'avais donc un test parfait sur lequel travailler.

Et si, j'ai toujours une partition swap, toujours de la même taille (5G).

----------

## DuF

 *pums974 wrote:*   

> 
> 
> ```
> 
> #cat /proc/sys/vm/overcommit_ratio
> ...

 

Si si c'est égal, faut respecter l'ordre des opérateurs (j'aurai pu ajouter des parenthèses j'avoue). Le calcul c'est swap + MemTotal*ratio/100 dans ton cas ça donne 5Go + 7.8Go*50/100 soit 5Go + 7.8Go*0.5 soit 5Go + 3.9Go soit 8.9Go ce qui correspond exactement à ton CommitLimit (9345804 kB == 8.9Go).

C'est normal que les valeurs ne changement pas quand tu touches à vm.overcommit_memory car ce paramètre ne touche que le comportement (vérification des malloc ou pas en gros). Pour que ça bouge il faut toucher un des éléments qui servent au calcul donc soit le swap total, soit la mémoire totale disponible, soit le ratio.

A mon avis t'avais le swap inactif comme le suggère Boozo ce qui donne seulement 3.9Go de mémoire disponible à allouer.

 *pums974 wrote:*   

> (d'ailleur DuF, désolé de ne pas t'avoir répondu sur ce fil, j'ai du subir un rush au boulot et ca m'est complètement sortie de la tête). 

 

Aucun souci, perso j'avais rien de pressé   :Laughing: 

----------

## pums974

 *Quote:*   

> Si si c'est égal, faut respecter l'ordre des opérateurs

 

Oups.. je suis un imbécile... désolé.

 *Quote:*   

> A mon avis t'avais le swap inactif comme le suggère Boozo ce qui donne seulement 3.9Go de mémoire disponible à allouer. 

 

Tu entend quoi par inactif ?

----------

## DuF

 *pums974 wrote:*   

> 
> 
>  *Quote:*   A mon avis t'avais le swap inactif comme le suggère Boozo ce qui donne seulement 3.9Go de mémoire disponible à allouer.  
> 
> Tu entend quoi par inactif ?

 

Il me semble qu'a un moment donné tu faisais des tests avec swapoff comme l'indique Boozo ce qui influence le calcul. Après de toute façon c'est facilement vérifiable et reproductible.

----------

