Linux, care a mâncat toată memoria

Apoi am ajuns într-o căutare și a găsit script ps_mem.py. care contorizează numărul de procese de memorie. Script-ul este scris în Python, un post despre el aici: consumul de memorie Numărarea protsecsami pe Linux. Dar, de asemenea, arată că, în mod colectiv procese nu consuma la fel de mult de memorie.

Apoi m-am gândit că problema este cu kernel-ul, și a urcat să caute informatii, pe cuvintele cheie: „dimensiunea Linux RAM nu este corect“, fie că datoria pe termen scurt, dar am găsit aici este un răspuns la unul din mesajele:

După cum am înțeles, pe „folosit“ de memorie Linux este împărțit în „activ“ și „inactiv“.

Memoria activă este memoria care este alocat unui proces și în cazul utilizării de către acesta.

Inactiv este de memorie care a fost alocată unui proces, dar nu mai este în uz de acesta (a fost eliberat). Repartitorul pune această memorie pe de o parte pentru o utilizare ulterioară, dar nu-l gol. În cazul în care aceleași date pe care se află în acel bloc de memorie este solicitat din nou doar re-bloc de memorie, care alocă pentru acest proces. În cazul în care se solicită un bloc de memorie și nu există nici o memorie „curat“ lăsat începe să re-alocarea această memorie „murdar“.

Examinarea / proc / meminfo pot arăta cât de mult din memorie „folosit“ este activă și cât de mult este inactiv.

Pe scurt, sunt scrise următoarele: în memoria Linux este împărțit în activ și inactiv. Inactiv este cea care a subliniat procesul, dar cele mai multe nu le folosesc. Repartitorul (vydelyator 🙂) își rezervă această memorie pentru o utilizare ulterioară, și nu o purifica. În cazul în care va fi necesară datele sunt aranjate în memorie, el le va reveni imediat. În cazul în care un alt proces este necesar, această memorie și nu va fi „memorie pură“, atunci acesta va fi distribuit ca o memorie inactivă.

Cu alte cuvinte, utilizarea de optimizare, iar datele nu sunt eliminate în mod inutil din memorie, dar dacă este necesar, această memorie vor fi alocate procese. Prin urmare, vom trage concluzii: în cazul în care o mare parte a memoriei este inactiv, atunci totul este în regulă.

Verificați numărul de memorie inactiv poate fi după cum urmează:

După cum puteți vedea, 11 GB (11521124 kB). Ele sunt inactive de memorie, și 1,95 Gb (1958840 kB). utilizate efectiv, adică Este activ. Deci, în cazul meu, nu există nici un consum în exces.

Rezumând, vreau să rețineți că destul de des, întregul punct al problemei constă în lipsa de calificare a garniturii între scaun și monitorul și ar trebui să fie lucrat la 🙂

- Și am rupt fiecare server în decurs de cinci minute.
- E un hacker.
- Nu. El - starea de spirit @ k.

Am câștigat pe forum. Toate aspectele care nu se referă la articol, precum și întrebări specifice pentru cazul dumneavoastră, trebuie să cereți și să discute acolo, în „User Help“.

„După cum se poate vedea, 11 GB (11521124 kB), sunt inactive de memorie și 1,95 GB (1958840 kB), este utilizat de fapt, care este activ. Deci, în cazul meu, există un exces de consum.“

Um. Cum de a dezactiva memoria activă? Din cauza lipsei de memorie un server pentru a schimba afară, și el începe să încetinească.

Puteți încerca să curățați cache-urile de la rădăcină, așa cum este descris aici.

# Pentru pagecache gratuit:
sincronizați echo 1> / proc / sys / vm / drop_caches

# Pentru dentries gratuite și inodes:
sincronizați echo 2> / proc / sys / vm / drop_caches

# Pentru a elibera pagecache, dentries și inodes:
sincronizați echo 3> / proc / sys / vm / drop_caches
dar acest lucru nu este de obicei necesară, deoarece Acesta este angajat în nucleul sistemului de operare, dacă este necesar.

În cazul în care memoria se execută afară și devine în schimb, este necesar să se caute un proces care îl consumă și pentru a limita la aceasta.

Vă mulțumesc, veni la îndemână. informații foarte utile.

Vă mulțumesc, foarte util

Brilliant! De asemenea, deja încercat totul este posibil, totul este mai ușor. Mulțumesc mult.

ceas această situație pe Debian 8 Nginx + php-fpm, MySQL, Mongo, RAM de 8 GB.
se sprijină în mod liber 800-1000M
Când porniți o sarcină serioasă de utilizatori 50-80, memoria este 200M, și Nginx dă 504.
În cazul în care cache-ul curat echipa a lansat 6GB și totul începe să zboare.
În ceea ce poate fi o problemă, de ce nu php înlocuiește memoria inactiv?

Bună ziua, eu nu sunt cu adevărat un expert și arhitectură a memoriei, dar cred că problema nu este în php, memorie conduce OS și PHP poate cu greu ceva de-a face cu ea.
Încercați-l în acest timp, atunci când există 504, verificați următoarele:
1. Verificați numărul de php-ul se blochează procesele active (pentru a începe cu, de exemplu, același ps -A | grep php) și modul în care această cifră corespunde cu configurația php-fpm
2. Ce mănâncă MySQL, Mongo. Dacă mai mult decât vă așteptați, atunci trebuie să modificați configurația.

Cred că problema este că nu este lansat complet procesul de a muri php, în cele din urmă au devenit atât de numeroase încât nu pot multiplica. Dacă este așa, atunci este necesar pentru a optimiza codul de timp a fost redus script-ul.

Poate fi completat printr-un articol ca o echipă pentru a curăța memoria - gratuit sincronizați echo 3> / proc / sys / vm / drop_caches echo "" gratuit

nu fi leneș să spun mulțumesc: „Vă mulțumesc!“. A fost Infa extrem de relevant.
PS: cu CAPTCHA, IMHO, prea mult.

Vă mulțumim! Din contul captcha Sunt de acord, dar nu au ajuns la remake-ul. Și fără să-l sooo mult impotriva spam-urilor.

Multumesc pentru info,
toate blogurile scrie cum să optimizați,
totul se face, iar numărul nu se schimbă, se pare că che

Vă rugăm să bucuros să vă ajute!

Vă mulțumesc, informații este pur și simplu minunat!

Vă mulțumim! Mă bucur că este util pentru tine!

Vă mulțumesc, informații foarte utile.