织梦网站突然打开很慢,网站设计流程的步骤包括,自己做的网站如何加视频教程,沈阳网站维护公司目录 内存统计工具
/proc/meminfo
Buddy
Slub
Procrank
/proc/pid/smaps
Dumpsys meminfo 内存评估 内存泄漏
Lmk 水位调整 内存统计工具
/proc/meminfo 可以提供整体内存信息#xff0c;各字段表示的意思如…目录 内存统计工具
/proc/meminfo
Buddy
Slub
Procrank
/proc/pid/smaps
Dumpsys meminfo 内存评估 内存泄漏
Lmk 水位调整 内存统计工具
/proc/meminfo 可以提供整体内存信息各字段表示的意思如下 字段 表示意思 MemTotal 系统可以使用的总内存 MemFree buddy 里面所有 free 的 page 的数(不包括冷热页目前也没有看见哪里统计 有冷热页) Buffers 块设备的缓存页(不属于某个具体文件的管理信息的缓存页) Cached 属于具体某个文件的缓存页 SwapCached swap cache 中的缓存页其不包含在下面的 lru 中 Active 系统中正在使用中的且使用的较积极的页 Inactive lru 系统中正在使用中的但是不太积极的页 Active(anon) Active 的匿名页 Inactive(anon) Inactive 的匿名页 Active(file) Active 的文件缓存页 Inactive(file) Inactive 的文件缓存页 Unevictable 隔离的暂时不参与 active/Inactive 判断的匿名页和文件缓存页之和 SwapTotal swap 分区总大小(对于 zram是 zram 块设备的大小而不是 zram 实际占用的大小) SwapFree swap 分区 free 空间(对于 zram是 zram 块设备剩余空间) Dirty 文件缓存中的脏页如果这个地方很大就要小心 IO 的配置或者 IO 有问题比如之前有 Bug 将 dirty_ration 设置为 30%就会出现这种情况 Writeback 文件缓存中正在写回的页 AnonPages APP 所使用的匿名映射的 pages(没有被 swap 出去的部分)。基本就是 Active(anon) Inactive(anon) Mapped mapped 文件的部分其应该是 cached 的一个子集 Slab slab 占有的所有page. 如果user_debug 版本打开了slub 将显著的增大该项 SReclaimable 其中设置为 Reclaimable 的 slab 占用的部分 SUnreclaim 设置为 Unreclaim 的 slab 占用的部分 KernelStack 每个线程(无论用户线程还是内核线程)都有一个 8Karm32的内核空间 线程栈 PageTables 用户进程的二级页表 pte 项(不包括内核进程的)所以可以认为完全是用户 态占用 VmallocTotal 内核 vmalloc 可以用的全部空间 VmallocUsed 已经使用了的空间(但不一定是 vmalloc 分配了物理内存的) VmallocChunk vmalloc 区域剩余的最大连续空间
Buddy
分别是各个Order 的块的个数。Buddy 之和就是proc/meminfo 中free 的大小。 Slub rootXXXX:/ # cat /proc/slabinfo slabinfo - version: 2.1
# name active_objs num_objs objsize objperslab pagesperslab : tunables
limit batchcount sharedfactor : slabdata active_slabs num_slabs sharedavail ext4_groupinfo_4k 61 156 104 39 1 : tunables 0 0 0 : slabdata
4 4 0 UDPLITEv6 0 0 768 21 4 : tunables 0 0 0 : slabdata 0 0 0 UDPv6 1 42 768 21 4 : tunables 0 0 0 : slabdata 2 2 0 ... kmalloc-4096 184 196 4096 4 4 : tunables 0 0 0 : slabdata 49 49 0 kmalloc-2048 95 136 2048 8 4 : tunables 0 0 0 : slabdata 17 17 0 kmalloc-1024 377 400 1024 16 4 : tunables 0 0 0 : slabdata 25 25 0 kmalloc-512 918 1072 512 16 2 : tunables 0 0 0 : slabdata 67 67 0 kmalloc-256 635 704 256 16 1 : tunables 0 0 0 : slabdata 44 44 0 kmalloc-192 4726 4893 192 21 1 : tunables 0 0 0 : slabdata 233 233 0 kmalloc-128 5501 6048 128 32 1 : tunables 0 0 0 : slabdata 189 189 0 kmalloc-64 47242 48640 64 64 1 : tunables 0 0 0 : slabdata
760 760 0
kmem_cache_node 76 256 64 64 1 : tunables 0 0 0 : slabdata 4 4 0
kmem_cache 76 160 128 32 1 : tunables 0 0 0 : slabdata 5 5 0
各项信息为
active_objsThe number of objects (memory blocks) that are in use (allocated)
num_objs总共现在有多少 memory blocks ObjsizeThe size of the objects.
Objperslab每个 slab 有多少个 memory blocks Pagesperslab每个 slab 占用多少个page(4096)。
Procrank 字段 表示意思 VSS(virtual set size) 单个进程全部可访问的用户虚拟地址空间 RSS(Resident set size) 单个进程实际占用的内存大小(所有共享库的全部内存大小) PSS(proportional set size) 不同于 RSS它只是按比例包含其所使用的共享库大小。 USS(Unique set size) 是单个进程的全部私有内存大小。 Swap 某个进程被交换出去的匿名页的大小就是 Swap(包括在 swap cache 中的和 真正交换到 swap 分区的都算)。 Pswap 模仿 PSS 的概念因为每个匿名页可能会被多个进程使用。因此 Swap 中 的 page 按照目前还有多少进程使用它按照比例分配得到 pswap。 Uswap 模仿 Uss 的概念私有的且被 swap 出去的内存的大小。 127|rootXXXX:/ # procrank PID Vss Rss Pss Uss Swap PSwap cmdline 1237 1128200K 108136K 55922K 52196K 1388K 1388K system_server 1390 732552K 105912K 52002K 46884K 52K 52K com.android.systemui 1977 1028756K 81440K 31869K 28868K 0K 0K com.android.launcher3 3474 1058820K 75688K 22556K 17464K 0K 0K com.sds.android.ttpod:channel 3343 1301320K 67968K 20864K 16336K 0K 0K com.tencent.mm ... 186 9172K 1448K 208K 160K 692K 692K /system/bin/vold 224 4748K 928K 172K 160K 256K 256K /system/bin/download 325 3092K 1100K 165K 20K 0K 0K /system/xbin/srtd 362 3092K 460K 152K 20K 0K 0K /system/xbin/srtd 207 3104K 928K 80K 64K 232K 232K /system/bin/lmkd 252 3036K 804K 68K 12K 312K 312K /system/bin/sh 213 7824K 844K 65K 52K 256K 256K /system/bin/modemd 218 988K 96K 64K 64K 56K 56K /bin/batterysrv 194 5284K 1192K 54K 24K 464K 464K /system/bin/gatekeeperd 225 5108K 792K 40K 28K 228K 228K /system/bin/gnss_download 212 4708K 792K 17K 4K 284K 284K /system/bin/modem_control 219 4860K 748K 16K 4K 284K 284K /system/bin/modemDriver_vpad_main 195 2800K 804K 15K 0K 308K 308K /system/xbin/perfprofd 627540K 492360K 10772K 10619K TOTAL RAM: 939244K total, 19076K free, 8768K buffers, 365548K cached, 4024K shmem, 34248K slab /proc/pid/smaps 这个是对进程地址空间以及内存使用最全面的展示。各项说明参考 6f387000-6ff18000 rw-p 00000000 b3:15 7575 /data/dalvik-cache/arm/systemframeworkboot.art Size: 11844 kB 该段虚拟空间大小 Rss: 11828 kB Shared_Clean Shared_Dirty Private_Clean Private_Dirty Filecache Anonymous Pss: 2179 kB Pss_Filecache Pss_Anonymous Uss: 1304 kB Private_FilecachePrivate_Anonymou Shared_Clean: 7964 kB 和其它进程共享而且是干净的 Shared_Dirty: 2560 kB 和其它进程共享而且是脏的 Private_Clean: 616 kB 本进程私有而且是干净的 Private_Dirty: Referenced: Filecache: 688 kB 11544 kB 8580 kB 本进程私有而且是脏的 文件缓存 Shared_Filecache Private_Filecache Pss_Filecache: 1344 kB 按比例共享的文件缓存 Shared_Filecache: 7964 kB 多进程共享的文件缓存 Private_Filecache: 616 kB 私有的文件缓存 Anonymous: 3248 kB 匿名内存 Shared_Anonymous Private_Anonymous Pss_Anonymous: 835 kB 按比例共享的匿名内存 Shared_Anonymous: 2560 kB 多进程共享的匿名内存 Private_Anonymous: AnonHugePages: Swap: 688 kB 0 kB 0 kB 私有的匿名内存 进程被交换出去的匿名页 PSwap: 0 kB 按比例共享的被交换出去的匿名页 USwap: KernelPageSize: MMUPageSize: Locked: 0 kB 4 kB 4 kB 0 kB 私有的被交换出去的匿名页 VmFlags: rd wr mr mw me ac mg Dumpsys meminfo Dumpsys meminfo 是 android 提供的比较有用的内存信息统计工具并且结合了进程的 adj可以查看各组进程所占的内存情况。 各个数据的统计来自/proc/pid/smaps对应关系请参考 dumpsys meminfo smaps line 特殊计算 Native Heap [heap] [anon:libc_malloc]XXX Dalvik Heap .Heap.LOS.NonMoving .Zygote Dalvik Other .LinearAlloc.Indirec tRef.JITCache.GC Stack [stackXXX Ashmem /dev/ashmemXXX (-/dev/ashmem/dalvik-XXX -/dev/ashmem/CursonrWindowXXX -/dev/ashmem/libc mallocXXX) Gfx dev /dev/kgsl-3d0XXX Other dev /dev/ (-/dev/kgsl-3d0 -/dev/ashmem) .so mmap XXX.so 共享库的 bss 段 .jar mmap XXX.jar .apk mmap XXX.apk .ttf mmap XXX.ttf .dex mmap XXX.dex XXX.odex .oat mmap XXX.oat .art mmap XXX.art Other mmap namelen0,已经统计的情况除外 EGL mtrack GL mtrack Other mtrack Unknow [anonXXXnew mapping Dalvik Details .Heap /dev/ashmem/dalvik-alloc space /dev/ashmem/dalvik-main space .Los /dev/ashmem/dalvik-large object space .LinearAlloc /dev/ashmem/dalvik-LinearAlloc .GC /dev/ashmem/dalvik-XXX (-heap_dalvik- .LinearAlloc,.IndirectRef,.JitCache) .JITCache /dev/ashmem/dalvik-jit-code-cache .Zygote /dev/ashmem/dalvik-zygote space .NonMoving /dev/ashmem/dalvik-non moving space .IndirectRef /dev/ashmem/dalvik-indirect ref App Summary(主要是用来体现进程独占的那些内存 Java Heap: Private Dirty(Dalvik Heap) Private Clean(.art) Private Dirty(.art) 该进程独有 Java Heap 这个有点问题的, .art比较复杂也会包含文件缓存的而从经验上看Private Clean(.art) 全部是Private_Filecache; 而Private Dirty(.art) 全部 是 Private_Anonymous Native Heap: Private Dirty(Native Heap) 该进程独有的 Native Heap Code: Private(.so) Private(.jar)Private(.apk)Private(. ttf)Private(.dex)Private(.oat) 该进程独有的代码占用的内存 .so 其实并不完全是 Code其也包 含.data, .rodat .bss。这个参考意义有限因为mmap 部分动态变化且不好统计的 Stack: Private Dirty(Stack) 该进程独有的栈内存 Graphics: Private(Gfx_dex) Private(EGL mtrack) Private(GL mtrack) Private Other: Private(Native Heap) Private(Dalvik Heap) Private(Unknow) -Java Heap-Native Heap - Code -Stack - Graphics 剩余的独有的部分 即TOTAL(private) - Java Heap - Native Heap - Code - Stack - Graphics应该就是Dalvik OtherAshmemUnkno w System: Pss(Dalvik Heap) Pss(Native Heap) Pss(Unknow)-Private(Dalvik Heap)-Private(Native Heap)-Private(Unknow) 和其它进程共享的就算做系统的部分。 即TOTAL(Pss) -TOTAL(Private)。 就是指和其他进程有共享的就算系统占用的PSS 部分 dumpsys meminfo smaps 备注 Pss Total Pss: Pss Clean sharing_proportion(pss-priv ate_clean-private_dirty)/(shar ed_cleanshared_dirty) sharing_proportion*shared_c lean private_clean 前提条件 XXX.so||XXX.jar||XXX. apk|XXX.ttf|XXX.dex|XX X.odex|XXX.oat|XXX.artpss0 (shared_clean0|shared_di rty0) 这个就只统计这几 部分其它的不管。所以 heap 的都为 0 Shared Dirty Shared_Dirty: 共享的脏的 Private Dirty Private_Dirty: 独占的脏的 Shared Clean Shared_Clean: 共享的干净的 Private Clean Private_Clean 独占的干净的 Swapped Dirty Swap: 被交换出去的 Private Swapped Uswap 独有的被交换出去的 Pss Swapped Pswap 按比例被交换出去的 Heap Size(Native Heap) mallinfo-usmblks 程序申请内存的最 高值 Heap Alloc(Native Heap) mallinfo-uordblks 当前正在使用的内 存大小 Heap Free(Native Heap) mallinfo-fordblks 当前空闲的内存大 小 Heap Size(Dalvik Heap) Runtime.totalMemory() Xms 参数指定 Heap Alloc(Dalvik Heap) Heap Size - Heap Free Heap Free(Dalvik Heap) Runtime.freeMemory() 内存评估
有时需要评估二个版本或者同一个版本二种场景下的系统内存情况。比如某公司项目发现插 sim 比不插 sim性能差想看看这二种情况下的内存情况。
首先可以收集信息看看同样在开机分钟的场景下FreeRAM 的差异。下面的数据可以从/proc/meminfo 和 dumpsys meminfo 中获得。 其次看下这多出的内存都用在哪里了。 从上面可以看出二种场景主要是 frameworkapp 的内存差异那进一步看下用户空间的内存使用情况。下面数据可以由dumpsys meminfo 与 procrank得出。 由上面的数据分析可以得出结论
插 sim 卡时FreeRAM 少 40。是因为上层 app 会多从收集的数据看会多占 60内存。因此会 drop 更多的file cache, swap 更多匿名页。而 Free RAM是强依赖 file cachefile cache 少FreeRAM 也会少。 内存泄漏
当系统稳定性不好或者 lmk 杀到 adj 很低时一般会看下此时内存使用情况同内存评估的表格排查内存泄漏问题。这样整体上看只能定位出哪个模块或者进程存在 memory leak具体的 leak 点还需要各个 FO 排查。内核很少出现这类问题一旦怀疑是内核出现 leak,就会采取很脏的方式标记每个分配路径与回收路径最终统计定位出问题的点一般是 patch 形式 debug。
但是用户层的 memory leak 却很常见一般泄漏的是 malloc 或者 new 后没有对应的 free 掉导致Active(anon) Inactive(anon) ZRAM 很大。
例
从下面 LMK 杀进程时的 mem 情况看到 Free memory 较小而 swapfree为 0swap 分区耗尽。
[82916.745910] c3 sprd thm: D thm sensor id:0, cal_offset:-2, rawdata:0x3b4
[82916.765411] c1 lowmemorykiller: Killing d.process.acore (27571), adj 5,
[82916.765411] c1 to free 11576kB on behalf of sdcard (1590) because
[82916.765411] c1 cache 17680kB is below limit 18432kB for oom_score_adj 3
[82916.765411] c1 Free memory is 4124kB above reserved
[82916.765411] c1 swaptotal is 409596kB, swapfree is 0kB
进程的 RSS 信息和 swap 信息如下而此时 mediaserver 占用空间特别大用户空间 RSS 为 50M, 而swap 空间为 379M。基本可以确认是 mediaserver 内存泄漏。
lowmemorykiller: [ pid ] uid tgid total_vm rss swap cpu oom_score_adj name lowmemorykiller: [ 130] 0 130 175 48 62 3 -1000 ueventd lowmemorykiller: [ 155] 1023 155 1028 51 45 0 -1000 sdcard lowmemorykiller: [ 156] 1036 156 1497 51 112 2 -1000 logd lowmemorykiller: [ 157] 0 157 395 44 2 3 -1000 healthd lowmemorykiller: [ 158] 0 158 592 58 50 0 -1000 lmkd lowmemorykiller: [ 159] 1000 159 309 58 30 0 -1000 servicemanager lowmemorykiller: [ 160] 0 160 1447 33 144 1 -1000 vold lowmemorykiller: [ 161] 0 161 545 48 175 0 -1000 debuggerd lowmemorykiller: [ 162] 1000 162 10559 207 173 3 -1000 surfaceflinger lowmemorykiller: [ 163] 0 163 782 10 43 0 -1000 modem_control lowmemorykiller: [ 164] 1000 164 1559 3 57 3 -1000 modemd lowmemorykiller: [ 165] 1000 165 1515 43 70 0 -1000 wcnd lowmemorykiller: [ 166] 1000 166 88 0 12 3 -1000 batterysrv lowmemorykiller: [ 173] 2000 173 278 21 41 1 -1000 sh lowmemorykiller: [ 174] 0 174 1444 41 66 1 -1000 collect_apr lowmemorykiller: [ 176] 0 176 2681 20 85 3 -1000 netd lowmemorykiller: [ 177] 1019 177 4535 92 278 1 -1000 drmserver lowmemorykiller: [ 178] 1013 178 146988 7926 92832 1 -1000 mediaserver
Lmk 水位调整 在低内存手机中常常会涉及 lmk 水位的调整因为 android 原生水位相对高常会出现闪退问题或者 CTS 测试进程被 kill。Lmk 水位调整是一种权衡不会解决所有问题只能根据项目的性能稳定性目标做出均衡。 根据项目经验以下是Tuning 的大体策略 基本原则是以 Android 计算的原生值为基准不建议偏差太多。但是我们实际发现原生计算值比较大多后台性能不怎么好而且运行大应用会出现闪退。各 minfree 值档位差最好依据原生的比例尽量进行模仿。我们只是定最高水位 adj 15 对应的内存值。当系统 ANR 较多时(注并不是说 ANR 就一定和 LMK 参数相关但是调节 LMK 参数可以缓解系统的 ANR 情况)加大 oom_adj 9(HIDDEN_APP_MIN_ADJ)对应的 minfree 值但该方法会降低多后台的性能(减少后台 APP 个数)通过系统更为积极的 kill 进程来释放 mem以降低内存回收所使用的 CPU以及占用的 IO 带宽加快进程获取 mem 的速度。如果想提高多后台 同时应注意与 HIDDEN_APP_MIN_ADJ9以下的 adj 对应的 minfree调低 oom_adj 9(HIDDEN_APP_MIN_ADJ)对应 minfree 的值的值保持一定距离该方法和上述需求 1 是矛盾的。多后台和减少 ANR 往往会不可兼得请根据实际需求综合考虑。如果要避免前台进程发生闪退 如果该值太低系统内存极低时可能无法恢复过来导致定屏黑屏等等。调低 FOREGROUND_APP_ADJ 0 对应的 minfree 值 如果觉得两个水位之间间隔太大没有积极的杀进程(主要是导致性能问 题)可以重新设定Oom_adj 数组比如设定为0,1,3,9,11,15(原生值为 01 23915)。调节起点如果 swapfree 相当小时(小于 5%)但 ANON 页和 Filecache 都很大而且由于 Filecache 很多没有杀进程。则至少需要将最高杀 APP 水位调整到此时 Filecache 最大值。通过积极的杀进城来释放 swap 的空间并减轻内存回收的压力。
下面是实际 tuning 的操作方法
如果存在页颠簸的话我们还是希望通过 lmk kill 进程来快速回收内存。而 lmk 参考的阀值是 file-cache那我们可以大概估算出低于 adj 9 所有进程所需的总体 active file-cache这值可以做为 adj9 的lmk 阀值。有了这个值再根据原生水位的比例就可以得出一组 lmk 水位。
一般将上面得到的水位做为系统最不积极的水位水位再低点就会出现页颠簸了然后在这组水位与原生水位之间再设计出几套水位再加一组比原生水位高点的水位。分别对设计出来的几套水位进行性能与稳定性测试选定表现最均衡的一组。
操作方法
手机开机分钟
kill 所有后台进程am kill-all;
2 ) 回收内存echo 1 /proc/sys/vm/drop_caches;
32 操作后马上收集内存信息/proc/meminfo, dumpsys meminfo -a;
active file-cache 可以做为 adj 529 的内存阀值 baseminfree 数组的第 5 个值注意除 4再根据原生水位的比例设计一组 lmk 水位
最后依据 dumpsys meminfo,查看各组进程组的内存占用情况进行 minfree微调
