記憶體用量

這個檔案包含 Zircon 中的記憶體管理和診斷資訊， 也會討論檢查程序和系統記憶體用量的方法。

處理序可使用下列 3 種記憶體：

1. 對應記憶體的形式，格式為堆積、執行緒堆疊、可執行的程式碼 + 資料。 此記憶體以 VMAR 表示 而保留對 VMO 的參照 程式設計師通常會透過記憶體位址與這個記憶體通訊。
2. 獨立 VMO。這些是多組記憶體頁面，並未透過 擔任警察，程式設計人員透過控點與這個記憶體通訊通常是核發的 vmo_read 和 vmo_write。
3. 核心記憶體，以控制核心物件的形式呈現。

Fuchsia 採用「超額配置」模型：程序可以分配較多的記憶體 能夠滿足特定時刻的需求 而且記憶體頁面 而是透過核心即時分配實體管道

使用者空間記憶體

哪些程序耗用了全部記憶體？

傾印程序記憶體總用量

使用 ps 工具：

$ ps
TASK           PSS PRIVATE  SHARED NAME
j:1028       32.9M   32.8M         root
  p:1043   1386.3k   1384k     28k bin/devmgr
  j:1082     30.0M   30.0M         zircon-drivers
    p:1209  774.3k    772k     28k /boot/bin/acpisvc
    p:1565  250.3k    248k     28k driver_host
    p:1619  654.3k    652k     28k driver_host
    p:1688  258.3k    256k     28k driver_host
    p:1867 3878.3k   3876k     28k driver_host
    p:1916   24.4M   24.4M     28k driver_host
  j:1103   1475.7k   1464k         zircon-services
    p:1104  298.3k    296k     28k crashlogger
    p:1290  242.3k    240k     28k netsvc
    p:2115  362.3k    360k     28k sh:console
    p:2334  266.3k    264k     28k sh:vc
    p:2441  306.3k    304k     28k /boot/bin/ps
TASK           PSS PRIVATE  SHARED NAME

PSS (比例共用狀態) 是位元組數量，用於評估 與程序耗用的實體記憶體對應。其值為 PRIVATE + (SHARED / sharing-ratio)，其中 sharing-ratio 是以 在這個過程中，系統會共用每一個頁面。

這麼做的用意是，假設有四個程序共用單一網頁， 該網頁的位元組都會納入這四個程序的 PSS 中。如果兩個 每個程序都會共用不同網頁，則每個程序都會獲得網頁位元組的 1/2。

PRIVATE 是僅透過這個程序對應的位元組數。例如 沒有其他程序對應這個記憶體請注意，這不適用於私人影片 未對應的 VMO。

SHARED 是這個程序對應的位元組數，至少 程序。請注意，這麼做並未計入 對應。此物件也不會指出共用記憶體的程序數： 可以是 2，可以是 50。

以圖表呈現記憶體用量

如果您建立的是 Fuchsia 版本，可以使用樹狀圖， 以及系統

1. 在主體機器的根目錄中執行下列指令 Fuchsia 結帳：

   ./scripts/fx shell memgraph -vt | ./scripts/memory/treemap.py > mem.html

2. 在瀏覽器中開啟 mem.html。

memgraph 工具會產生系統工作和記憶體的 JSON 說明 然後由 treemap.py 指令碼剖析。-vt說 ，在輸出內容中加入 VMO 和執行緒。

傾印程序的詳細記憶體對應圖

如要查看特定程序使用過多記憶體的原因，您可以執行 vmaps 工具使用 koid (Kid 是執行 ps 時顯示的 ID) 即可看到 對應至記憶體的內容

$ vmaps help
Usage: vmaps <process-koid>

Dumps a process's memory maps to stdout.

First column:
  "/A" -- Process address space
  "/R" -- Root VMAR
  "R"  -- VMAR (R for Region)
  "M"  -- Mapping

  Indentation indicates parent/child relationship.

資料欄標記：

• :sz：項目的虛擬大小，以位元組為單位。部分網頁 均由實體記憶體支援
• :res：「常駐」記憶體的數量項目中，以位元組為單位；亦即 傳回該項目的實體記憶體容量這項回憶集錦可能屬於私人內容 (只能透過這項程序存取) 或由多個程序共用。
• :vmo：對應至這個區域的 VMO 的 koid。

$ vmaps 2470
/A ________01000000-00007ffffffff000    128.0T:sz                    'proc:2470'
/R ________01000000-00007ffffffff000    128.0T:sz                    'root'
...
# This 'R' region is a dynamic library. The r-x section is .text, the r--
# section is .rodata, and the rw- section is .data + .bss.
R  00000187bc867000-00000187bc881000      104k:sz                    'useralloc'
 M 00000187bc867000-00000187bc87d000 r-x   88k:sz   0B:res  2535:vmo 'libfdio.so'
 M 00000187bc87e000-00000187bc87f000 r--    4k:sz   4k:res  2537:vmo 'libfdio.so'
 M 00000187bc87f000-00000187bc881000 rw-    8k:sz   8k:res  2537:vmo 'libfdio.so'
...
# This 2MB anonymous mapping is probably part of the heap.
M  0000246812b91000-0000246812d91000 rw-    2M:sz  76k:res  2542:vmo 'mmap-anonymous'
...
# This region looks like a stack: a big chunk of virtual space (:sz) with a
# slightly-smaller mapping inside (accounting for a 4k guard page), and only a
# small amount actually committed (:res).
R  0000358923d92000-0000358923dd3000      260k:sz                    'useralloc'
 M 0000358923d93000-0000358923dd3000 rw-  256k:sz  16k:res  2538:vmo ''
...
# The stack for the initial thread, which is allocated differently.
M  0000400cbba84000-0000400cbbac4000 rw-  256k:sz   4k:res  2513:vmo 'initial-stack'
...
# The vDSO, which only has .text and .rodata.
R  000047e1ab874000-000047e1ab87b000       28k:sz                    'useralloc'
 M 000047e1ab874000-000047e1ab87a000 r--   24k:sz  24k:res  1031:vmo 'vdso/stable'
 M 000047e1ab87a000-000047e1ab87b000 r-x    4k:sz   4k:res  1031:vmo 'vdso/stable'
...
# The main binary for this process.
R  000059f5c7068000-000059f5c708d000      148k:sz                    'useralloc'
 M 000059f5c7068000-000059f5c7088000 r-x  128k:sz   0B:res  2476:vmo '/boot/bin/sh'
 M 000059f5c7089000-000059f5c708b000 r--    8k:sz   8k:res  2517:vmo '/boot/bin/sh'
 M 000059f5c708b000-000059f5c708d000 rw-    8k:sz   8k:res  2517:vmo '/boot/bin/sh'
...

您也可以使用 aspace 指令顯示記憶體對應： zxdb。

傾印與程序相關聯的所有 VMO

vmos <pid>

這也會顯示未對應的 VMO，ps和vmaps目前都沒有 帳號

也會顯示特定 VMO 是否為子項，以及其父項的 koid。

$ vmos 1118
rights  koid parent #chld #map #shr    size   alloc name
rwxmdt  1170      -     0    1    1      4k      4k stack: msg of 0x5a
r-xmdt  1031      -     2   28   14     28k     28k vdso/stable
     -  1298      -     0    1    1      2M     68k jemalloc-heap
     -  1381      -     0    3    1    516k      8k self-dump-thread:0x12afe79c8b38
     -  1233   1232     1    1    1   33.6k      4k libbacktrace.so
     -  1237   1233     0    1    1      4k      4k data:libbacktrace.so
...
     -  1153   1146     1    1    1  883.2k     12k ld.so.1
     -  1158   1153     0    1    1     16k     12k data:ld.so.1
     -  1159      -     0    1    1     12k     12k bss:ld.so.1
rights  koid parent #chld #map #shr    size   alloc name

欄數：

• rights：如果程序透過帳號代碼指向 VMO，此欄顯示 帳號代碼擁有的權利 (零或多個)：
  • r：ZX_RIGHT_READ
  • w：ZX_RIGHT_WRITE
  • x：ZX_RIGHT_EXECUTE
  • m：ZX_RIGHT_MAP
  • d：ZX_RIGHT_DUPLICATE
  • t：ZX_RIGHT_TRANSFER
  • 注意：非帳號代碼項目會有單個「-」。
• koid：VMO 的 Kid (如果有的話)。否則為零。沒有特別說明的 VMO koid 是由核心建立，從未有使用者空間控制代碼。
• parent：VMO 父項的 koid (如果是子項)。
• #chld：VMO 的有效子項數量。
• #map：VMO 目前對應至 VMAR 的次數。
• #shr：對應 (共用) VMO 的程序數量。
• size：VMO 的目前大小，以位元組為單位。
• alloc：分配給 VMO 的實體記憶體量，以位元組為單位。
  • 注意：如果這個資料欄含有 phys 值，表示 VMO 會指向原始實體位址範圍，例如記憶體對映裝置。 phys VMO 不會耗用 RAM。
• name：VMO 的名稱；如果名稱空白，則為 -。

為了和 ps 建立關聯：每個 VMO 都會根據對應的部分提供貢獻 (因為系統可能不會對應 VMO 的所有頁面)：

PRIVATE =  #shr == 1 ? alloc : 0
SHARED  =  #shr  > 1 ? alloc : 0
PSS     =  PRIVATE + (SHARED / #shr)

您也可以使用在以下位置使用 handle 指令顯示 VMO 資訊： zxdb。

傾印「已隱藏」(未對應和核心) VMO

k zx vmos hidden

與 vmos <pid> 類似，但會轉儲系統中所有未對應的 VMO 融入任何程序：

• 使用者空間可處理但未對應的 VMO
• 僅對應至核心空間的 VMO
• 僅限核心且未對應的 VMO，但沒有帳號代碼

koid 的值為 0 表示只有核心具有該 VMO 的參照。

如果 #map 值為 0，表示 VMO 未對應到任何位址空間。

另請參閱：k zx vmos all，這會傾印系統中的所有 VMO。注意： 這個輸出內容因核心控制台而遭到截斷是很常見的情況 緩衝區限制，因此最好結合 k zx vmos hidden 每個使用者程序都會有 vmaps 傾印的輸出內容。

限制

「ps」和「vmaps」目前沒有符合以下條件的廣告主：

• 未對應的 VMO 或 VMO 子範圍。舉例來說，您可以建立 VMO 並寫入 1G 資料，不會顯示在這裡。

所有程序傾印工具都未考量以下因素：

• 倍增對應的頁面。如果您使用相同的範圍建立多個對應關係 則 VMO 的任何修訂頁面都會以 這些頁面就會彼此對應這可以位於同一個程序內，也可能是 即可。

  請注意，「倍增對應的頁面」包括寫入時複製的內容

• 程序分配資源的基本核心記憶體負擔。 舉例來說，一個程序可以有百萬個帳號代碼，而這些帳號代碼會耗用大量資源 核心記憶體大小

  您可以使用 k zx ps 指令，查看程序控制使用量；執行 k zx ps help 用於表示資料欄的說明。

• 複製時複製 (COW) 的 VMO。未複製且未複製的 本機副本不會計入「共用」處理本機副本的程序 但這些相同的網頁可能會誤算為「私人」程序 用來對應至父項 (複製) VMO 的容器。

  TODO(dbort)：修正這個問題；這些工具是在 COW 複製推出之前就寫成。

核心記憶體

傾印系統記憶體競技場和核心堆積使用情況

執行 kstats -m 將持續轉儲實體記憶體的相關資訊 可用性和可用性

$ kstats -m
--- 2017-06-07T05:51:08.021Z ---
mem total      free      VMOs     kheap     kfree     wired       mmu       ipc     other
    2048M   1686.4M    317.8M      5.1M      0.9M     17.8M     20.0M      0.1M      0.0M

--- 2017-06-07T05:51:09.021Z ---
...

欄位：

• -t 選項會顯示時間戳記 2017-06-07T05:51:08.021Z，也就是統計資料的時間 的收集格式為 ISO 8601 字串。
• total：系統可用的實體記憶體總量。
• free：未配置的記憶體量。
• VMOs：承諾為 VMO (包含核心和使用者) 的記憶體量。A 罩杯 超級系列不包含某些受影響的 VMO 低於 wired。
• kheap：標示為已分配的核心堆積記憶體數量。
• kfree：標示為免費的核心堆積記憶體量。
• wired：為 本結構中其他欄位未涵蓋的原因。通常為唯讀 例如 ram 磁碟和核心映像檔，以及適用於早期啟動動態記憶體的資料。
• mmu：用於架構專屬 MMU 中繼資料的記憶體量，例如 分頁表。
• ipc：用於處理序間通訊的記憶體量。
• other：其他所有為 other 的內容。

傾印核心位址空間

k zx asd kernel

傾印核心的 VMAR/mapping/VMO 階層，與 vmaps 工具類似 處理整個事件

$ k zx asd kernel
as 0xffffffff80252b20 [0xffffff8000000000 0xffffffffffffffff] sz 0x8000000000 fl 0x1 ref 71 'kernel'
  vmar 0xffffffff802529a0 [0xffffff8000000000 0xffffffffffffffff] sz 0x8000000000 ref 1 'root'
    map 0xffffff80015f89a0 [0xffffff8000000000 0xffffff8fffffffff] sz 0x1000000000 mmufl 0x18 vmo 0xffffff80015f8890/k0 off 0 p ages 0 ref 1 ''
      vmo 0xffffff80015f8890/k0 size 0 pages 0 ref 1 parent k0
    map 0xffffff80015f8b30 [0xffffff9000000000 0xffffff9000000fff] sz 0x1000 mmufl 0x18 vmo 0xffffff80015f8a40/k0 off 0 pages 0 ref 1 ''
      object 0xffffff80015f8a40 base 0x7ffe2000 size 0x1000 ref 1
    map 0xffffff80015f8cc0 [0xffffff9000001000 0xffffff9000001fff] sz 0x1000 mmufl 0x1a vmo 0xffffff80015f8bd0/k0 off 0 pages 0 ref 1 ''
      object 0xffffff80015f8bd0 base 0xfed00000 size 0x1000 ref 1
...