Forum Linux.debian/ubuntu swap

Posté par  .
Étiquettes : aucune
0
17
juin
2011

Bonjour j'ai une question lié à un serveur que j'ai
j'ai remarqué que ma machine swap alors qu'il lui reste de la mémoire vive

free -m
                                               total       used       free     shared    buffers     cached
Mem:                                   8112       5166       2946          0        497        136
-/+ buffers/cache:          4532       3580
Swap:                                       1999         424       1575

Si quelqu'un peut m'expliquer pourquoi je suis preneur
Merci

  • # le swapin est normal sous linux...

    Posté par  (site web personnel) . Évalué à 3.

    C'est le système qui met en swap les processus qui fichent pas grand choses, pour avoir de la mémoire "rapide" disponible en cas de besoin
    C'est linux qui gère bien la mémoire, mieux que zin tout ca( buffercache, swap in/out )

    Tu as pour 424 Mo de processus qui "pioncent"...
    Rien d'affolant pour moi....
    Pour te rassurer regarde les page in/out

    NB : si c'est des proc java il est recommandé de forcer le maintient en mémoire haute.
    La JVM ( en tout cas celle de sun, ha non oracle, car pour la jerokit je sais pas trop je l'ai pas trop pratiqué ) supporte assez mal les allé retour en swap..

    Fuse : j'en Use et Abuse !

  • # swap

    Posté par  . Évalué à 1.

    ok merci pour vos réponse
    j'ai fait
    cat /proc/meminfo pour avoir plus d'info mais c’était trop tard je suis redescendu à 65 mo .j 'ai remarqué que c'est accès récurrent cette utilisation de 400~ mo. Mais si vous me dite que c'est pas anormale.

    MemTotal:        8307360 kB
    MemFree:         2217600 kB
    Buffers:          514048 kB
    Cached:           491712 kB
    SwapCached:         7036 kB
    Active:          5106196 kB
    Inactive:         849452 kB
    Active(anon):    4560264 kB
    Inactive(anon):   389952 kB
    Active(file):     545932 kB
    Inactive(file):   459500 kB
    Unevictable:           0 kB
    Mlocked:               0 kB
    HighTotal:       7651336 kB
    HighFree:        2208208 kB
    LowTotal:         656024 kB
    LowFree:            9392 kB
    SwapTotal:       2047992 kB
    SwapFree:        1982268 kB
    Dirty:               116 kB
    Writeback:             0 kB
    AnonPages:       4944560 kB
    Mapped:            54964 kB
    Shmem:               324 kB
    Slab:             103384 kB
    SReclaimable:      82304 kB
    SUnreclaim:        21080 kB
    KernelStack:        9168 kB
    PageTables:        13164 kB
    NFS_Unstable:          0 kB
    Bounce:                0 kB
    WritebackTmp:          0 kB
    CommitLimit:     6201672 kB
    Committed_AS:    6170692 kB
    VmallocTotal:     122880 kB
    VmallocUsed:        1784 kB
    VmallocChunk:     120648 kB
    HardwareCorrupted:     0 kB
    HugePages_Total:       0
    HugePages_Free:        0
    HugePages_Rsvd:        0
    HugePages_Surp:        0
    Hugepagesize:       2048 kB
    DirectMap4k:      737272 kB
    DirectMap2M:           0 kB
    
  • # swap

    Posté par  . Évalué à 1.

    Effectivement sur ce serveur il n'y a que des jvm

    • [^] # Re: swap

      Posté par  . Évalué à 5.

      Bonjour,

      Tout d'abord les aspects purement performance, qui peut être ne t'intéresse pas mais qui me permette d'introduire rapidement des mécanismes de fonctionnement. Donc quelles que soient les JVMs (sun, hp, jrockit, etc.) elles sont toujours sensibles quand elles sont en swap disque (je précise swap disque pour pas confondre avec la pseudo-swap d'hp-ux), c'est d'autant plus vrai lorsqu'elles sont soumises à de la charge.

      Pour faire simple, si les utilisateurs remontent des problèmes de performance, alors le seul indicateur a regarder pour savoir si le swap disque est la cause, c'est de surveiller le swapin/swapout. Le taux d'occupation du swap ne sert à rien si on ne sait pas à quel moment il s'est rempli.

      En effet, pour une raison ou une autre, le système d'exploitation a pu décider à un moment de mettre des process en swap car il avait besoin de la mémoire. Mais si ensuite il n'y a plus aucun si/so alors que les process sont toujours en swap, c'est qu'ils n'ont aucune activité. Et ils vont rester en swap tant qu'ils ne seront pas sollicités.

      Si par contre, tu constates du si/so, alors c'est mauvais pour les performances (c'est d'ailleurs vrai pour d'autres process, pas seulement JVMs).

      Pour le surveiller, le plus simple c'est un vmstat -n 5, tu as le si et le so.

      Pour revenir sur ton cas précis, les ~400Mo de swap sont peut être là depuis très longtemps et si le système constate qu'ils ne sont pas utilisés alors il estime qu'il n'a pas intérêt à le repasser en mémoire. En effet ça évite de lire le disque et d'écrire en mémoire et de prendre de la place mémoire pour des process qui a priori ne font rien. Donc autant laisser la mémoire libre disponible pour les prochaines exécutions.

      C'est un peu rapide mais le sujet est long :)

      @+

  • # Explication possible

    Posté par  . Évalué à 3.

    J'ai remarqué ça sur un serveur à moi aussi, et je pense que ça vient de tâches ponctuelles qui prennent beaucoup de mémoire et relèguent donc les autres en swap. Comme ces dernières restent inactives elles restent en swap.

    DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: Explication possible

      Posté par  . Évalué à 2.

      Qui restent inactives ou qui n'accèdent tout simplement plus à toutes les pages de mémoire qui leurs ont été allouées... Évidemment c'est moins chouette avec les garbage collectors qui parcourent inconditionnellement l'ensemble du tas :^)

      [ Btw, il me semble avoir entendu parler (d'un projet/recherche) d'une implémentation de gc qui s'appuyerait sur des indications du kernel justement : le problème étant qu'un processus n'a pas les informations d'accès et de pagination que le kernel a, rendant certaines optimisations impossibles pour les gc, aussi il ne sait pas tirer partie de la mmu matérielle. ]

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.