Problème mémoire vive [SuSE] - Divers - Linux et OS Alternatifs
Marsh Posté le 20-06-2007 à 13:00:07
alors il faut modifer ton bash le temps d'investigation et ne plus utiliser unzip et surtout pas dans sa version actuellement installee ..
--------------
tu as pas tout simplement tanter de jouer avec les param shm etc.... dans sysctrl (/etc)
par exemple si ta BDD est oracle c'est indispenssable ! et c'est meme le prerequis avant installation !
quand aux 12G de ram il est extremement probable si tu n'a jamais compiler de noyaux specialement pour ces machines que tu aies des noyaux standard (donc limités à 4Go) et du coup la fin de ram n'est pas calculée correctement....
le coup classique c'est un programme qui regarde la ram dispo (XGo) et demande donc une allocation de X/2 Go mais pas de bol en realité la ram libre est calculée pour 3/4 au dela des 4Go donc l'application plante sans provoqeuer d'erreur et donc plus rien ne peut empecher un plantage general de la machine.
C'est peut etre ton cas....
Verfies aussi que ton bios permet de depasser les 4Go de ram (la pluspart du temps le bus memoire et son controleur le peuvent mais pas le bios et là aussi meme genre de symptome au lieu que l'appli plante c'est la machine globale qui sait plus trop où elle en est de ses reservations....
Marsh Posté le 20-06-2007 à 14:30:57
Salut,
Effectivement pour ma BDD j'ai créé un /etc/sysctl.conf avec les paramètres suivants :
kernel.shmall=3145728
kernel.shmmax=4254967296
SHMALL à 12Go et SHMMAX à un peu moins de 4Go.
Le noyau installé par la SuSE 7.3 est un 2.4.10 et effectivement il doit y avoir cette limite à 4Go dont tu me parles.
Comment je m'y prend pour recompiler le noyau avec le bon paramètre magique ?
Quand au bios je vais faire vérifier çà.
A+
Marsh Posté le 20-06-2007 à 19:28:12
tu reprends ton /boot/configmachin comme /usr/local/src/.config
et tu installes les sources noyau (ncurse etc...) de suse entreprise server (version que je suppose etre la 7.*)
tu vas dans le repertoire des sources noyau
tu fait ton make proper et derierre tu fait un make menuconfig
tu charges le fichier .config comme base de travaille
et voir les valeurs suivantes :
-highmem
-hugepages
-ihash_entries
-ihash_addr
-max_addr <- je pense que c'est cet element la
-mem <- et ca (force memory usage)
-memmap
-noexec
-reserve
-vmalloc
-norandmaps
-vdso
d'apres mon document (linux kernel in a nutshell) ISBN : 0-956-10079-5
mais j'ai pas de quoi tester sous la main... ma plus grosse becanne en ram a que 2Go donc les options par defaut sont ok.
apres bien sur tu enregistre sous le meme nom de config .config mais cette fois ci dans le repertoire des sources noyau
puis tu fais les classique make make modules_install make install make initrd lilo pour ajouter une ligne de choix au boot avec ton nouveau noyau a tester...
(pour etre sur de pouvoir revenir en arriere en cas de soucis)
Verifies quand meme avant si novell n'a pas de procedure speciale a suivre pour ca sinon utilise la methode classique (celle que je t'ai decrite)
Marsh Posté le 23-06-2007 à 14:45:25
cypress a écrit : Bonjour à tous,
|
La mémoire que tu vois chuter, c'est avec ou sans le cache système ? ( "free -m" -> première ligne ou seconde ligne ? )
Marsh Posté le 25-06-2007 à 11:03:18
La solution la plus rapide au problème, si tu peux te le permettre, ça serait de passer à une version plus récente de SuSe. Surtout que (amha) la 7.3 n'est plus supportée.
Enfin si c'est un syst en prod c'est pas faisable.
Marsh Posté le 25-06-2007 à 11:24:36
Salut,
Pour résoudre le pb, on a été encore plus radical : on a baissé la mémoire à 4Go :-)
Et là, plus de problème.
Merci à vous.
Marsh Posté le 20-06-2007 à 11:30:26
Bonjour à tous,
Sur une vieille SuSE 7.3, j'ai un problème de mémoire vive : dès que je lance un traitement batch qui fait des unzip, ou encore une intégration de data dans une BDD, la mémoire vive chute à vitesse grand V.
Si je fais un top -d1, je la vois chuter tranquillement et le processus init finit par prendre énormément de CPU.
Et forcément, à un moment ==> bash: fork: Cannot allocate memory
A partir de là, impossible de rebooter, même après avoir killé le traitement initial : le init continue de prendre tout le CPU.
J'ai un autre serveur identique, et j'ai le même soucis.
Avez-vous une idée ? Je pensais à un problème avec la gestion de 12Go de RAM, ou encore un soucis de compatibilité matérielle ?
Merci !
Pour info : j'ai des disques en raid sur une adaptec 2120S.
CPU0 states: 0.0% user, 100.0% system, 0.0% nice, 0.0% idle
CPU1 states: 0.0% user, 48.0% system, 0.0% nice, 51.0% idle
Mem: 12365592K av, 12360820K used, 4772K free, 0K shrd, 84060K buff
Swap: 2097136K av, 1360492K used, 736644K free 10419976K cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
1 root 14 0 208 176 176 R 81.4 0.0 13:16 init
28751 base 19 0 1028 952 796 R 22.8 0.0 2:07 top
5 root 18 0 0 0 0 RW 20.7 0.0 6:57 kswapd
790 root 9 0 1656 1392 1392 S 1.4 0.0 0:12 httpd
701 root 9 0 812 664 660 S 0.7 0.0 0:19 nscd
2 root 9 0 0 0 0 SW 0.0 0.0 0:00 keventd
3 root 19 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU0
4 root 18 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU1
6 root 9 0 0 0 0 SW 0.0 0.0 0:35 bdflush
7 root 9 0 0 0 0 SW 0.0 0.0 0:10 kupdated
8 root -1 -20 0 0 0 SW< 0.0 0.0 0:00 mdrecoveryd
11 root 9 0 0 0 0 SW 0.0 0.0 0:00 aacraid
12 root 9 0 0 0 0 SW 0.0 0.0 0:00 aacraid
13 root 9 0 0 0 0 SW 0.0 0.0 0:00 scsi_eh_0
14 root 9 0 0 0 0 SW 0.0 0.0 0:00 scsi_eh_1
54 root 9 0 0 0 0 SW 0.0 0.0 5:04 kjournald
55 root 9 0 0 0 0 SW 0.0 0.0 0:00 kjournald