Swap onverklaarbaar vol

[kKaltUu]

Ola, probleem hier.

Ik heb hier een server draaien met Ubuntu 8.10 LTS (2.6.27-15-server) waar ik een raar probleem met m'n swapspace heb.
/dev/sda1 is m'n hoofdpartitie waar ook het systeem op draait, hier wordt ook af en toe gegevens naartoe gehaald die naar /dev/sdb1 wordt geschreven.
Na een mailalert die ik maandag kreeg, keek ik hoeveel ruimte er nog overwas, en blijkbaar zat m'n schijf vol omdat de backup op de temp locatie te groot was).
Nadat alles opgeschoont is, zie ik dat m'n swappartitie toch nog vol zit, terwijl het huidige ram op zo'n 1/3e gebruikt wordt.

M'n cacti metingen stopten er ook mee, zo is hier goed te zien dat m'n geheugenverbruik er niet meer doorheen kwam.

Free geeft mij:

mem:	total	used	free
ram	1518504	1517760	35124
swap	1502036	1487716	14320

Terwijl htop mij kan vertellen dat m'n memory usage 638/1516MB is, en m'n swap op 1452/1466 staat.

Ik zit te kijken of ik swap niet tijdelijk uit kan zetten door swapoff, helaas na het uitvoeren hiervan:

swapoff: /dev/sda5: Cannot allocate memory

Als ik zo lees is dat begrijpelijk, het wordt eerst naar het fysieke ram geschreven voordat swap uitgaat.

Als ik bij htop, top of ps kijk, zie ik dat mysql de enige "grootverbruiker" is met 10 processen van 1% per process.

Dus waar ik tegenaan loop is: hoe kan ik m'n swap leegmaken zonder dat m'n fysieke geheugen vol gaat lopen?
En hoe kan het zijn dat m'n swap volblijft?

[Kees]

swapiness verlagen, en als je hem nu leeg wil hebben; reboten.

[kKaltUu]

Kees schreef op donderdag 03 juni 2010 @ 14:55:
swapiness verlagen, en als je hem nu leeg wil hebben; rebooten.

swapiness stond op 60, heb het een halfuur geleden op 10 gezet dmv

sudo sysctl -w vm.swappiness=10

Ik snap dat ik kan rebooten, maar ik gebruik dat liever als last-resort.

Is er een manier om m'n swap meteen leeg te laten lopen, ook als is er niet genoeg ram beschikbaar om een swapoff te doen?

[ Voor 15% gewijzigd door kKaltUu op 03-06-2010 15:18 ]

[hostname]

In swap staat ook gewoon memory dat door een proces (of de kernel) is geclaimd. Als je je swap wil legen; dan moet je dus processen die veel geheugen gebruiken stoppen. Kijk eens met top of ps welke processen veel memory gebruiken. En wat geeft free bij de buffer/caches? als je hele swap volzit met buffers en/of caches maakt het ook niet zo heel veel uit, die worden er toch uitgehaald als het echt nodig is.

[daft_dutch]

Moest swap niet minstens twee keer je Ram zijn. was volgens mij een vuist regel.
Dit omdat als je gaat swappen je niet weet hoe veel ram er wordt weg gezet naar de swap. (kan zo maar 80% zijn) dat twee keer en je geheugen is goner

Ik snap dat ik kan rebooten, maar ik gebruik dat liever als last-resort.

Dat is inderdaad nooit nodig. Je kan "tijdelijk" een swap disk maken. lees dit en ook de swap vuistregel op

http://www.linux.com/news...ll-about-linux-swap-space

[kKaltUu]

Free:	total	used	free
-/+ buffers/cache	.	664844	888040

Staat dus genoeg free, en met htop op memory geselecteerd zie ik niets speciaals.

Heb een swapfile gemaakt, zie dit ook netjes erbij geteld worden, helaas blijft er nog 1.5GB vaststaan.
Ik heb in ieder geval wat ruimte om mee te spelen, zal kijken of ik een swapoff kan doen.

[Predator]

daft_dutch schreef op donderdag 03 juni 2010 @ 17:12:
Moest swap niet minstens twee keer je Ram zijn. was volgens mij een vuist regel.
Dit omdat als je gaat swappen je niet weet hoe veel ram er wordt weg gezet naar de swap. (kan zo maar 80% zijn) dat twee keer en je geheugen is goner

Dat is een regel van vroeger. Die geldt enkel voor kleine RAM volumes en voor desktops.
Voor servers wordt dat snel absurd.
16GB ram betekent je dat 32GB swap moet nemen

Beter is bv 1/2 of maximum 1.

RH geeft trouwens de volgende info:

1.Systems with 4GB of ram or less require a minimum of 2GB of swap space
2.Systems with 4GB to 16GB of ram require a minimum of 4GB of swap space
3.Systems with 16GB to 64GB of ram require a minimum of 8GB of swap space
4.Systems with 64GB to 256GB of ram require a minimum of 16GB of swap space

Bron

* Predator vermijdt swapping. Memory rules, swap sucks
Ik denk niet dat ik een server heb die al zijn swap partitie aangeraakt heeft.

[ Voor 6% gewijzigd door Predator op 04-06-2010 10:11 ]

[H!GHGuY]

Waarom is het een probleem dat je swapspace volstaat?
Linux regelt dat allemaal netjes voor je. Niks van aantrekken dus.

Als je teveel geheugen gebruik hebt (mem+swap) dan moet je andere maatregelen nemen en op zoek gaan wie de grootverbruikers zijn mbv top, vmstat, lsof, enz.

[kKaltUu]

Mijn beeld van swap is dat als het fysieke geheugen van de server (bijna) vol zit, dit in elk geval wat geheugenverbruik opvangt door het naar een swappartitie/swapfile te schrijven. Natuurlijk wil ik dan wat vrij hebben *voorhetgevaldat*

Swapfile aanmaken was gisteravond gelukt, hierna kon ik ook swapoff doen, in de loop van de ochtend van 1 tot 4 uur het swapverbruik verlaagd is.
Ik ga het de komende dagen even aanzien, maar waarschijnlijk is het ergste al achter de rug.

Het liefste zou ik ook een hele sloot ram in de server gooien, maar vanwege de ouderdom zing ik het liever uit tot er ... financiële ruimte vraag is voor een nieuwe.

[Kees]

H!GHGuY schreef op vrijdag 04 juni 2010 @ 12:19:
Waarom is het een probleem dat je swapspace volstaat?
Linux regelt dat allemaal netjes voor je. Niks van aantrekken dus.

Als je teveel geheugen gebruik hebt (mem+swap) dan moet je andere maatregelen nemen en op zoek gaan wie de grootverbruikers zijn mbv top, vmstat, lsof, enz.

Het is ook geen probleem, alleen nagios klaagt er bij mij over

We hebben een server met 72G ram, en 4G aan swap (no way dis ik daar 144G aan swap bij ga doen op de SSD's ). Die 4G zit ook helemaal nokjevol, maar dat komt omdat we het geheugen redelijk goed ingesteld hebben, zodat er nog wel 1-2 gig vrij zijn. Helaas ziet linux dit dan als een teken om zo veel mogelijk uit te swappen, want het geheugen is voor 80%+ vol (ex cache). Het is verder geen probleem, want met de swapiness op een lage waarde doet hij gelukkig niet zoveel meer met de swap.

[u_nix_we_all]

Soms is het efficienter om je geheugen voor buffers en cache te gebruiken dan voor het in-memory houden van bepaalde processen. Niet gebruikte RAM heeft niemand wat aan, dus liever een klein beetje swap en al je geheugen in gebruik met cache en buffers, dan vrij geheugen IMHO.

[Mijzelf]

Kees schreef op vrijdag 04 juni 2010 @ 14:27:
We hebben een server met 72G ram, en 4G aan swap (no way dis ik daar 144G aan swap bij ga doen op de SSD's ). Die 4G zit ook helemaal nokjevol, maar dat komt omdat we het geheugen redelijk goed ingesteld hebben, zodat er nog wel 1-2 gig vrij zijn. Helaas ziet linux dit dan als een teken om zo veel mogelijk uit te swappen, want het geheugen is voor 80%+ vol (ex cache). Het is verder geen probleem, want met de swapiness op een lage waarde doet hij gelukkig niet zoveel meer met de swap.

Waarom zet je de swap dan niet gewoon uit?

[H!GHGuY]

kKaltUu schreef op vrijdag 04 juni 2010 @ 13:51:
Mijn beeld van swap is dat als het fysieke geheugen van de server (bijna) vol zit, dit in elk geval wat geheugenverbruik opvangt door het naar een swappartitie/swapfile te schrijven. Natuurlijk wil ik dan wat vrij hebben *voorhetgevaldat*

Swap is een backing store voor je RAM. Je kan het zien als een overloopbuffer. Als je RAM overloopt dan gaat de kernel aan het werk om pagina's (typisch 4KB) van RAM naar swap te schrijven om aan nieuwe geheugenrequests te voldoen. Wanneer dan toch plots een pagina uit je swap nodig is, moet die terug in RAM gehaald worden en moeten er mogelijk andere pagina's naar swap wijken.

Hetzelfde geldt voor open files. Die worden in de cache geplaatst (of rechtstreeks via memory map) en ook dan kun je de file zelf zien als backing store voor je RAM. Alle writes blijven in RAM. Is er echter te weinig RAM beschikbaar dan gaat de kernel alle writes die enkel in RAM staan maar nog niet daar disk geflushed zijn effectief gaan wegschrijven om zo de RAM pagina te kunnen gebruiken voor andere doeleinden.

Diezelfde optimalisatie kan ook op de swap: pagina's die ingeswapt zijn, kunnen ook nog in de pagefile staan. Als er iets moet uitgeswapt worden en die pagina is niet veranderd (en ook niet recent meer opgevraagd) dan kan die pagina zonder extra moeite gebruikt worden voor andere doeleinden want de content is nog in de pagefile beschikbaar.

Bottom-line is dat swap<->RAM onderhand zo optimized is dat je je er niet van moet aantrekken. Het wordt pas een probleem als je te weinig RAM hebt en er enkel nog geswapt wordt. Deze situatie heet trashing en heeft als gevolg dat je PC niet vooruit te branden is.

[silentsnake]

Ik heb zelf wel eens problemen gehad met een Oracle server met 32GB geheugen en 2 GB swap waarbij die op een gegeven moment ook door z'n swap heen was. Het rare was alleen dat er 20 van de 32GB gecachet was maar hij zat tijden lang alsnog met een volle swap partitie. Alleen als ik keihard de cache dropte (echo '3' > /proc/sys/vm/drop_caches) had ie weer 20GB vrij en was die swap partitie weer leeg na verloop van tijd.

swappiness van 60 naar 40 gezet en het probleem was weg. Toch blijf ik het raar gedrag vinden dat ie ging swappen en niet die cache ging flushen.

[H!GHGuY]

silentsnake schreef op zondag 06 juni 2010 @ 10:32:
Ik heb zelf wel eens problemen gehad met een Oracle server met 32GB geheugen en 2 GB swap waarbij die op een gegeven moment ook door z'n swap heen was. Het rare was alleen dat er 20 van de 32GB gecachet was maar hij zat tijden lang alsnog met een volle swap partitie. Alleen als ik keihard de cache dropte (echo '3' > /proc/sys/vm/drop_caches) had ie weer 20GB vrij en was die swap partitie weer leeg na verloop van tijd.

swappiness van 60 naar 40 gezet en het probleem was weg. Toch blijf ik het raar gedrag vinden dat ie ging swappen en niet die cache ging flushen.

Dan heb je't waarschijnlijk over higher order allocations (grote sizes dus). Dan kan het wel eens zijn dat ie net iets te snel tot de conclusie komt dat er geen RAM beschikbaar is. Sinds een recentere kernel (was het .33 of .34) is er memory compaction, die daar mogelijk wel wat in helpt.
Bovendien is geheugen in de cache ook niet altijd vrij te geven. RAMdisk en het executable stuk van applicaties in RAM tellen vziw ook mee in cached.

Bovendien gebruikt Linux ook heuristics om te beslissen wanneer hij wel of geen geheugen meer aan een proces geeft. Hierbij worden de Virtual Set Size en Resident Set met elkaar vergeleken, alsook rekening houdend met totale hoeveelheid en beschikbaarheid van RAM. Je kan dit gedrag afzetten door de overcommit (/proc/sys/vm/overcommit of zoiets) uit te zetten.

[kKaltUu]

Ohai, even tot slot:
M'n memory zelf zat na het free-en van de swap behoorlijk vol, bleek dat apache het niet 100% had gedropped. restart van apache loste het probleem op.

[Verwijderd]

kKaltUu schreef op donderdag 08 juli 2010 @ 12:45:
Ohai, even tot slot:
M'n memory zelf zat na het free-en van de swap behoorlijk vol, bleek dat apache het niet 100% had gedropped. restart van apache loste het probleem op.

Ah, dus je hebt het probleem over een paar maanden weer? Je hebt het probleem dus niet opgelost, je hebt een work-around gevonden.

[Wolfboy]

Nog even voor de voor de volledigheid, waarom heb je je swap niet leeggemaakt door een swap image te maken, de oude swap weg te halen en weer terug te zetten?