《嵌入式Linux內存使用與性能優化》筆記
這本書有兩個關切點：系統內存(用戶層)和性能優化。node
這本書和Brendan Gregg的《Systems Performance》相比，不管是技術層次仍是更高的理論都有較大差距。可是這不影響，快速花點時間簡單過一遍。linux
而後在對《Systems Performance》進行詳細的學習。程序員
因爲Ubuntu測試驗證更合適，因此在Ubuntu(16.04)+Kernel(4.10.0)環境下作了下面的實驗。算法
全書共9章：1~4章着重於內存的使用，儘可能下降進程的內存使用量，定位和發現內存泄露；5~9章着重於如何讓系統性能優化，提升執行速度。shell
第1章 內存的測量api
第3章 系統內存優化性能優化
第4章 內存泄露bash
用戶空間的內存使用量是由進程使用量累積和系統使用之和，因此優化系統內存使用，就是逐個攻克每一個進程的使用量和優化系統內存使用。。
俗話說「知己知彼，百戰不殆」，要優化一個進程的使用量，首先得使用工具去評估內存使用量(第1章 內存的測量)；
而後就來看看進程那些部分耗費內存，並針對性進行優化(第2章 進程內存優化)；
最後從系統層面尋找方法進行優化(第3章 系統內存優化)。
內存的使用一個致命點就是內存泄露，如何發現內存泄露，而且將內存泄露定位是重點(第4章 內存泄露)
第1章 內存的測量
做者在開頭的一段話說明了本書採用的方法論：
關於系統內存使用，將按照(1)明確目標->(2)尋找評估方法，(3)瞭解當前情況->對系統內存進行優化->從新測量，評估改善情況的過程，來闡述系統的內存使用與優化。
(1)明確目標，針對系統內存優化，有兩個：
A.每一個守護進程使用的內存儘量少
B.長時間運行後，守護進程內存仍然保持較低使用量，沒有內存泄露。
(2)尋找評估方法，第1章關注點。
(3)對系統內存進行優化，第2章針對進程進行優化，第3章針對系統層面進行內存優化，第4章關注內存泄露。
系統內存測量
free用以得到當前系統內存使用狀況。
在一嵌入式設備獲取以下：
| busybox free |
和PC使用的free對比：
| total used free shared buffers cached |
可見這兩個命令存在差別，busybox沒有cached。這和實際不符，實際可用內存=free+buffers+cached。
buffers是用來給Linux系統中塊設備作緩衝區，cached用來緩衝打開的文件。下面是經過cat /proc/meminfo獲取，可知實際可用內存=8352+0+3508=11860。已經使用內存爲=23940-11860=12080。可見二者存在差別，busybox的free不太準確；/proc/meminfo的數據更準確。
| MemTotal: 23940 kB |
進程內存測量
在進程的proc中與內存有關的節點有statm、maps、memmap。
cat /proc/xxx/statm
| 1086 168 148 1 0 83 0 |
這些參數以頁(4K)爲單位，分別是：
1086 Size，任務虛擬地址空間的大小。
168 Resident，應用程序正在使用的物理內存的大小。
148 Shared，共享頁數。
1 Trs，程序所擁有的可執行虛擬內存的大小。
0 Lrs，被映像到任務的虛擬內存空間的的庫的大小。
83 Drs，程序數據段和用戶態的棧的大小。
0 dt，髒頁數量(已經修改的物理頁面)。
Size、Trs、Lrs、Drs對應虛擬內存，Resident、Shared、dt對應物理內存。
cat /proc/xxx/maps
| 00400000-00401000 r-xp 00000000 08:05 18561374 /home/lubaoquan/temp/hello |
第一列，表明該內存段的虛擬地址。
第二列，r-xp，表明該段內存的權限，r=讀，w=寫，x=執行，s=共享，p=私有。
第三列，表明在進程地址裏的偏移量。
第四列，映射文件的的主從設備號。
第五列，映像文件的節點號。
第六列，映像文件的路徑。
kswapd
Linux存在一個守護進程kswapd，他是Linux內存回收機制，會按期監察系統中空閒呢村的數量，一旦發現空閒內存數量小於一個閾值的時候，就會將若干頁面換出。
可是在嵌入式Linux系統中，卻沒有交換分區。沒有交換分區的緣由是：
1.一旦使用了交換分區，系統系能將降低的很快，不可接受。
2.Flash的寫次數是有限的，若是在Flash上面創建交換分區，必然致使對Flash的頻繁讀寫，影響Flash壽命。
那沒有交換分區，Linux是如何作內存回收的呢？
對於那些沒有被改寫的頁面，這塊內存不須要寫到交換分區上，能夠直接回收。
對於已經改寫了的頁面，只能保留在系統中，，沒有交換分區，不能寫到Flash上。
在Linux物理內存中，每一個頁面有一個dirty標誌，若是被改寫了，稱之爲dirty page。全部非dirty page均可以被回收。
第2章 進程內存優化
當存在不少守護進程，又要去下降守護進程內存佔用量，如何去推進：
1.全部守護進程內存只能比上一個版本變少。
2.Dirty Page排前10的守護進程，努力去優化，dirty page減小20%。
能夠從三個方面去優化：
1.執行文件所佔用的內存
2.動態庫對內存的影響
3.線程對內存的影響
2.1 執行文件
一個程序包括代碼段、數據段、堆段和棧段。一個進程運行時，所佔用的內存，能夠分爲以下幾部分：
棧區(stack)：由編譯器自動分配釋放，存放函數的參數、局部變量等
堆區(heap)：通常由程序員分配釋放，若程序員不釋放，程序結束時可有操做系統來回收
全局變量、靜態變量：初始化的全局變量和靜態變量在一塊區域，未初始化的全局變量和靜態變量在另外一塊區域，程序結束後由系統釋放
文字常量：常量、字符串就是放在這裏的，程序結束後有系統釋放
程序代碼：存放函數體的二進制代碼
下面結合一個實例分析：
| #include <stdlib.h> int n=10; int main() printf("pid:%d\n", pid); |
執行程序結果：
| pid:18768 |
查看cat /proc/17868/maps
| 00400000-00401000 r-xp 00000000 08:05 18561376 /home/lubaoquan/temp/example |
第3章 系統內存優化
3.1 守護進程的內存使用
守護進程因爲上期運行，對系統內存使用影響很大：
1.因爲一直存貨，因此其佔用的內存不會被釋放。
2.即便什麼都不作，因爲引用動態庫，也會佔用大量的物理內存。
3.因爲生存週期很長，哪怕一點內存泄露，累積下來也會很大，致使內存耗盡。
那麼如何下降風險呢？
1.設計守護進程時，區分常駐部分和很是駐部分。儘可能下降守護進程的邏輯，下降內存佔用，下降內存泄露概率。或者將幾個守護進程內容合爲一個。
2.有些進程只是須要儘早啓動，而不須要變成守護進程。能夠考慮加快啓動速度，從而使服務達到按需啓動的需求。優化方式有優化加載動態庫、使用Prelink方法、採用一些進程調度方法等。
3.2 tmpfs分區
Linux中爲了加快文件讀寫，基於內存創建了一個文件系統，成爲ramdisk或者tmpfs，文件訪問都是基於物理內存的。
使用df -k /tmp能夠查看分區所佔空間大小：
| Filesystem 1K-blocks Used Available Use% Mounted on |
在對這個分區進行讀寫時，要時刻注意，他是佔用物理內存的。不須要的文件要及時刪除。
3.3 Cache和Buffer
系統空閒內存=MemFree+Buffers+Cached。
Cache也稱緩存，是把從Flash中讀取的數據保存起來，若再次讀取就不須要去讀Flash了，直接從緩存中讀取，從而提升讀取文件速度。Cache緩存的數據會根據讀取頻率進行組織，並最頻繁讀取的內容放在最容易找到的位置，把再也不讀的內容不短日後排，直至從中刪除。
在程序執行過程當中，發現某些指令不在內存中，便會產生page fault，將代碼載入到物理內存。程序退出後，代碼段內存不會當即丟棄，二是做爲Cache緩存。
Buffer也稱緩存，是根據Flash讀寫設計的，把零散的寫操做集中進行，減小Flash寫的次數，從而提升系統性能。
Cache和BUffer區別簡單的說都是RAM中的數據，Buffer是即將寫入磁盤的，而Cache是從磁盤中讀取的。
使用free -m按M來顯示Cache和Buffer大小：
| total used free shared buffers cached |
下降Cache和Buffer的方法：
sync
該命令將未寫的系統緩衝區寫到磁盤中。包含已修改的 i-node、已延遲的塊 I/O 和讀寫映射文件。/proc/sys/vm/drop_caches
a）清理pagecache（頁面緩存）
# echo 1 > /proc/sys/vm/drop_caches 或者 # sysctl -w vm.drop_caches=1b）清理dentries（目錄緩存）和inodes
# echo 2 > /proc/sys/vm/drop_caches 或者 # sysctl -w vm.drop_caches=2c）清理pagecache、dentries和inodes
# echo 3 > /proc/sys/vm/drop_caches 或者 # sysctl -w vm.drop_caches=3上面三種方式都是臨時釋放緩存的方法，要想永久釋放緩存，須要在/etc/sysctl.conf文件中配置：vm.drop_caches=1/2/3，而後sysctl -p生效便可！
vfs_cache_pressurevfs_cache_pressure=100 這個是默認值，內核會嘗試從新聲明dentries和inodes，並採用一種相對於頁面緩存和交換緩存比較」合理」的比例。減小vfs_cache_pressure的值，會致使內核傾向於保留dentry和inode緩存。增長vfs_cache_pressure的值，（即超過100時），則會致使內核傾向於從新聲明dentries和inodes總之，vfs_cache_pressure的值：小於100的值不會致使緩存的大量減小超過100的值則會告訴內核你但願以高優先級來清理緩存。
3.4 內存回收
kswapd有兩個閾值：pages_high和pages_low，當空閒內存數量低於pages_low時，kswapd進程就會掃描內存而且每次釋放出32個free pages，知道free page數量達到pages_high。
kswapd回收內存的原則？
1.若是物理頁面不是dirty page，就將該物理頁面回收。
- 代碼段，只讀不能被改寫，所佔內存都不是dirty page。
- 數據段，可讀寫，所佔內存多是dirty page，也可能不是。
- 堆段，沒有對應的映射文件，內容都是經過修改程序改寫的，所佔物理內存都是dirty page。
- 棧段和堆段同樣，所佔物理內存都是dirty page。
- 共享內存，所佔物理內存都是dirty page。
就是說，這條規則主要面向進程的代碼段和未修改的數據段。
2.若是物理頁面已經修改而且能夠備份迴文件系統，就調用pdflush將內存中的內容和文件系統進行同步。pdflush寫回磁盤，主要針對Buffers。
3.若是物理頁面已經修改可是沒有任何磁盤的備份，就將其寫入swap分區。
kswapd再回首過程當中還存在兩個重要方法：LMR(Low on Memory Reclaiming)和OMK(Out of Memory Killer)。
因爲kswapd不能提供足夠空閒內存是，LMR將會起做用，每次釋放1024個垃圾頁知道內存分配成功。
當LMR不能快速釋放內存的時候，OMK就開始起做用，OMK會採用一個選擇算法來決定殺死某些進程。發送SIGKILL，就會當即釋放內存。
3.5 /proc/sys/vm優化
此文件夾下面有不少接口控制內存操做行爲，在進行系統級內存優化的時候須要仔細研究，適當調整。
block_dump
表示是否打開Block Debug模式，用於記錄全部的讀寫及Dirty Block寫回操做。0，表示禁用Block Debug模式；1，表示開啓Block Debug模式。dirty_background_ratio
表示髒數據達到系統總體內存的百分比，此時觸發pdflush進程把髒數據寫回磁盤。dirty_expires_centisecs
表示髒數據在內存中駐留時間超過該值，pdflush進程在下一次將把這些數據寫回磁盤。缺省值3000，單位是1/100s。dirty_ratio
表示若是進程產生的髒數據達到系統總體內存的百分比，此時進程自行吧髒數據寫回磁盤。dirty_writeback_centisecs
表示pdflush進程週期性間隔多久把髒數據協會磁盤，單位是1/100s。vfs_cache_pressure
表示內核回收用於directory和inode cache內存的傾向；缺省值100表示內核將根據pagecache和swapcache，把directory和inode cache報紙在一個合理的百分比；下降該值低於100，將致使內核傾向於保留directory和inode cache；高於100，將致使內核傾向於回收directory和inode cache。min_free_kbytes
表示強制Linux VM最低保留多少空閒內存(KB)。nr_pdflush_threads
表示當前正在進行的pdflush進程數量，在I/O負載高的狀況下，內核會自動增長更多的pdflush。overcommit_memory
指定了內核針對內存分配的策略，能夠是0、一、2.
0 表示內核將檢查是否有足夠的可用內存供應用進程使用。若是足夠，內存申請容許；反之，內存申請失敗。
1 表示內核容許分配全部物理內存，而無論當前內存狀態如何。
2 表示內核容許分配查過全部物理內存和交換空間總和的內存。overcommit_ratio
若是overcommit_memory=2，能夠過在內存的百分比。page-cluster
表示在寫一次到swap區時寫入的頁面數量，0表示1頁，3表示8頁。swapiness
表示系統進行交換行爲的成都，數值(0~100)越高，越可能發生磁盤交換。legacy_va_layout
表示是否使用最新的32位共享內存mmap()系統調用。nr_hugepages
表示系統保留的hugetlg頁數。
第4章 內存泄露
4.1 如何肯定是否有內存泄露
解決內存泄露一個好方法就是：不要讓你的進程成爲一個守護進程，完成工做後馬上退出，Linux會自動回收該進程所佔有的內存。
測試內存泄露的兩種方法：
1.模仿用戶長時間使用設備，查看內存使用狀況，對於那些內存大量增加的進程，能夠初步懷疑其有內存泄露。
2.針對某個具體測試用例，檢查是否有內存泄露。
在發現進程有漏洞以後，看看如何在代碼中檢查內存泄露。
4.2 mtrace
glibc針對內存泄露給出一個鉤子函數mtrace：
1.加入頭文件<mcheck.h>
2.在須要內存泄露檢查的代碼開始調用void mtrace()，在須要內存泄露檢查代碼結尾調用void muntrace()。若是不調用muntrace，程序天然結束後也會顯示內存泄露
3.用debug模式編譯檢查代碼(-g或-ggdb)
4.在運行程序前，先設置環境變量MALLOC_TRACE爲一個文件名，這一文件將存有內存分配信息
5.運行程序，內存分配的log將輸出到MALLOC_TRACE所執行的文件中。
代碼以下：
| #include <stdio.h> int main(void) char *p=malloc(10); |
編譯，設置環境變量，執行，查看log：
| gcc -o mem-leakage -g mem-leakage.c export MALLOC_TRACE=/home/lubaoquan/temp/malloc.og ./mem-leakage = Start |
加入mtrace會致使程序運行緩慢：
1.日誌須要寫到Flash上(能夠將MALLOC_TRACE顯示到stdout上。)
2.mtrace函數內，試圖根據調用malloc代碼指針，解析出對應的函數
性能優化是一個艱苦、持續、枯燥、反覆的過程，涉及到的內容很是多，編譯器優化、硬件體系結構、軟件的各類技巧等等。
另外在嵌入式電池供電系統上，性能的優化也要考慮到功耗的使能。PnP的兩個P(Power and Performance)是不可分割的部分。
第5章 性能優化的流程
5.1 性能評價
首先「快」與「慢」須要一個客觀的指標，同時明肯定義測試階段的起訖點。
同時優化也要考慮到可移植性以及普適性，不要由於優化過分致使其餘問題的出現。
5.2 性能優化的流程
1. 測量，得到數據，知道和目標性能指標的差距。
2. 分析待優化的程序，查找性能瓶頸。
3. 修改程序。
4. 從新測試，驗證優化結果。
5. 達到性能要求，中止優化。不達目標，繼續分析。
5.3 性能評測
介紹兩種方法：可視操做(攝像頭)和日誌。
話說攝像頭錄像評測，仍是很奇葩的，適用範圍很窄。可是貌似仍是有必定市場。
5.4 性能分析
致使性能低下的三種主要緣由：
(1) 程序運算量很大，消耗過多CPU指令。
(2) 程序須要大量I/O，讀寫文件、內存操做等，CPU更多處於I/O等待。
(3) 程序之間相互等待，結果CPU利用率很低。
簡單來講便是CPU利用率高、I/O等待時間長、死鎖狀況。
下面重點放在第一種狀況，提供三種方法。
1. 系統相關：/proc/stat、/proc/loadavg
cat /proc/stat結果以下：
cpu 12311503 48889 7259266 561072284 575332 0 72910 0 0 0-----分別是user、nice、system、idle、iowait、irq、softirq、steal、guest、guest_nice
user：從系統啓動開始累計到當前時刻，用戶態CPU時間，不包含nice值爲負的進程。
nice：從系統啓動開始累計到當前時刻，nice值爲負的進程所佔用的CPU時間。
system：從系統啓動開始累計到當前時刻，內核所佔用的CPU時間。
idle：從系統啓動開始累計到當前時刻，除硬盤IO等待時間之外其餘等待時間。
iowait：從系統啓動開始累計到當前時刻，硬盤IO等待時間。
irq：從系統啓動開始累計到當前時刻，硬中斷時間。
softirq：從系統啓動開始累計到當前時刻，軟中斷時間。
steal：從系統啓動開始累計到當前時刻，involuntary wait
guest：running as a normal guest
guest_nice：running as a niced guest
cpu0 3046879 11947 1729621 211387242 95062 0 1035 0 0 0 cpu1 3132086 8784 1788117 116767388 60010 0 535 0 0 0 cpu2 3240058 12964 1826822 116269699 353944 0 31989 0 0 0 cpu3 2892479 15192 1914705 116647954 66316 0 39349 0 0 0 intr 481552135 16 183 0 0 0 0 0 0 175524 37 0 0 2488 0 0 0 249 23 0 0 0 0 0 301 0 0 3499749 21 1470158 156 33589268 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
-------------------Counts of interrupts services since boot time.Fist column is the total of all interrupts services, each subsequent if total for particular interrupt.
ctxt 2345712926-------------------------------------------------Toal number of context switches performed since bootup accross all CPUs. btime 1510217813------------------------------------------------Give the time at which the system booted, in seconds since the Unix epoch. processes 556059------------------------------------------------Number of processes and threads created, include(but not limited to) those created by fork() or clone() system calls. procs_running 2-------------------------------------------------Current number of runnable threads procs_blocked 1-------------------------------------------------Current number of threads blocked, waiting for IO to complete. softirq 415893440 117 134668573 4001105 57050104 3510728 18 1313611 104047789 0 111301395---總softirq和各類類型softirq產生的中斷數：HI_SOFTIRQ,TIMER_SOFTIRQ,NET_TX_SOFTIRQ,NET_RX_SOFTIRQ,BLOCK_SOFTIRQ,IRQ_POLL_SOFTIRQ,TASKLET_SOFTIRQ,SCHED_SOFTIRQ,HRTIMER_SOFTIRQ,RCU_SOFTIRQ, /* Preferable RCU should always be the last softirq */
由cpu的各類時間能夠推導出：
CPU時間=user+nice+system+idle+iowait+irq+softirq+steal+guest+guest_nice
CPU利用率=1-idle/(user+nice+system+idle+iowait+irq+softirq+steal+guest+guest_nice)
CPU用戶態利用率=(user+nice)/(user+nice+system+idle+iowait+irq+softirq+steal+guest+guest_nice)
CPU內核利用率=system/(user+nice+system+idle+iowait+irq+softirq+steal+guest+guest_nice)
IO利用率=iowait/(user+nice+system+idle+iowait+irq+softirq+steal+guest+guest_nice)
cat /proc/loadavg結果以下：
0.46 0.25 0.16 2/658 13300
一、五、15分鐘平均負載；
2/658：在採樣時刻，運行隊列任務數目和系統中活躍任務數目。
13300：最大pid值，包括線程。
2. 進程相關：/proc/xxx/stat
24021 (atop) S 1 24020 24020 0 -1 4194560 6179 53 0 0 164 196 0 0 0 -20 1 0 209898810 19374080 1630 18446744073709551615 1 1 0 0 0 0 0 0 27137 0 0 0 17 1 0 0 0 0 0 0 0 0 0 0 0 0 0
3. top
top是最經常使用來監控系統範圍內進程活動的工具，提供運行在系統上的與CPU關係最密切的進程列表，以及不少統計值。
第6章 進程啓動速度
進程啓動能夠分爲兩部分：
(1) 進程啓動，加載動態庫，直到main函數值錢。這是尚未執行到程序員編寫的代碼，其性能優化有其特殊方法。
(2) main函數以後，直到對用戶的操做有所響應。涉及到自身編寫代碼的優化，在七、8章介紹。
6.1 查看進程的啓動過程
hello源碼以下：
#include <stdio.h>
#include <stdlib.h>
int main() { printf("Hello world!\n"); return 0; }
編譯：
gcc -o hello -O2 hello.c
strace用於查看系統運行過程當中系統調用，同時得知進程在加載動態庫時的大概過程，-tt能夠打印微妙級別時間戳。
strace -tt ./hello以下：
20:15:10.185596 execve("./hello", ["./hello"], [/* 82 vars */]) = 0
20:15:10.186087 brk(NULL) = 0x19ad000
20:15:10.186206 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
20:15:10.186358 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f24710ea000
20:15:10.186462 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) 20:15:10.186572 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 20:15:10.186696 fstat(3, {st_mode=S_IFREG|0644, st_size=121947, ...}) = 0 20:15:10.186782 mmap(NULL, 121947, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f24710cc000 20:15:10.186857 close(3) = 0 20:15:10.186975 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) 20:15:10.187074 open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 20:15:10.187153 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 832) = 832----------------libc.so.6文件句柄3，大小832。 20:15:10.187270 fstat(3, {st_mode=S_IFREG|0755, st_size=1868984, ...}) = 0 20:15:10.187358 mmap(NULL, 3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2470afd000 20:15:10.187435 mprotect(0x7f2470cbd000, 2097152, PROT_NONE) = 0 20:15:10.187558 mmap(0x7f2470ebd000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c0000) = 0x7f2470ebd000---參數依次是：addr、length、prot、flags、fd、offset。 20:15:10.187662 mmap(0x7f2470ec3000, 14752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2470ec3000 20:15:10.187749 close(3) = 0 20:15:10.187887 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f24710cb000 20:15:10.187992 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f24710ca000 20:15:10.188072 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f24710c9000 20:15:10.188191 arch_prctl(ARCH_SET_FS, 0x7f24710ca700) = 0--------------------------------set architecture-specific thread state, the parameters are code and addr。 20:15:10.188334 mprotect(0x7f2470ebd000, 16384, PROT_READ) = 0 20:15:10.188419 mprotect(0x600000, 4096, PROT_READ) = 0 20:15:10.188541 mprotect(0x7f24710ec000, 4096, PROT_READ) = 0 20:15:10.188633 munmap(0x7f24710cc000, 121947) = 0 20:15:10.188785 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0 20:15:10.188965 brk(NULL) = 0x19ad000 20:15:10.189158 brk(0x19ce000) = 0x19ce000 20:15:10.189243 write(1, "Hello world!\n", 13Hello world!-----------------------------------往句柄1寫13個字符Hello world!\n。 ) = 13 20:15:10.189299 exit_group(0) = ? 20:15:10.189387 +++ exited with 0 +++
經過設置LD_DEBUG環境變量，能夠打印出在進程加載過程當中都作了那些事情：
LD_DEBUG=all ./hello以下。看似簡單的一個Hello world!，其系統已經作了不少準備工做。
13755: 13755: file=libc.so.6 [0]; needed by ./hello [0]----------(1) 搜索其所依賴的動態庫。 13755: find library=libc.so.6 [0]; searching 13755: search cache=/etc/ld.so.cache 13755: trying file=/lib/x86_64-linux-gnu/libc.so.6 13755: 13755: file=libc.so.6 [0]; generating link map 13755: dynamic: 0x00007fbac5cedba0 base: 0x00007fbac592a000 size: 0x00000000003c99a0 13755: entry: 0x00007fbac594a950 phdr: 0x00007fbac592a040 phnum: 10 13755: 13755: checking for version `GLIBC_2.2.5' in file /lib/x86_64-linux-gnu/libc.so.6 [0] required by file ./hello [0] 13755: checking for version `GLIBC_2.3' in file /lib64/ld-linux-x86-64.so.2 [0] required by file /lib/x86_64-linux-gnu/libc.so.6 [0] 13755: checking for version `GLIBC_PRIVATE' in file /lib64/ld-linux-x86-64.so.2 [0] required by file /lib/x86_64-linux-gnu/libc.so.6 [0] 13755: 13755: Initial object scopes------------------------------(2) 加載動態庫。
13755: object=./hello [0]
13755: scope 0: ./hello /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2
13755: object=linux-vdso.so.1 [0]
13755: scope 0: ./hello /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2 13755: scope 1: linux-vdso.so.1 13755: 13755: object=/lib/x86_64-linux-gnu/libc.so.6 [0] 13755: scope 0: ./hello /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2 13755: 13755: object=/lib64/ld-linux-x86-64.so.2 [0] 13755: no scope 13755: 13755: 13755: relocation processing: /lib/x86_64-linux-gnu/libc.so.6 (lazy) 13755: symbol=_res; lookup in file=./hello [0] 13755: symbol=_res; lookup in file=/lib/x86_64-linux-gnu/libc.so.6 [0] 13755: binding file /lib/x86_64-linux-gnu/libc.so.6 [0] to /lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `_res' [GLIBC_2.2.5] ... 13755: symbol=__vdso_time; lookup in file=linux-vdso.so.1 [0] 13755: binding file linux-vdso.so.1 [0] to linux-vdso.so.1 [0]: normal symbol `__vdso_time' [LINUX_2.6] 13755: symbol=__vdso_gettimeofday; lookup in file=linux-vdso.so.1 [0] 13755: binding file linux-vdso.so.1 [0] to linux-vdso.so.1 [0]: normal symbol `__vdso_gettimeofday' [LINUX_2.6] 13755: 13755: relocation processing: ./hello (lazy) 13755: symbol=__gmon_start__; lookup in file=./hello [0] 13755: symbol=__gmon_start__; lookup in file=/lib/x86_64-linux-gnu/libc.so.6 [0] 13755: symbol=__gmon_start__; lookup in file=/lib64/ld-linux-x86-64.so.2 [0] ... 13755: 13755: calling init: /lib/x86_64-linux-gnu/libc.so.6--------(3) 初始化動態庫。 13755: 13755: symbol=__vdso_clock_gettime; lookup in file=linux-vdso.so.1 [0] 13755: binding file linux-vdso.so.1 [0] to linux-vdso.so.1 [0]: normal symbol `__vdso_clock_gettime' [LINUX_2.6] 13755: symbol=__vdso_getcpu; lookup in file=linux-vdso.so.1 [0] 13755: binding file linux-vdso.so.1 [0] to linux-vdso.so.1 [0]: normal symbol `__vdso_getcpu' [LINUX_2.6] 13755: symbol=__libc_start_main; lookup in file=./hello [0] 13755: symbol=__libc_start_main; lookup in file=/lib/x86_64-linux-gnu/libc.so.6 [0] 13755: binding file ./hello [0] to /lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `__libc_start_main' [GLIBC_2.2.5] 13755: 13755: initialize program: ./hello--------------------------(4) 初始化進程。 13755: 13755: 13755: transferring control: ./hello------------------------(5) 將程序的控制權交給main函數。 13755: 13755: symbol=puts; lookup in file=./hello [0] 13755: symbol=puts; lookup in file=/lib/x86_64-linux-gnu/libc.so.6 [0] 13755: binding file ./hello [0] to /lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `puts' [GLIBC_2.2.5] 13755: symbol=_dl_find_dso_for_object; lookup in file=./hello [0] 13755: symbol=_dl_find_dso_for_object; lookup in file=/lib/x86_64-linux-gnu/libc.so.6 [0] 13755: symbol=_dl_find_dso_for_object; lookup in file=/lib64/ld-linux-x86-64.so.2 [0] 13755: binding file /lib/x86_64-linux-gnu/libc.so.6 [0] to /lib64/ld-linux-x86-64.so.2 [0]: normal symbol `_dl_find_dso_for_object' [GLIBC_PRIVATE] Hello world!-------------------------------------------------------(6) 執行用戶程序。 13755: 13755: calling fini: ./hello [0]---------------------------(7) 執行去初始化動做。
6.2 減小加載動態庫的數量
正如《Systems Performance》所說的，最好的優化就是取出沒必要要的工做。
(1) 將一些無用的動態庫去掉。
(2) 從新組織動態庫的結構，力爭將進程加載動態庫的數量減到最小。
(3) 將一些動態庫編譯成靜態庫，與進程或其餘動態庫合併。
優勢是：
- 減小了加載動態庫的數量。
- 在與其餘動態庫合併以後，動態庫內部之間的函數調用沒必要再進行符號查找、動態連接。
缺點是：
- 若是被其餘進程或動態庫依賴，則會致使被複制多份，佔用更多空間。
- 失去了代碼段內存共享，致使內存使用增長。
- 因爲被多個進程使用，致使page fault增多，進而影響加載速度。
所以，對於只被不多進程加載的動態庫，將其編譯成靜態庫，減小進程啓動時加載動態庫的數量。對於那些守護使用的動態庫，代碼段大多已經被加載到內存，運行時產生的page fault要少，所以動態庫反而要比靜態庫速度更快。
(4) 使用dlopen動態加載動態庫。能夠精確控制動態庫的生存週期，一方面能夠減小動態庫數據段的內存使用，另外一方面能夠減小進程啓動時加載動態庫的時間。
6.3 共享庫的搜索路徑
在進程加載動態庫是，loader要從不少路徑搜索動態庫，搜索順序是：DT_NEED-->DT_RPATH-->LD_LIBRARY_PATH-->LD_RUNPATH-->ld.so.conf-->/lib /usr/lib。
DT_RPATH和LD_RUNPATH是程序編譯時加的選項，使用-rpath來設置DT_RPATH。
還存在一種比DT_RPATH更高優先級的目錄搜索機制HWCAP。HWCAP是爲了支持系統根據不一樣的硬件特性，道不一樣的目錄去搜索動態庫。
能夠經過屏蔽LD_HWCAP_MASK減小搜索路徑。
export LD_HWCAP_MASK=0X00000000
6.4 動態庫的高度
依據動態庫之間的依賴關係，從當前動態庫到最底層動態庫之間的最長路徑，成爲該動態庫的高度。
下降動態庫的高度，有利於提升加載時間。
6.5 動態庫的初始化
在loader完成對動態庫的內存應設置後，須要運行動態庫的一些初始化函數，來完成設置動態庫的一些基本環境。包括兩部分：
(1) 動態庫的構造和析構函數機制
首先構造三個文件hello.c、hello.h、main.c。
===========hello.c============ #include <stdio.h> void __attribute__ ((constructor)) my_init(void) { printf("constructor\n");; } void __attribute__ ((destructor)) my_finit(void) { printf("destructor\n");; } void hello(const char *name) { printf("Hello %s!\n", name); } ===========hello.h============ #ifndef HELLO_H #define HELLO_H void hello(const char *name); #endif //HELLO_H ===========main.c============ #include "hello.h" int main() { hello("everyone"); return 0; }
而後編譯庫(gcc -fPIC -shared -o libmyhello.so hello.c)、拷貝庫到系統lib目錄(sudo cp libmyhello.so /usr/lib)、編譯執行文件(gcc -o hello main.c -L./ -lmyhello)。
執行./hello結果以下：
constructor Hello everyone! destructor
(2) 動態庫的全局變量初始化工做
在C語言中，全局變量保存在.data段。再啓動過程當中，loader只是簡單地使用mmap將數據段映射到dirty page，這些變量只有在第一次使用到的時候纔會爲其分配物理內存。
從優化的角度來說，要儘可能減小全局對象的使用。
6.6 動態連接
首先給一段代碼，基於此看看動態連接的過程。
#include <stdio.h> int main() { printf("hello\n"); return 0; }
printf是glibc中定義，採用動態庫，在程序編譯階段，編譯器沒法得知printf函數地址。
在程序運行時，當調用printf的時候，程序會將處理權交給linker，由其負責在執行文件以及其鏈接的動態庫中查找printf函數地址。
因爲linker不知道printf具體在哪一個動態庫，因此將在整個執行文件和動態庫範圍內查找。
26221: 26221: runtime linker statistics: 26221: total startup time in dynamic loader: 703291 cycles 26221: time needed for relocation: 188666 cycles (26.8%) 26221: number of relocations: 77 26221: number of relocations from cache: 3 26221: number of relative relocations: 1199 26221: time needed to load objects: 325593 cycles (46.2%) hello 26221: 26221: runtime linker statistics: 26221: final number of relocations: 82 26221: final number of relocations from cache: 3
能夠看出及時簡單打印hello，在啓動過程當中查找、連接了不少符號，耗費了大量cpu cycle。
優化的方法：
(1) 減小導出符號的數量
經過去掉那些動態庫中沒必要導出的符號，從而減小動態庫在作連接時所查找的符號的數量，能夠加快動態連接的速度。
(2) 減小符號的長度
在作符號連接時，linker將作字符串的匹配，符號名字越長，其查找匹配的時間越長。
(3) 使用prelink
若是動態庫在編譯的時候就能肯定運行時的加載地址，那麼動態庫函數調用的地址就應該是已知的，在進程運行的時候就沒有必要再進行符號的查找和連接，從而節省進程的啓動時間。
6.7 提升進程啓動速度
1. 將進程改成線程
2. prefork進程
3. preload進程
4. 提早加載，延後退出
5. 調整CPU的頻率
整體來說，優化進程的啓動速度的順序爲：
(1) 優化動態庫的搜索路徑
(2) 檢查進程中是否有無用的動態庫
(3) 減小進程或所依賴動態庫的全局對象的數量
(4) 使用prelink，預先連接進程的動態庫
(5) 考慮從新組織動態庫，爭取減小進程加載動態庫的數量
(6) 考慮使用dlopen，將一塊兒啓動時不須要的動態庫從進程的依賴動態庫中去除
若是仍然沒法知足要求，能夠採用調度的方法：
(1) 進程改成線程
(2) preload進程
(3) 提早加載、延遲退出。
6.8 進程冷起與熱起的區別
在程序第一次啓動(冷起)退出後，再次啓動速度明顯比第一次快，爲何呢？
在程序第一次啓動、退出後，進程雖然被銷燬了，可是進程代碼段所佔用的物理內存並無被銷燬；而是被Linux緩存起來，保存在Cache中。
這樣程序再次啓動時，指令沒必要再從Flash讀到內存中，而是直接使用Linux內核中的Cache，減小了程序啓動過程當中所產生的page fault，從而加快了進程的啓動速度。
在進程啓動過程當中：
(1) 進程冷起時，若是運行的指令較多，則出現的page fault較多，影響進程的啓動速度。
(2) 進程所依賴的某些動態庫可能已經被一些守護進程所加載，其代碼段已經在內存中，故這種動態庫對進程的冷起和熱起性能影響不大。
(3) 沒有被其餘進程使用過的動態庫，在冷起時則會產生page fault影響進程的啓動速度。
第7章 性能優化的方法
程序優化！=編碼技巧
編碼技巧是程序優化的一部分；程序優化涉及到硬件架構、程序架構、邏輯設計等，還有一點如何肯定代碼瓶頸位置很重要。
7.1 尋找程序熱點
1. gprof
#include <stdio.h> void funca() { int i = 0, n = 0; for(i=0; i<10000000; i++) { n++; n--; } } void funcb() { int i = 0, n = 0; for(i=0; i<10000000; i++) { n++; n--; } } int main() { int i=0; for(i=0;i<10;i++) { funca(); } funcb(); return 0; }
而後編譯(gcc performance.c -pg -o performance)、運行(./performance)、查看結果(gprof performance gmon.out -q -p)。
gprof performance gmon.out -p Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 91.95 0.40 0.40 10 40.46 40.46 funca 9.20 0.45 0.04 1 40.46 40.46 funcb ========================================= gprof performance gmon.out -q Call graph (explanation follows) granularity: each sample hit covers 2 byte(s) for 2.25% of 0.45 seconds index % time self children called name <spontaneous> [1] 100.0 0.00 0.45 main [1] 0.40 0.00 10/10 funca [2] 0.04 0.00 1/1 funcb [3] ----------------------------------------------- 0.40 0.00 10/10 main [1] [2] 90.9 0.40 0.00 10 funca [2] ----------------------------------------------- 0.04 0.00 1/1 main [1] [3] 9.1 0.04 0.00 1 funcb [3] -----------------------------------------------
2. oprofile
7.2 程序邏輯瓶頸
oprofile只能有助於發現熱點，可是對程序熱點與代碼邏輯對應關係沒法對應，所以不能定位由邏輯問題所形成的瓶頸。
能夠經過添加日誌的方法來肯定不一樣邏輯部分耗時。進而找出邏輯問題。
PS：這裏做者講到的日誌多形成的反作用，在動態log，和能夠添加filter的log中是不存在的。
7.3 優化的層次
1. 針對某一特定事例的優化，考慮使用oprofile，查找熱點，進行優化。主要以擴及優化爲主、程序熱點函數優化爲輔。
2. 系統總體性能的提升，分兩層：業務邏輯的優化和底層基礎函數性能優化。
上層業務邏輯優化：重點在於邏輯的調整、算法的優化。
底層基礎函數遊湖：重點在於代碼的寫做技巧。
7.4 什麼時候開始性能優化
(1) 在需求階段，就要把性能指標定義下來。
(2) 在軟件設計階段，要考慮這些性能指標，根據指標來考慮程序所使用的算法、邏輯，在這個階段考慮邏輯上的優化。
(3) 在軟件功能基本完成後，一方面軟件的邏輯要作一些細微調整，另外一方面要開始使用oprofile之類的工具查找熱點函數，對熱點函數作代碼優化。
7.5 如何推進系統性能優化
(1) 須要找出一些關鍵的步驟，這些步驟性能直接影響着用戶使用體驗。
(2) 爲這些關鍵的過程定義相應的性能指標。
(3) 在定義性能指標後，須要測試現系統，看看各個過程和目標性能之間的差距。
(4) 拿到結果以後嗎，須要和相應開發團隊談判，要求其優化代碼。
當優化任務 陷入僵局的時候，要求相應團隊出具兩份報告：一，從程序邏輯考慮，程序都作了哪些事情，每一個事情花了多少時間，主要算法是什麼；二，這個過程當中oprofile報告，包括每一個函數執行時間佔比。查看前幾名函數邏輯上是否合理；對於前幾名函數，檢查其從算法實現到代碼優化層次是否可以進行優化。
(5) 在各個團隊優化完代碼以後，返回流程(3)重新測試性能。如沒有達標，繼續3~5過程。
7.6 爲何軟件性能會低下
7.7 程序邏輯優化
5個程序優化的思路：
(1) Do it faster：找到最有效率的方法，來提升程序的運行速度。
(2) Do it in parallel：並行加快執行速度。
(3) Do it later：沒必要要的功能，能夠考慮延後執行，騰出資源作重要的事。
(4) Don't do it at all：最好的優化就是不作事。
(5) Do it before：把一些工做空閒時預先完成。
第8章 代碼優化的境界
從高級語言C/C++，到指令在系統上運行，分兩個階段：
(1) 編譯器將C/C++轉變成能夠在系統上運行的機器指令。編譯器會對代碼進行優化，優化後的機器指令可能與編寫的代碼有較大差別。
(2) 機器指令在不一樣硬件上執行，與體系結構、執行環境有密切關係。
因此優化代碼有兩個境界：從代碼看到編譯器優化後產生的彙編指令；根據芯片組特性，能看到彙編語言在硬件中執行狀態，好比流水線使用狀況、緩存命中率等等。
8.1 GCC編譯優化
8.1.1 條件編譯
經過宏來下降條件判斷等操做，提升效率。
gcc -DXXX
8.1.2 指定CPU的型號
gcc -mcpu=XXX，是編譯出來的代碼可以充分利用硬件平臺的特色，加快程序的執行速度。
8.1.3 builtin函數
GCC提供一些builtin函數來完成一些特殊功能。
(1) void *__builtin_apply_args(void);
(1) void *__builtin_apply(void (*func)(), void *arguments, int size);
(1) void *__builtin_return(void *result);
GCC網站http://gcc.gnu.org/onlinedocs/提供了builtin詳細信息。
8.1.4 GCC編譯優化
-O0 關閉編譯器優化
-O/-O1 增長了一些GCC優化代碼選項
-O2 除了完成全部-O1級別的優化以外，增長了好比處理器指令調度等。
-O3 除了完成全部-O2級別的優化以外，增長了循環展開和其餘一些處理器特性相關優化工做。
8.2 優化基本原則
8.3 標準C代碼優化
8.4 C++代碼優化
8.5 硬件相關的優化
第9章 系統性能優化
9.1 Shell腳本優化
9.1.1 Shell腳本優化
在嵌入式Linux中，bash腳本佔很大比重。優化shell有助於縮短系統啓動時間，加快進程的執行速度。
在Linux bash shell通常由Busybox實現，命令主要被分爲兩大類：built-ins和applets。
Built-ins只是簡單的函數調用，而applets則意味着須要調用"fork/exec"建立子進程來執行，而且busybox也可使用外部命令。
處於性能考慮，應使用built-ins來代替applets和外部命令。
輸入busybox，能夠看到支持的全部功能。
include/applets.h中，定義了BusyBox支持的全部功能。
docs/nofork_noexec.txt中，說明了built-ins和applets的區別。
applets.h定義功能的時候，也定義了類型，分類以下：
(1) APPLET：即applets，建立一個子進程，而後調用exec執行相應的功能，執行完畢後，返還控制給父進程。
(2) APPLET_NOUSAGE：BusyBox中不包含該命令的幫助文檔。
(3) APPLET_NOEXEC：調用fork建立子進程，而後執行BusyBox對應功能，執行完畢後，返回控制給父進程。
(4) APPLET_NOFORK：至關於built-ins，只執行BusyBox內部函數，不建立子進程，效率最高。
9.1.2 bash腳本
包含在pipe中的built-ins將建立子進程來執行。
包含在'中的命令將建立子進程來執行。
對bash腳本進行優化時，要儘可能避免fork進程。
9.1.3 如何優化busybox bansh腳本
(1) 去掉腳本中無用的代碼
(2) 儘量使用busybox中的built-ins替換外部命令
printf "Starting" --> echo "Starting"
(3) 儘量不使用pipe
(4) 減小pipe中的命令數
(5) 儘量不適用"'"
更多方法參考：Optimize RC Scripts
9.2 使用preload預先加載進程
在系統比較空閒時，經過將特定程序的代碼從Flash加載到Cache，加快進程執行速度。
可否控制在Cache內存回收時，對某些關鍵進程所佔用的Cache儘可能少回收，加大某一進程Cache內存數量。
Linux有一個開源項目preload，就是利用控制Linux中的cache，來加快進程的啓動速度。
相似的技術有prelink和readahead
9.3 調整進程的優先級
在Linux內核中，支持兩種進程：實時進程和普通進程。
(1) 實時進程
實時進程的優先級是靜態設定的，只有當運行隊列沒有實時進程的狀況下，普通進程纔可以得到調度。
實時進程採用兩種調度策略：SCHED_FIFO和SCHED_RR。
FIFO採用先進先出的策略，對於全部相同優先級的進程，最早進入runqueue的進程總能優先得到調度；Round Robin採用更加公平的輪轉策略，使得相同優先級的實時進程可以輪流得到調度。
對於實時進程來說，使用絕對優先級概念，絕對優先級取值範圍是0~99，數字越大，優先級越高。
(2) 普通進程
Linux 2.6普通進程的絕對優先級取值是0，普通進程有靜態優先級和動態優先級之分。
能夠經過nice修改進程的靜態優先級。
系統在運行過程當中，在靜態優先級基礎上，不斷動態計算出每一個進程的動態優先級，擁有最高優先級的進程被調度器選中。
動態優先級計算公式：動態優先級=max(100,min(靜態優先級-bonus+5，139))
bonus取決於進程的平均睡眠時間。
對實時進程設置經過以下函數進行：
#include <sched.h> int sched_setscheduler(pid_t pid, int policy, const struct sched_param *param); int sched_getscheduler(pid_t pid); int sched_setparam(pid_t pid, const struct sched_param *param); int sched_getparam(pid_t pid, const struct sched_param *param);
pid：指定所要設置的進程號，pid爲0，表示爲當前進程。
policy：設置進程調度策略，SCHED_OTHER/SCHED_FIFO/SCHED_RR。
param：設置進程的絕對優先級，範圍是0~99。
對普通進程來說，絕對優先級爲0，經過nice來影響進程的調度。
nice取值-20~19，能夠經過setpriority來設置普通進程優先級。
#include <sys/resource.h> int setpriority(int class, int id, int niceval);
class：PRIO_PROCESS/PRIO_PGRP/PRIO_USER。
niceval：爲進程nice值，-20~19。
對實時線程操做，使用pthread_setschedparam；對普通線程，仍然可使用setpriority和nice來調整線程優先級。
9.4 讓進程運行的慢一些
對於某些沒有時限要求的進程，能夠下降運行速度。
(1) 下降進程優先級。
(2) 增長一些代碼來控制Linux中進程的調度，如sched_yield自願放棄CPU，進程仍然處於TASK_RUNNING狀態，但調度器把它放在運行隊列鏈表的末尾。
9.5 守護進程的數量
守護進程佔用大量動態庫代碼段和數據段內存，內存蟹柳機率加大，CPU性能降低，致使系統總體性能降低。
9.6 文件系統
主要看基於Flash和RAM的兩大類文件系統。
基於Flash的文件系統：JFFS二、YAFFS二、Cramfs、Romfs，YAFFS2目前被普遍運用。
基於RAM的文件系統：Ramdisk(在Linux啓動，initrd提供將內核映像和根文件系統一塊兒載入內存)、Ramfs/tmpfs(把全部的文件都放在RAM中)。
9.7 使用Lmbench瞭解你的系統
9.8 系統的啓動
關於Linux啓動速度，有一個網頁進行了詳細的總結：Boot Time。
9.9 系統耗電量
本章節所講技術已經落後。
- 1. 《嵌入式Linux內存使用與性能優化》筆記
- 2. Linux性能優化筆記
- 3. iOS 使用Instruments優化內存性能
- 4. 嵌入式系統的性能優化
- 5. Linux性能優化-內存性能優化思路
- 6. 嵌入式linux優化
- 7. LINUX性能優化-內存篇
- 8. android性能評測與優化-內存
- 9. CocosCreator內存與性能優化
- 10. Android之——性能與內存優化
- 更多相關文章...
- • SEO - 搜索引擎優化 - 網站建設指南
- • Redis內存回收策略 - Redis教程
- • Tomcat學習筆記（史上最全tomcat學習筆記）
- • Java Agent入門實戰（一）-Instrumentation介紹與使用
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. Window下Ribbit MQ安裝
- 2. Linux下Redis安裝及集羣搭建
- 3. shiny搭建網站填坑戰略
- 4. Mysql8.0.22安裝與配置詳細教程
- 5. Hadoop安裝及配置
- 6. Python爬蟲初學筆記
- 7. 部署LVS-Keepalived高可用集羣
- 8. keepalived+mysql高可用集羣
- 9. jenkins 公鑰配置
- 10. HA實用詳解
- 1. 《嵌入式Linux內存使用與性能優化》筆記
- 2. Linux性能優化筆記
- 3. iOS 使用Instruments優化內存性能
- 4. 嵌入式系統的性能優化
- 5. Linux性能優化-內存性能優化思路
- 6. 嵌入式linux優化
- 7. LINUX性能優化-內存篇
- 8. android性能評測與優化-內存
- 9. CocosCreator內存與性能優化
- 10. Android之——性能與內存優化