Xorg : Problème Occupation de la RAM

Xorg : Problème Occupation de la RAM - Installation - Linux et OS Alternatifs

Marsh Posté le 16-07-2009 à 16:52:12    

Salut,
 
 
J'ai depuis quelques jours un petit problème sous ArchLinux.
Je tourne sous KDE.
Au bout de quelques minutes, le serveur X occupe pas loin de 45% de ma mémoire (4 Gigas).
Du coup, plus moyen d'ouvrir de nouvelles fenêtres ou applis, pour en lancer une nouvelle il faut que je ferme une fenêtre/appli déjà ouverte.
J'avais déjà eu ce problème il y a quelques mois mais il avait disparu plus ou moins tout seul.
 
Un peu lourd de devoir relancer le serveur X toutes les 6 heures...
 
Quelqu'un aurait déjà rencontré ce genre de problème ?
Merci d'avance.


Message édité par jaymzwise le 20-07-2009 à 18:36:44
Reply

Marsh Posté le 16-07-2009 à 16:52:12   

Reply

Marsh Posté le 17-07-2009 à 10:57:42    

Salut,
 
 
Petit complément d'information, si je souhaite lancer une nouvelle appli quand ma mémoire est occupée à 50% j'obtiens ce genre de message :

Code :
  1. Maximum number of clients reachedamarok: cannot connect to X server :0.0

Reply

Marsh Posté le 20-07-2009 à 18:29:48    

Salut,
 
 
Voici quelques infos supplémentaires :
xrestop

Code :
  1. xrestop - Display: localhost:0
  2.           Monitoring 256 clients. XErrors: 0
  3.           Pixmaps: 1634852K total, Other:      68K total, All: 1634921K total
  4. res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier
  5. b600000    11    6    0  289  380    14620K      9K  14629K 14334 amarok
  6. 1c00000    22   16    0  571  675    11693K     16K  11710K  3868 Qt-subapplication
  7. 1fe00000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  8. 1fc00000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  9. 1fa00000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  10. 1f800000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  11. 1f600000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  12. 1f400000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  13. 1f200000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  14. 1f000000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  15. 1ee00000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  16. 1ec00000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  17. 1e800000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  18. 1e600000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  19. 1e400000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  20. 1e200000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  21. 1e000000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  22. 1de00000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  23. 1dc00000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  24. 1da00000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  25. 1d800000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  26. 1d600000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  27. 1d400000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  28. 1d200000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  29. 1d000000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  30. 1ce00000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  31. 1cc00000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  32. 1ca00000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  33. 1c800000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  34. 1c600000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  35. 1c400000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  36. 1c200000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  37. 1c000000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  38. 1be00000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  39. 1bc00000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  40. 1ba00000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  41. 1b800000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  42. 1b600000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  43. 1b400000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  44. 1b200000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  45. 1b000000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  46. 1ae00000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>
  47. 1ac00000     0    0    0    1    0     6890K      0B   6890K   ?   <unknown>


 
Je suppose qu'avoir autant de ligne <unknown> ne doit pas être normal mais que puis-je faire pour trouver quelle appli les génère ?


Message édité par jaymzwise le 20-07-2009 à 18:30:48
Reply

Marsh Posté le 21-07-2009 à 12:05:06    

Si tu lances un X à poil avec juste un xterm ou un WM super léger, est-ce que tu constates la même fuite ? Il faut que tu détermines si c'est un problème de X ou bien une application à la noix.

Reply

Marsh Posté le 21-07-2009 à 14:23:14    

Ok, je vais tester avec fluxbox.


Message édité par jaymzwise le 21-07-2009 à 15:04:05
Reply

Marsh Posté le 23-07-2009 à 16:57:13    

Salut,
 
J'ai résolu mon problème en supprimant le répertoire .kde4 présent dans mon Home.
Pour le moment, l'occupation de RAM est normale.

Reply

Marsh Posté le 23-07-2009 à 17:06:25    

Au fait,
Si on constate une fuite de mémoire dans un programme, il y a un moyen "simple" de déterminer d'où ça vient pour faire un bug report un peu plus précis que "ça marche pas" ?
Parce que je suspecte une fuite de mémoire dans mon eclipse (au lancement ça prend ~50Mo, 1Go de ram en fin de journée, si je relance pas) mais je sais pas si ça vient d'eclipse tout seul, d'un plugin/workspace précis :s


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 23-07-2009 à 20:08:26    

java

Reply

Marsh Posté le 24-07-2009 à 08:07:21    

c-a-d? :heink:


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 24-07-2009 à 10:20:27    

all your ram are belong to us

Reply

Marsh Posté le 24-07-2009 à 10:20:27   

Reply

Marsh Posté le 24-07-2009 à 10:23:00    

Oué mais non quoi :o
Un programme qui démarre à 50 Mo et qui systématiquement fini par occuper 1 Go de Ram en fin de journée c'est pas une feathure de java :p


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 24-07-2009 à 10:33:22    

Ben justement si. Tant que t'as pas atteint ton Mx, bah ça se goinfre, et après ça collecte juste ce que nécessaire.
 
Je te raconte pas le bordel au taf: imagine un serveur d'appli avec 10 instances de java. Chaque instance tourne sans problème avec un Mx à 250meg. Problème: une fois par semaine, chaque instance va faire un traitement spécial qui nécessite environ 1gig de mémoire. Sauf que l'ami java, le paramétrage dynamique il connaît pas. Donc pour pas se manger des EOM partout, on est obligé de positionner le Mx à 1g pour le pire des cas.
 
Résultat: bah ça swap à donf parce que chaque instance se touche la nouille à ne collecter que vers 1g...
 
Merci java.

Reply

Marsh Posté le 24-07-2009 à 10:42:47    

mmm ok ..
C'est con ça, parce que dans mon cas bein relancer Eclipse ça résoud direct le problème, alors qu'appeler le GC via l'interface, comme tu dis ça réduit juste "ce qu'il faut", du coup il me libère genre 50 Mo de ram...Cool sur 1 Go :heink: surtout que 15 sec après c'est rebelote ...
Dans mon cas c'est un peu chiant mais je suis juste sur le cul pour les problèmes que ça peut créer pour des appli serveur :heink:


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 24-07-2009 à 16:30:27    

Taz a écrit :

Je te raconte pas le bordel au taf: imagine un serveur d'appli avec 10 instances de java. Chaque instance tourne sans problème avec un Mx à 250meg. Problème: une fois par semaine, chaque instance va faire un traitement spécial qui nécessite environ 1gig de mémoire. Sauf que l'ami java, le paramétrage dynamique il connaît pas. Donc pour pas se manger des EOM partout, on est obligé de positionner le Mx à 1g pour le pire des cas.


 
Ouch. C'est quoi? Du websphere?


---------------
Petit guide Kerberos pour l'administrateur pressé
Reply

Marsh Posté le 27-07-2009 à 21:33:25    

oui. un grand grand classique

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed