Bonjour,
Après d'autre vérification et d'autres tests il semblerait qu'au
final le paramètre incrimine est 'overcommit_ratio'. En effet, dans la documentation il est
écrit:
overcommit_ratio:
When overcommit_memory is set to 2, the committed address
space is not permitted to exceed swap plus this percentage
of physical RAM. See above.
Or voici ma configuration:
Limitation memoire:
[root@XXX]:~ # sysctl -p | grep over
vm.overcommit_ratio = 0
vm.overcommit_memory = 50
Sans limitation memoire:
[root@XXX]:~ # sysctl -p | grep over
vm.overcommit_ratio = 0
vm.overcommit_memory = 0
Il y aurait-il un problème de définition?
Cordialement,
JM
On 06/15/2011 04:33 PM, Jeremy MAURO wrote:
Re
bonjour,
Après avoir creuser et avoir asticoté le serveur dans tous les
sens il semblerait que le fautif soit le paramétré système:
kernel.shmmax que nous avions mis à une valeur qui ne semble pas
plaire au systeme: kernel.shmmax = 8589934592
Cordialement,
JM
On 06/15/2011 02:51 PM, Jeremy MAURO wrote:
A priori non:
[root@XXX]:/etc/apt # df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md1 7.3G 885M 6.0G 13% /
tmpfs 7.9G 0 7.9G 0% /lib/init/rw
udev 7.9G 192K 7.9G 1% /dev
tmpfs 7.9G 0 7.9G 0% /dev/shm
/dev/md0 244M 22M 210M 10% /boot
/dev/mapper/vg_data-lv_home
2.0G 68M 1.9G 4% /home
/dev/mapper/vg_system-lv_tmp
1008M 34M 924M 4% /tmp
/dev/mapper/vg_system-lv_var
5.0G 456M 4.3G 10% /var
Et voici les options de montage:
[root@XXX]:/etc/apt # cat /proc/mounts
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
none /dev devtmpfs
rw,relatime,size=8224644k,nr_inodes=2056161,mode=755 0 0
none /dev/pts devpts
rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/disk/by-uuid/42530f44-663a-4be9-88ac-07c1d8c05c8f / ext3
rw,relatime,errors=continue,data="" 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
/dev/md0 /boot ext3 rw,relatime,errors=continue,data="" 0 0
/dev/mapper/vg_data-lv_afs7 /usr/local/afs7 ext4
rw,noatime,barrier=1,stripe=256,data="" 0 0
/dev/mapper/vg_data-lv_home /home ext3
rw,relatime,errors=continue,data="" 0 0
/dev/mapper/vg_system-lv_tmp /tmp ext3
rw,relatime,errors=continue,data="" 0 0
/dev/mapper/vg_system-lv_var /var ext3
rw,relatime,errors=continue,data="" 0 0
[root@XXX]:/etc/apt # cat /etc/mtab
/dev/md1 / ext3 rw 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=0755 0 0
proc /proc proc rw,noexec,nosuid,nodev 0 0
sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0
udev /dev tmpfs rw,mode=0755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
/dev/md0 /boot ext3 rw 0 0
/dev/mapper/vg_data-lv_afs7 /usr/local/afs7 ext4 rw,noatime 0 0
/dev/mapper/vg_data-lv_home /home ext3 rw 0 0
/dev/mapper/vg_system-lv_tmp /tmp ext3 rw 0 0
/dev/mapper/vg_system-lv_var /var ext3 rw 0 0
De plus le message d'erreur préciserait un FS full non? Une
autre idée?
Cordialement,
Jeremy MAURO
Jeremy MAURO (jmauro@antidot.net)
Antidot - Solutions de recherche d'information
29 avenue Jean Monnet, 13410 LAMBESC (FRANCE)
Tel: (+33) 4 42 63 67 90 / Fax: (+33) 4 42 28 61 03
On 06/15/2011 02:46 PM, Pascal Le Bris wrote:
Le 06/15/11 14:40, Jeremy MAURO a écrit
:
Bonjour tout le monde
Bonjour
Une idée de la provenance du 'Cannot allocate memory'
Puisque ce n'est pas la RAM, bêtement un filesystem full
...peut-être
Cdlt
|