Bir işlemin gerçek bellek kullanımı


20

Aşağıdakiler, sunucumun sırasıyla mysqlve bellek kullanımıdır apache. Çıkışında gereğince pmapsöz hakkından, mysql379M hakkında kullanıyorsa ve apache277m kullanıyor.

[root@server ~]# pmap 10436 | grep total
 total           379564K

[root@server ~]# pmap 10515 | grep total
 total           277588K

Bunun çıktısıyla karşılaştırıldığında top, değerlerin neredeyse eşleştiğini görüyorum.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
10515 apache    20   0  271m  32m 3132 S  0.0  6.6   0:00.73 /usr/sbin/httpd
10436 mysql     20   0  370m  21m 6188 S  0.0  4.3   0:06.07 /usr/libexec/mysqld --basedir=....

Şimdi bu değerler kesinlikle bu iki sürecin şu anki bellek kullanımı değildir, çünkü eğer olsaydı ramsistemimdeki 512M'yi aşmış olurdu ve bunların gerçekte değil, bu iki işleme atanan sayfaların boyutu olduğunu anlıyorum. aktif olarak kullandıkları belleğin boyutu. Şimdi, kullandığımızda pmap -x, Dirtysüreç için çok daha az bellek kullanımını gösteren ekstra bir sütun görüyorum . Aşağıdaki örnekte görüldüğü gibi, Dirtykolon, birinci kolonda 379M yerine 15M gösterir. Sorum şu: Sütun altındaki değer Dirty, bu işlem tarafından aktif olarak kullanılan 'gerçek' bellek miktarı mı? Değilse, bir sürecin gerçek bellek kullanımını nasıl bulabiliriz? Yukarıda değil psve topaynı nedenlerle. Altında bir şey var mı/proc bu bilgiyi verecek mi?

[root@server ~]# pmap -x 10436 | grep total
total kB          379564   21528   15340
[root@server ~]#


[root@server ~]# free -m
             total       used       free     shared    buffers     cached
Mem:           489        447         41          0         52        214
-/+ buffers/cache:        180        308
Swap:         1023          0       1023
[root@server ~]#

Yanıtlar:


18

Bir işlemin gerçek bellek kullanımı diye bir komut yoktur, çünkü bir işlemin gerçek bellek kullanımı diye bir şey yoktur .

Bir işlemin her bir bellek sayfası (diğer ayrımların yanı sıra) olabilir:

  • Yalnızca bu işlem tarafından kullanılan geçici depolama.
  • Çeşitli mekanizmalar kullanarak diğer süreçlerle paylaşılır.
  • Bir disk dosyası tarafından yedeklenir.
  • Fiziksel bellekte veya takasta.

Bence "kirli" rakam RAM (takas değil) ve bir dosya tarafından desteklenmeyen her şeyi toplar. Bu, hem paylaşılan hem de paylaşılmayan belleği içerir (çoğu durumda sunucuları çatallamak dışında, paylaşılan bellek yalnızca bellek eşlemeli dosyalardan oluşur).

Tarafından görüntülenen bilgiler ve ' pmapden gelir . Sürecin gerçek bellek kullanımı budur - tek bir sayı ile özetlenemez./proc/PID/maps/proc/PID/smaps


6

Ben aynı kaynaklardan üstüne benzer analiz ve çizim bilgisini yapar ben bir uygulama için kılavuz sayfasında yazdığı bir şeyi alıntı edeceğiz pmap(örneğin /proc/[N]/maps):

SANAL ADRES ALANI VS. FİZİKSEL HAFIZA

Yukarıdaki istatistiklerin bazılarının yorumlanmasında sanal adres alanı ile fiziksel bellek arasındaki farkın anlaşılması önemlidir . Adından da anlaşılacağı gibi, sanal adres alanı gerçek değildir; temelde bir işleme tahsis edilmiş olan tüm belleğin haritasıdır. Bu haritanın boyutundaki sınır her işlem için aynıdır (genellikle 2-4 GB) ve birikmez (yani , her biri kendi 2-4 GB sanal adresine sahip düzinelerce veya yüzlerce işleminiz olabilir. yalnızca 512 MB fiziksel belleğe sahip bir sistemde ).

Veriler aslında sanal adres alanından depolanamaz veya alınamaz; gerçek veriler gerçek, fiziksel bellek gerektirir. Birini diğerine göre yönetmek çekirdek işidir. Sanal alan istatistikleri (VirtualSz, Data + Stack ve Priv & Write), bir işlemin yapısını ve fiziksel bellek kullanımı ile ilişkisini dikkate almak için yararlıdır, ancak gerçekte kullanılan RAM miktarı ile ilgili olarak fiziksel bellek istatistikleri (ResidentSz, Share ve Oran) önemlidir.

pmapçoğunlukla size sanal adres alanı hakkında bilgi veriyor . topÇıktıdaki "değerlerin neredeyse eşleştiğini" gözlemlemeniz, muhtemelen RES rakamından çok farklı olan VIRT rakamını ifade eder. Bunlar tam olarak yukarıda "VirtualSz" ve "ResidentSz" olarak etiketlediklerime karşılık gelir (VIRT sanal içindir, RES yerleşik içindir).

Şimdi, pmap -x kullandığımızda, işlem için çok daha az bellek kullanımı gösteren fazladan kirli bir kolon görüyorum. Aşağıdaki örnekte görüldüğü gibi, Dirty coloumn, birinci kolonda 379M yerine 15M gösterir. Sorum şu: Kirli sütunun altındaki değer Kirli, bu işlem tarafından aktif olarak kullanılan 'gerçek' bellek miktarı mı?

Hayır, ama bir çeşit. "Kirli" bellek, diskten yüklenen ve daha sonra değiştirilen verilere karşılık gelir; değiştirildiği için, yerleşik belleğin bir parçası olması gerekir, çünkü bu değişiklikler şu anda RAM'de saklanır. Ancak, onunla eşanlamlı değildir.


Katılıyorum. Ancak 2 - 4GB 32 bit sistemler içindir. Günümüzde çoğu sistem muhtemelen 64bit'tir.
ctrl-alt-delor

3

Sanal bellek hızlı arama numaraları gibidir, ancak yaklaşık 3 milyar veya bunların dışında (32 bit sistem için, 64 bit çekirdeğinde 32 bit uygulama için 4 milyar, 64 bit uygulama için çok daha fazlası) ve doğrudan numara çeviremezsiniz, hızlı aramaya eşleştirilecek.

Birçok işlemde aynı adres (telefon numaraları) için farklı eşlemeler (hızlı arama numaraları) olabilir. Örneğin, birkaç kütüphaneyi paylaşabilirler, bu nedenle tüm kütüphanenin sanal adresleri vardır (bunu pmap'de görebilirsiniz). Hatta aynı yürütülebilir dosyayı paylaşabilirler, örneğin 2 bash örneği.

Şimdiye kadar bu, tüm sanal adresin alt bölümünün nasıl sığabileceğini açıklıyor, ancak daha fazlası var. Bir işlem o kadar çok sanal belleğe sahip olmayabilir ki, nasıl? Bir kitaplığın veya yürütülebilir dosyanın bazı bölümleri kullanılamayabilir, diskten ram'a kopyalanamazlar veya ram dolar ve diskten yüklendiği yerlerde bırakılır, çünkü gerekirse diskten yeniden getirilebilirler, veya diski yedeklemeyen bellek takas için eşlenir, takas için kopyalanır ve sonra bırakılır. Daha sonra gerektiğinde ve gerektiğinde takastan okunabilir. Bu son stratejilerden herhangi biri çok fazla kullanılırsa, sistem yavaşlar.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.