[rosedu-admins] [Fwd: Re: Probleme memorie masini mamba]

[Mircea Bardac]

Salut,

> On Sat, 2009-02-28 at 21:55 +0200, Sergiu Iordache wrote:
>> Nu mai țin minte care era situația dar totuși nu ar trebui să avem
>> swap pe mașinile virtuale de pe mamba? M-am trezit azi cât lucram la
>> CDL fără memorie de nu mai puteam să fac nimic.. după un timp și-a
>> revenit în mod surprinzător.

Masinile virtuale nu vad direct swap-ul, ci doar o "gramada" mare de
memorie.

Am pus pe masina noua rosedu un script (/root/vmem) care afiseaza
memoria disponibila in masina.

Exemplu output (in acest moment):
# /root/vmem
Memory limit...: 512 MB (burstable: 1280 MB)
    [vmguardpages(barrier)),  burstable: privvmpages(limit)]
Requested......: 324 MB (63%) [privvmpages(held)]
Current usage..: 128 MB (25%) [physpages(held)]
Free memory....: 384 MB (75%)

In traducere:
- masina are 512 MB garantati (in conditiile in care toate masinile sunt
incarcate full, 512 MB vor fi intotdeauna disponibili) [1] -  - aici mai
apare si optiunea de oomguarpages (inca nemodificata, set to defaults)
are o valoare default, nu ar trebui sa influenteze sistemul in "viitorul
apropiat" (yet to be defined)
- atat timp cat exista memorie disponibila pe masina host, procesele pot
ocupa pana la 1280MB RAM)
- 324MB sunt alocati in prezent de aplicatii
- din cei 324MB, 128MB sunt de fapt folositi
- in concluzie, raman practic liberi: 384 MB RAM (512-128=384); da,
poate sa apara si 0 (zero), atunci cand masina foloseste mai mult de
512MB RAM.

Exista acest articol [5] care descrie limitele destul de bine folosind
un grafic.

Din cate observ in "cat /proc/user_beancounters", problemele pe care
le-a avut masina au tinut de:
* kmemsize - [2]: Size of unswappable memory in bytes, allocated by the
operating system kernel. It includes all the kernel internal data
structures associated with the container's processes, except the network
buffers discussed below. These data structures reside in the first
gigabyte of the computer's RAM, so called “low memory”. (in prezent are
ca valoare 8MB, limita e 14MB, limita atinsa de 1100 ori)
* othersockbuf - [3]: The total size of buffers used by local
(UNIX-domain) connections between processes inside the system (such as
connections to a local database server) and send buffers of UDP and
other datagram protocols. (in prezent 2312 bytes, limita 1126080 bytes,
limita atinsa de 2 ori)

Poate fi oricand verificat fisierul "/proc/user_beancounters" [4]. Nu
sunt convins daca ar trebui modificate valorile sau daca este o problema
de configurare a sistemului. Dat fiind experienta anaconda, am o usoara
inclinatie catre varianta a 2-a. Voi mai discuta cu RazvanD, caci nu
cunosc prea bine implicatiile unei modificari in configuratie. Intre
timp, poate reusiti sa izolati problema/problemele care au cauzat
spike-urile in kmemsize si othersockbuf (am un feeling ca au legatura cu
mysql-ul si cu apache-ul... care zburda libere sub forma de multe procese).

Din nefericire, nu avem monitorizare (inca), pentru a putea face un
tracking mai eficient in asemenea situatii. Somebody is working on this
(nagios setup).

Observatie - dupa cum am spus si mai sus, inca nu am configurat
oomguarpages... maybe we should (necesita ceva calcule though).

P.S. am Cc-uit si rosedu-admins at lists.rosedu.org, probabil e-mail-ul are
nevoie de moderare

[1] http://wiki.openvz.org/Vmguarpages#vmguarpages
[2] http://wiki.openvz.org/Kmemsize#kmemsize
[3] http://wiki.openvz.org/Othersockbuf#othersockbuf
[4] http://wiki.openvz.org/UBC_parameters
[5] http://maxgarrick.com/understanding-openvz-resource-limits/

-- 
Mircea
http://mircea.bardac.net