Top: geheugengebruik achterhalen [Ubuntu]

[st0p]

Ik heb sinds enige tijd een VPS pakketje en ik was vanavond bezig met het beestje inrichten. Ik heb tot drie keer toe niet veel meer gedaan dan de volgende zaken:

code:

apt-get update
apt-get upgrade
apt-get install aptitude
apt-get install php5 php-pear php5-suhosin
apt-get install mysql-server

Eigenlijk bij alles wat ik daarna probeer krijg ik segfaults of mededelingen dat er niet geforked kan worden. Na even googelen leek een tekort aan geheugen een potentiele kandidaat. Aangezien het el cheapo abbo wat ik heb maar 256MB geheugen heeft, is dat zeker een optie. Een blik in het control panel van de provider geeft aan dat ik 95% gebruik van die 256MB. Als ik top gebruik krijg ik de volgende uitkomsten:

code:

top - 00:52:42 up 19 min,  1 user,  load average: 0.00, 0.00, 0.00
Tasks:  14 total,   1 running,  13 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    262144k total,   258388k used,     3756k free,        0k buffers
Swap:        0k total,        0k used,        0k free,        0k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1193 mysql     15   0  136m  17m 5740 S    0  6.7   0:00.31 mysqld
 3421 www-data  15   0 35784 9872 3748 S    0  3.8   0:01.65 apache2
 1218 bind      25   0 80124 9712 2224 S    0  3.7   0:00.04 named
 3419 root      18   0 33552 7564 4064 S    0  2.9   0:00.04 apache2
 3435 www-data  15   0 34016 5160 1228 S    0  2.0   0:00.02 apache2
 1415 root      15   0  8544 2836 2232 S    0  1.1   0:00.56 sshd
 1296 root      18   0  5600 2148 1728 S    0  0.8   0:00.01 sshd
 1427 root      18   0  3096 1748 1400 S    0  0.7   0:00.10 bash
 1324 root      15   0  9736 1712  576 S    0  0.7   0:00.01 sendmail-mta
    1 root      15   0  2604 1488 1232 S    0  0.6   0:00.22 init
 3452 root      15   0  2448 1128  920 R    0  0.4   0:00.21 top
 1142 root      21   0  2176  968  808 S    0  0.4   0:00.01 xinetd
 1154 root      15   0  2216  888  704 S    0  0.3   0:00.00 cron
 1209 syslog    18   0  2020  708  572 S    0  0.3   0:00.01 syslogd

De hoeveelheid beschikbaar geheugen is inderdaad belabberd, Echter, als ik de percentages bij elkaar optel kom ik op ongeveer 25%. Ik heb geprobeerd met n 100 in top meer processen weer te geven, maar dan blij ik een gelijk aantal processen zien, met een verglijkbaar geheugen gebruik. Heeft iemand enig idee wat ik kan doen om te zien waar de resterende 70% heen is?

[blaataaps]

Zie bijvoorbeeld FAQ Non-Windows Operating Systems - Overige vragen

256 megabyte en 0 swapspace is inderdaad behoorlijk aan de krappe kant, zeker voor apache, mod_php en mysql samen.

[Xesxen]

Zou ik mogen weten waar je deze vps afneemt, en hoeveel je er voor betaald?

[alx]

Dat percentage is afgeleid van de RES (resident) kolom, maar dat is niet alles. Volgens mij zit daar geen SHR (shared), want dat is niet duidelijk toe te schrijven aan 1 proces (zoals voor de programma en lib instructies als meerdere keren in gebruik) en mss ook geen stacks (niet zeker), en dan is natuurlijk nog kernel geheugen in gebruik. Met zo weinig vrij geheugen zal de performance ook wel belabberd zijn, want er is dan ook nauwelijks ruimte voor kernel I/O caching e.d. En er hoeft maar iets te gebeuren en de kernel OoM (out of mem) killer gaat een proces afschieten... Helemaal geen enkele swap space lijkt me ook niet handig.

Kun je niet gewoon wat meer krijgen? 256 MB voor een server, tja, het is niet onmogelijk, maar zeker zonder enige swap beetje onnodig moeilijk doen...

[st0p]

Dank voor de link naar de FAQ (suf dat ik daar zelf niet in gekeken heb)

Ik beschouwde die 256MB al als een "uitdaging". Ik ben al aan het kijken of ik een swap partitie kan toevoegen, maar ik kan in /dev geen sda of hda vinden, wat volgens mij wel nodig is om parted te kunnen gebruiken.

Ik programmeer thuis al een tijd in een debian 6 VM met 1024MB geheugen en 1024MB swap. Daarin werkt alles prima. Het gaat hier ook niet over gigantische grote databases: 2 tabellen, een met 200 rijen en de ander ongeveer 2500 rijen. Wat is dan de minimum hoeveelheid geheugen waar ik aan moet denken? (zeker als ik het niet voor elkaar krijg om die swap aan de praat te krijgen)

@Xesxen: http://www.hostslim.nl/

[CAPSLOCK2000]

In /proc/partitions kan je zien wat je systeem zoal aan storage kent.

256MB kan werken, maar je zal het wel echt moeten gaan tweaken. Is die named echt nodig? Kun je sendmail vervangen door iets kleiners? Vervang Apache door lighttpd of nginx. Als je database zo klein is kun je MySQL krapper afstellen, of misschien zelfs wel vervangen door sqlite.

[DeadLock]

Hmm, ik zie eigenlijk an sich geen probleem in die 256MB? Ik heb zelf ook een simpel vps'je met 256mb ram, met daarop ook de lamp stack en mailserver en nog wat kleine grut. Momenteel is er nog ongeveer de helft van het ram vrij...

Het is een default debian 6 installatie.

[st0p]

die hoop had ik dus ook nog, dat het wel ging lukken met 256MB (ik moet ook eerlijk bekennen dat het nu natuurlijk ergens mijn eer te na is om de boel niet aan de praat te krijgen, hoe crappy ook). Ik zou zelf ook een voorkeur hebben gehad voor debian, maar toen ik die gisteren als eerste installeerde krijg ik bij zowel apt-get, dpkg en aptitude de melding dat het een onbekend commando was. Dselect ben ik toen vergeten, misschien dat dat wel ging werken maar toen had ik het al gezien...

Ondertussen heb ik (tig installs later) sendmail en apache eraf en lighttpd draaien. mysql staat er nog vanilla op, later vandaag maar eens kijken of we die ook wat kunnen tweaken.

/proc/partitions bestaat bij mij helaas niet. Ik heb even gekeken met mount (weet eigenlijk niet zeker of dat zin heeft) en kreeg de volgende output:

code:

/dev/simfs on / type simfs (rw,relatime,usrquota,grpquota)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /dev/pts type devpts (rw,relatime)

ik heb geprobeerd om met parted verder te klooien:

code:

root@vps:/proc# parted /dev/simfs
Error: Error opening /dev/simfs: Permission denied

voor zover ik kan vinden is simfs iets van openVZ, en daar draait het inderdaad onder. Heb dus zeer mijn twijfels of ik het ooit voor elkaar ga krijgen om een swap partitie aan te maken.

[Nick_S]

quote: http://forums.vpslink.com...te-swapfile-your-vps.html

How to create a swapfile in your VPS
DON'T!!!!

We've been noticing quite a few people trying to add more memory to their VPS by creating a swapfile. This will NOT work, and will only result in your VPS being unbootable.

If you need more memory, upgrade via the control panel.

We don't have the full specifics of why OpenVZ will not allow this, but our theory (based on the resource utilization reports in /proc/user_beancounters, and the error messages we receive when the VPS will not start) is that when you enable swapping on the file, the resource allocation is NOT increased, and the use of the additional memory from the swapfile causes you to use more memory than is assigned to your VPS. This means the OpenVZ resource system kills processes and refuses to allocate more memory (since it thinks you are using more memory than you are paying for) and logs memory overutilization errors. When trying to restart the VPS, the massive numbers of memory overutilization prevent the VPS from even booting.

The only way we are able to restart your VPS if you do this, is to reboot the hardware node (which would affect all other VPS's also hosted on the same node, not something we are likely to do) or rebuild your VPS from scratch manually. So please, don't try to add more memory to your system with a swapfile, it just doesn't work.

Update: Even running mkswap seems to trigger this problem, so our theory is not completely correct. Still does not change the fact that it causes the VPS to be unbootable without manual intervention.

Update (12/24/2008): Note that this applies only to OpenVZ VPS's. Our newer Xen VPS's allow for creation of swap files to increase available memory, at the expense of disk i/o in extreme cases.

[CAPSLOCK2000]

st0p schreef op donderdag 19 januari 2012 @ 13:33:
die hoop had ik dus ook nog, dat het wel ging lukken met 256MB (ik moet ook eerlijk bekennen dat het nu natuurlijk ergens mijn eer te na is om de boel niet aan de praat te krijgen, hoe crappy ook). Ik zou zelf ook een voorkeur hebben gehad voor debian, maar toen ik die gisteren als eerste installeerde krijg ik bij zowel apt-get, dpkg en aptitude de melding dat het een onbekend commando was. Dselect ben ik toen vergeten, misschien dat dat wel ging werken maar toen had ik het al gezien...

Weet je zeker dat het Debian was? Bovenstaande kan bijna niet kloppen. Geen aptitude wil ik wel geloven, geen apt-get niet, en geen dpkg is imho onmogelijk.

Ondertussen heb ik (tig installs later) sendmail en apache eraf en lighttpd draaien. mysql staat er nog vanilla op, later vandaag maar eens kijken of we die ook wat kunnen tweaken.

Vervang/verwijder ook named (aka Bind).

[Thralas]

st0p schreef op woensdag 18 januari 2012 @ 22:44:
Ik beschouwde die 256MB al als een "uitdaging". Ik ben al aan het kijken of ik een swap partitie kan toevoegen, maar ik kan in /dev geen sda of hda vinden, wat volgens mij wel nodig is om parted te kunnen gebruiken.

Mooi. Bij elk probleem met een VPS zijn er weer 3 posters die roepen dat 256MB toch echt veel te weinig is voor een simpele webserver-setup. Mits je bereid bent wat te tunen past dat ik 95% van de gevallen makkelijk.

That said, je hebt 'helaas' een OpenVZ-VPS. Zodra je tegen limieten aanloopt is het altijd slim om even user_beancounters te bekijken:

cat /proc/user_beancounters

Het geheugengebruik (MemFree/MemTotal) dat je ziet reflecteert privvmpages. Een too-little known fact van OpenVZ is dat page allocations worden gerekend, niet het daadwerkelijk aantal gebruikte pages. Dit is dus ook de reden dat de som van de RES-kolom in top niet gelijk is aan je RAM.

Er is dus een process dat een hoop geheugen allocated heeft. Probeer eens systematisch services te stoppen totdat je de boosdoener gevonden hebt.

Ga ik het toch (deels?) verklappen: stop bind eens