Op deze website gebruiken we cookies om content en advertenties te personaliseren, om functies voor social media te bieden en om ons websiteverkeer te analyseren. Ook delen we informatie over uw gebruik van onze site met onze partners voor social media, adverteren en analyse. Deze partners kunnen deze gegevens combineren met andere informatie die u aan ze heeft verstrekt of die ze hebben verzameld op basis van uw gebruik van hun services. Meer informatie.

Akkoord

Vraag & Antwoord

OS Linux

iets vreet langzaam m'n swap op...

KayJay
19 antwoorden
  • hoi,

    als ik m'n stats bekijk voor m'n server zie ik dat elke 2 wk de swap helemaal vol zit; in een (vrijwel) rechte lijn gaat dat van 0% naar 100% in 2 wk tijd. (dan reboot)
    Er zal dus wel een of ander proces/programma niet netjes werken, maar hoe kan ik zien wat beslag legt op m'n swap?
    Hoe voorkom ik dit, anders dan een reboot (dat niet eens "voorkomen" is)?
  • zoeken welk programma dat al je swap op smult en kijken of er een nieuwere versie is van dit programma, kijk eens met top (commandline, en dan "top" intypen , <enter>;) en kijk welk programma die 100(of toch veel)% geheugen voor zijn rekening neemt.
  • [code:1:4b83767efd]
    top - 21:37:03 up 7 days, 9:27, 1 user, load average: 0.02, 0.02, 0.00
    Tasks: 89 total, 1 running, 88 sleeping, 0 stopped, 0 zombie
    Cpu(s): 0.2% us, 0.1% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si
    Mem: 255176k total, 223280k used, 31896k free, 6276k buffers
    Swap: 260056k total, 206008k used, 54048k free, 31852k cached

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ [b]SWAP[/b] COMMAND
    19161 postfix 16 0 22368 6808 6248 S 0.0 2.7 0:00.08 15m MailScanner
    978 clamav 23 0 21116 6752 4072 S 0.0 2.6 0:09.83 14m clamd
    31647 root 16 0 20252 7256 16m S 0.0 2.8 0:00.51 12m httpd
    31651 apache 23 0 20252 7288 16m S 0.0 2.9 0:00.00 12m httpd
    31652 apache 22 0 20252 7288 16m S 0.0 2.9 0:00.00 12m httpd
    31653 apache 22 0 20252 7288 16m S 0.0 2.9 0:00.00 12m httpd
    31654 apache 22 0 20252 7288 16m S 0.0 2.9 0:00.00 12m httpd
    31655 apache 22 0 20252 7288 16m S 0.0 2.9 0:00.00 12m httpd
    31656 apache 25 0 20252 7288 16m S 0.0 2.9 0:00.00 12m httpd
    31657 apache 25 0 20252 7288 16m S 0.0 2.9 0:00.00 12m httpd
    31650 apache 22 0 20252 7292 16m S 0.0 2.9 0:00.00 12m httpd
    9184 postfix 16 0 22892 11m 6248 S 0.0 4.4 0:19.41 11m MailScanner
    17055 postfix 16 0 22892 11m 6248 S 0.0 4.7 0:11.22 10m MailScanner
    23550 postfix 16 0 22892 12m 6248 S 0.1 5.0 0:05.35 9.9m MailScanner
    24329 postfix 16 0 22892 12m 6248 S 0.1 5.1 0:06.30 9992 MailScanner
    1304 root 18 0 11040 1288 9140 S 0.0 0.5 0:00.00 9752 smbd
    10783 postfix 16 0 23324 13m 6248 S 0.0 5.4 0:18.94 9432 MailSca[/code:1:4b83767efd]
    hoop dat hier iets van overblijft…
    is dus top, gesort op Swap.
    Apache is vers gerestart, maar heeft dus gelijk al erg veel instances. Is dat normaal? Waarom is dat?
    Verder MailScanner met meerdere instances (weet ik geloof ik in configfiles wel terug te brengen).
    Maar toch; telt allemaal niet op tot 260MB, en verklaart ook niet het langzaam oplopen van totale swap (0-100% in 2 wk)
    Iemand nog een tip? (kan ik bv periodiek de swap legen? Is daar een command voor dat ik in cron kan duwen?)
  • swap legen lijkt me geen goed idee ;)
    Is de lijst wel op geheugengebruik gesorteerd?
    Verder is de lijst langer dan je scherm, houdt daar rekening mee.
    Ander progje om je geheugengebruik mee te bewonderen is ksysguard.
    Kijk ook even of uitloggen/inloggen verschil uitmaakt in swapgebruik (kun je beter uitvogelen of een systeemprogramma geheugen slurpt, of een gebruikersprogramma…)

    Max
  • Ik zie eigenlijk helemaal geen probleem :wink:

    http://gathering.tweakers.net/forum/list_messages/814910#geheugenvol
  • m3ssi4h - dat is toch niet helemaal hetzelfde. De poster zegt dat zijn SWAP volloopt. RAM word altijd volledig gebruikt ja, maar op het moment dat disk buffers weggeschreven moeten gaan worden naar SWAP is er toch iets fundamenteel fout in het swappingmechanisme :wink: ook staan in de top output slechts 6,5 Mb RAM aan buffergs gereserveerd.

    Sorteer ten eerste inderdaad de top output eens op geheugen verbruik.

    MailScanner is een notoire RAM vreter, beng je maximaal aantal MailScanner processen eens wat terug. Als dit je persoonlijk Linux systeem is, is meer dan 2 MailScanner processen overbodig.
  • Dit is inderdaad een (persoonlijke) mail/webserver (clarkconnect), dus de oplossing uit te loggen zal 'm niet maken; normaliter is er niemand ingelogd op die bak, en toch loopt de swaplijn netjes op.
    MailScanner heb ik teruggebracht naar 3 instances, levert wel iets ruimte op (2*12 MB ongeveer), maar dan nog; na een verse reboot gebruik ik 0% swap.
    Ook aantal childprocesses Apache heb ik teruggebracht, zelfde result.

    @ksysguard: klinkt als grafisch proggie? => geen X op die server.
    @sorteren op geheugen: welk geheugen? Wat ik nu heb gepost is gesorteerd op SWAP. Verder heb je fysiek, shared, virtueel etc..
    Wat wil je zien..?
  • als je een andere bak hebt draaien kan je daar ksysguard op draaien en je kan dan via netwerk ook die server controleren (normaal), je moet gewoon een deamon hebben draaien op die server waarmee ksysguard dan kan communiceren (ik heb dit nog niet gedaan maar ik zie gewoon dat je andere systemen kan bijvoegen die dan via netwerk bereikbaar zijn)
  • de VIRT kolom in top is niet de swap usage..

    Gewoon in top <SHIFT>+<M> drukken - sorteer op memory gebruik.

    (
    virt != swap ;
    Swap: 249472k total, 0k used, 249472k free, 205616k cached

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    8836 root 16 0 102m 44m 23m S 0.0 8.8 1:35.41 firefox-bin
    7953 root 15 0 57080 28m 32m S 0.0 5.6 0:51.89 k3b
    )
  • probeer zoveel mogelijk services te restarten..
    ik zie een smb server draaien…restart deze en kijk wat het met je swap doet na een tijd
    voor zover ikweet kan het even duren voor dat de swap minder wordrt..
    doe hetzelfde eens met ssh.. met postfix.. met clamav…
  • ik zal eea proberen als ik thuis ben, en jullie laten weten wat er uit komt.
    dank sofar.
  • Top, shift M geeft:
    [code:1:b18f311959]
    top - 18:12:53 up 8 days, 6:03, 1 user, load average: 0.01, 0.02, 0.00
    Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie
    Cpu(s): 0.2% us, 0.1% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si
    Mem: 255176k total, 247344k used, 7832k free, 31304k buffers
    Swap: 260056k total, 188860k used, 71196k free, 31300k cached

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    21434 postfix 16 0 22572 17m 6248 S 0.0 7.0 0:07.94 MailScanner
    28782 postfix 16 0 22572 17m 6248 S 0.1 7.0 0:02.53 MailScanner
    29517 postfix 16 0 22572 17m 6248 S 0.0 7.0 0:02.50 MailScanner
    802 postfix 16 0 22180 17m 6248 S 0.0 6.8 0:00.00 MailScanner
    944 apache 16 0 23264 11m 16m S 0.0 4.7 0:01.40 httpd
    945 apache 15 0 23232 11m 16m S 0.0 4.7 0:01.53 httpd
    4456 apache 15 0 23180 11m 16m S 0.0 4.6 0:01.11 httpd
    946 apache 15 0 23260 11m 16m S 0.0 4.6 0:01.28 httpd
    942 apache 15 0 23116 11m 16m S 0.0 4.6 0:01.25 httpd
    943 apache 15 0 23072 11m 16m S 0.0 4.6 0:01.08 httpd
    7393 root 16 0 14508 9316 7236 S 0.0 3.7 0:28.23 syswatch
    939 root 16 0 19120 7256 16m S 0.0 2.8 0:00.26 httpd
    1228 clamav 24 0 20468 6880 4072 S 0.0 2.7 0:00.89 clamd
    29767 webconfi 16 0 12708 5988 8564 S 0.0 2.3 0:06.90 webconfig
    30394 webconfi 16 0 12112 5344 8564 S 0.0 2.1 0:05.89 webconfig
    21278 root 16 0 10876 3568 5344 S 0.0 1.4 0:02.43 miniserv.pl
    31808 rolf 16 0 7860 2108 3684 R 0.0 0.8 0:00.01 sshd
    [/code:1:b18f311959]

    Geeft weinig extra info AFAIC..?

    Zal inderdaad eens experimenteren met periodieke restarts van services en evt MailScanner instances nog verder omlaag brengen. (Klopt toch dat daarmee alleen risico op langer delay is, en niet risico van mails verwerpen of ongescand doorlaten?)
  • Apache in mindere mate (niet abnormaal iig) maar meer mailscanner idd die je geheugen weg vreet. Dat moet je idd indammen. Moet je zelf kijken of de mail niet te veel vertraagt.
  • Maar dat al verklaart niet waarom het in de tijd oploopt?
    Gedurende 2 wk loopt het op van 0 > 100%.
    MailScanner loopt effe, en stopt dan weer. Zou geheugen weer moeten vrijgeven, toch?

    Als het stabiel hoog zou zijn, zou al dit bovenstaande kloppen. Maar kennelijk roept iets de swap aan, en geeft het daarna niet meer vrij…
  • [quote:141bf34c66="rolfb"]Maar dat al verklaart niet waarom het in de tijd oploopt?
    Gedurende 2 wk loopt het op van 0 > 100%.
    MailScanner loopt effe, en stopt dan weer. Zou geheugen weer moeten vrijgeven, toch?

    Als het stabiel hoog zou zijn, zou al dit bovenstaande kloppen. Maar kennelijk roept iets de swap aan, en geeft het daarna niet meer vrij…[/quote:141bf34c66]

    Er moet toch altijd een deamon lopen die de mailscanner kan oproepen, misschien "vergeet" deze deamon om de gealloceerde geheugen ruimte terug vrij te geven nadat die Mailscanner ermee gedaan heeft. (Memmory leak.)
  • MailScanner is zelf de daemon, en werkt samen met sendmail en spamassassin.

    Het bayesian filter in MailScanner/spamassassin wilt nogal eens tot 1Gb aan RAM alloceren, pas op met het bayesian filter, en gebruik desnoods de handmatige SPAM/HAM leer methode, of zet het bayesian filter uit voor zo'n kleine site, en gebruik de RBL's die stoppen al 99% van de spam.
  • spamassin wordt niet aangesproken door MailScanner (is gelukkig nog niet nodig :D ), stuurt alleen ClamAV aan (helaas wel nodig voor vrouw met Windows :cry: )

    Maar aangezien kennelijk de oorzaak niet voor de hand ligt: is er wel een voor de hand liggende oplossing?
    Rebooten flusht de swap uiteraard, maar kan dat ook op een andere (nette) manier?
  • misschien eens kijken voor welke programma's er een update beschikbaar is en alles eens updaten… misschien helpt dat.
  • Stop de verschillende services een 1 voor 1 en "sync" de harddisk erna. Kijk wanneer je memory weer terug komt. Dat zou dan de schuldige moeten zijn.

Beantwoord deze vraag

Dit is een gearchiveerde pagina. Antwoorden is niet meer mogelijk.