① linux 清除緩存 釋放內存
這里的默認顯示單位是kb，我的伺服器是128G內存，所以數字顯得比較大。這個命令幾乎是每一個使用過Linux的人必會的命令，但越是這樣的命令，似乎真正明白的人越少（我是說比例越少）。一般情況下，對此命令輸出的理解可以分這幾個層次：
1.不了解。這樣的人的第一反應是：天啊，內存用了好多，70個多G，可是我幾乎沒有運行什麼大程序啊？為什麼會這樣？Linux好占內存！
2.自以為很了解。這樣的人一般評估過會說：嗯，根據我專業的眼光看的出來，內存才用了17G左右，還有很多剩餘內存可用。buffers/cache佔用的較多，說明系統中有進程曾經讀寫過文件，但是不要緊，這部分內存是當空閑來用的。
3.真的很了解。這種人的反應反而讓人感覺最不懂Linux，他們的反應是：free顯示的是這樣，好吧我知道了。神馬？你問我這些內存夠不夠，我當然不知道啦！我特么怎麼知道你程序怎麼寫的？
根據目前網路上技術文檔的內容，我相信絕大多數了解一點Linux的人應該處在第二種層次。大家普遍認為，buffers和cached所佔用的內存空間是可以在內存壓力較大的時候被釋放當做空閑空間用的。但真的是這樣么？在論證這個題目之前，我們先簡要介紹一下buffers和cached是什麼意思：
什麼是buffer/cache？
buffer和cache是兩個在計算機技術中被用濫的名詞，放在不通語境下會有不同的意義。在Linux的內存管理中，這里的buffer指Linux內存的：Buffer cache。這里的cache指Linux內存中的：Page cache。翻譯成中文可以叫做緩沖區緩存和頁面緩存。在歷史上，它們一個（buffer）被用來當成對io設備寫的緩存，而另一個（cache）被用來當作對io設備的讀緩存，這里的io設備，主要指的是塊設備文件和文件系統上的普通文件。但是現在，它們的意義已經不一樣了。在當前的內核中，page cache顧名思義就是針對內存頁的緩存，說白了就是，如果有內存是以page進行分配管理的，都可以使用page cache作為其緩存來管理使用。當然，不是所有的內存都是以頁（page）進行管理的，也有很多是針對塊（block）進行管理的，這部分內存使用如果要用到cache功能，則都集中到buffer cache中來使用。（從這個角度出發，是不是buffer cache改名叫做block cache更好？）然而，也不是所有塊（block）都有固定長度，系統上塊的長度主要是根據所使用的塊設備決定的，而頁長度在X86上無論是32位還是64位都是4k。
明白了這兩套緩存系統的區別，就可以理解它們究竟都可以用來做什麼了。
什麼是page cache？
Page cache主要用來作為文件系統上的文件數據的緩存來用，尤其是針對當進程對文件有read／write操作的時候。如果你仔細想想的話，作為可以映射文件到內存的系統調用：mmap是不是很自然的也應該用到page cache？在當前的系統實現里，page cache也被作為其它文件類型的緩存設備來用，所以事實上page cache也負責了大部分的塊設備文件的緩存工作。
什麼是buffer cache？
Buffer cache則主要是設計用來在系統對塊設備進行讀寫的時候，對塊進行數據緩存的系統來使用。這意味著某些對塊的操作會使用buffer cache進行緩存，比如我們在格式化文件系統的時候。一般情況下兩個緩存系統是一起配合使用的，比如當我們對一個文件進行寫操作的時候，page cache的內容會被改變，而buffer cache則可以用來將page標記為不同的緩沖區，並記錄是哪一個緩沖區被修改了。這樣，內核在後續執行臟數據的回寫（writeback）時，就不用將整個page寫回，而只需要寫回修改的部分即可。
如何回收cache？
Linux內核會在內存將要耗盡的時候，觸發內存回收的工作，以便釋放出內存給急需內存的進程使用。一般情況下，這個操作中主要的內存釋放都來自於對buffer／cache的釋放。尤其是被使用更多的cache空間。既然它主要用來做緩存，只是在內存夠用的時候加快進程對文件的讀寫速度，那麼在內存壓力較大的情況下，當然有必要清空釋放cache，作為free空間分給相關進程使用。所以一般情況下，我們認為buffer/cache空間可以被釋放，這個理解是正確的。
② Linux的五種IO模型
在linux中，對於一次讀取IO請求（不僅僅是磁碟，還有網路）的操作，數據並不會直接拷貝到用戶程序的用戶空間緩沖區。它首先會被拷貝到操作系統的內核空間，然後才會從操作系統內核的緩沖區拷貝到用戶空間的緩沖區。
大概是這個樣子。
從圖中可以看見，這是分四步進行的，而這四步裡面有些細節，就有了這5種IO模型
前四種為同步IO，後一種為非同步IO，什麼是同步非同步可以看看我之前寫的 同步與非同步，阻塞與非阻塞 。
應用進程發起系統調用後就阻塞了，直到內核buffer拷貝到用戶buffer，發出成功提示後才繼續執行。
適用場景：並發量小的要及時響應的網路應用開發，JavaBIO。
優點：易於開發，不消耗CPU資源（線程阻塞），及時響應。
缺點：不適用與並發量大的網路應用開發，一個請求一個線程，系統開銷大。
應用進程發起系統調用，內核立馬返回一個自己當前的緩沖區的狀態（錯誤或者說成功），假如
為錯誤則隔段時間再系統調用（輪詢），直到返回成功為止。另外再說一點，有人說輪詢之間可以設置一個時間，例如每幾秒執行一次，然後在這段期間程序可以干自己的事情。（這個我不清楚是不是，雖然理論上可以實現，但是我覺得第一種與第二種的區別應該強調的是是否放棄CPU，第二種有點CAS+輪詢這種輕量級鎖的感覺，第一種就是那種重量級鎖的感覺）。
適用場景：並發量小且不用技術響應的網路應用開發
優點：易於開發，可以在輪詢的間斷期間繼續執行程序。
缺點：不適用與並發量大的網路應用開發，一個請求一個線程，系統開銷大。消耗CPU資源（輪詢），不及時響應。
將多個IO注冊到一個復用器上（select，poll，epoll），然後一個進程監視所有注冊進來的IO。
進程阻塞在select上，而不是真正阻塞在IO系統調用上。當其中任意一個注冊的IO的內核緩沖區有了數據，select就會返回（告訴程序內核態緩存有數據了），然後用戶進程再發起調用，數據就從內核態buffer轉到用態buffer（這段期間也是要阻塞的）。
適用場景：並發量大且對響應要求較為高的網路應用開發，JavaNIO
優點：將阻塞從多個進程轉移到了一個select調用身上，假如並發量大的話select調用是不易被阻塞的，或者說阻塞時間短的。
缺點：不易開發，實現難度大，當並發量小的時候還不如同步阻塞模型。
應用程序向內核注冊一個信號處理程序，然後立即返回，當數據准備好了以後（數據到了內核buffer），內核個應用進程一個信號，然後應用進程通過信號處理程序發起系統調用，然後阻塞直達數據從內核buffer復制到用戶buffer。
優點：將阻塞從多個進程轉移到了一個select調用身上，假如並發量大的話select調用是不易被阻塞的，或者說阻塞時間短的。
缺點：不易開發，實現難度大。
以上四個IO模型都可以看出來，到最後用戶進程都要在數據從內核buffer復制到用戶buffer時阻塞，直到內核告訴進程准備成功。這就是同步進程，就是發出一個功能調用時，在沒有得到結果之前，該調用就不返回或繼續執行後續操作。
就是發出一個功能調用時，在沒有得到結果之前，該調用就不返回或繼續執行後續操作
這個就是直到數據完成到用戶buffer才通知。
應用場景：Java AIO，適合高性能高並發應用。
優點：不阻塞，減少了線程切換，
缺點：難以實現，要操作系統支持。
③ 如何提高Linux伺服器磁碟io性能
您好，很高興為您解答。
在現有文件系統下進行優化：
linux內核和各個文件系統採用了幾個優化方案來提升磁碟訪問速度。但這些優化方案需要在我們的伺服器設計中進行配合才能得到充分發揮。
文件系統緩存
linux內核會將大部分空閑內存交給虛擬文件系統，來作為文件緩存，叫做page cache。在內存不足時，這部分內存會採用lru演算法進行淘汰。通過free命令查看內存，顯示為cached的部分就是文件緩存了。
如何針對性優化：
lru並不是一個優秀淘汰演算法，lru最大的優勢是普適性好，在各種使用場景下都能起到一定的效果。如果能找到當前使用場景下，文件被訪問的統計特徵，針 對性的寫一個淘汰演算法，可以大幅提升文件緩存的命中率。對於http正向代理來說，一個好的淘汰演算法可以用1GB內存達到lru演算法100GB內存的緩存 效果。如果不打算寫一個新的淘汰演算法，一般不需要在應用層再搭一個文件cache程序來做緩存。
最小分配：
當文件擴大，需要分配磁碟空間時，大部分文件系統不會僅僅只分配當前需要的磁碟空間，而是會多分配一些磁碟空間。這樣下次文件擴大時就可以使用已經分配好的空間，而不會頻繁的去分配新空間。
例如ext3下，每次分配磁碟空間時，最小是分配8KB。
最小分配的副作用是會浪費一些磁碟空間（分配了但是又沒有使用）
如何針對性優化：
我們在reiserfs下將最小分配空間從8KB改大到128K後提升了30%的磁碟io性能。如果當前使用場景下小文件很多，把預分配改大就會浪費很多 磁碟空間，所以這個數值要根據當前使用場景來設定。似乎要直接改源代碼才能生效，不太記得了，09年的時候改的，有興趣的同學自己google吧。
io訪問調度：
在同時有多個io訪問時，linux內核可以對這些io訪問按LBA進行合並和排序，這樣磁頭在移動時，可以「順便」讀出移動過程中的數據。
SATA等磁碟甚至在磁碟中內置了io排序來進一步提升性能，一般需要在主板中進行配置才能啟動磁碟內置io排序。linux的io排序是根據LBA進行的，但LBA是一個一維線性地址，無法完全反應出二維的圓形磁碟，所以磁碟的內置io排序能達到更好的效果。
如何針對性優化：
io訪問調度能大幅提升io性能，前提是應用層同時發起了足夠的io訪問供linux去調度。
怎樣才能從應用層同時向內核發起多個io訪問呢？
方案一是用aio_read非同步發起多個文件讀寫請求。
方案二是使用磁碟線程池同時發起多個文件讀寫請求。
對我們的http正向代理來說，採用16個線程讀寫磁碟可以將性能提升到2.5倍左右。具體開多少個線程/進程，可以根據具體使用場景來決定。
小提示：
將文件句柄設置為非阻塞時，進程還是會睡眠等待磁碟io，非阻塞對於文件讀寫是不生效的。在正常情況下，讀文件只會引入十幾毫秒睡眠，所以不太明顯；而在磁碟io極大時，讀文件會引起十秒以上的進程睡眠。
預讀取：
linux內核可以預測我們「將來的讀請求」並提前將數據讀取出來。通過預讀取可以減少讀io的次數，並且減小讀請求的延時。
如何針對性優化：
預讀取的預測准確率是有限的，與其依賴預讀取，不如我們直接開一個較大的緩沖區，一次性將文件讀出來再慢慢處理；盡量不要開一個較小的緩沖區，循環讀文件/處理文件。
雖然說「預讀取」和「延遲分配」能起到類似的作用，但是我們自己擴大讀寫緩沖區效果要更好。
延遲分配：
當文件擴大，需要分配磁碟空間時，可以不立即進行分配，而是暫存在內存中，將多次分配磁碟空間的請求聚合在一起後，再進行一次性分配。
延遲分配的目的也是減少分配次數，從而減少文件不連續。
延遲分配的副作用有幾個：
1、如果應用程序每次寫數據後都通過fsync等介面進行強制刷新，延遲分配將不起作用
2、延遲分配有可能間歇性引入一個較大的磁碟IO延時（因為要一次性向磁碟寫入較多數據）
只有少數新文件系統支持這個特性
如何針對性優化：
如果不是對安全性（是否允許丟失）要求極高的數據，可以直接在應用程序里緩存起來，積累到一定大小再寫入，效果比文件系統的延遲分配更好。如果對安全性要求極高，建議經常用fsync強制刷新。
在線磁碟碎片整理：
Ext4提供了一款碎片整理工具，叫e4defrag，主要包含三個功能：
1、讓每個文件連續存儲
2、盡量讓每個目錄下的文件連續存儲
3、通過整理空閑磁碟空間，讓接下來的分配更不容易產生碎片
如何針對性優化：
「讓每個目錄下的文件連續存儲」是一個極有價值的功能。
傳統的做法是通過拼接圖片來將這10張圖片合並到一張大圖中，再由前端將大圖切成10張小圖。
有了e4defrag後，可以將需連續訪問的文件放在同一個文件夾下，再定期使用e4defrag進行磁碟整理。
實現自己的文件系統：
在大部分伺服器上，不需要支持「修改文件」這個功能。一旦文件創建好，就不能再做修改操作，只支持讀取和刪除。在這個前提下，我們可以消滅所有文件碎片，把磁碟io效率提升到理論極限。
有一個公式可以衡量磁碟io的效率：
磁碟利用率 = 傳輸時間/（平均尋道時間+傳輸時間）
如若滿意，請點擊回答右側【採納答案】，如若還有問題，請點擊【追問】
~ O(∩_∩)O~
④ 在linux下關於C語言IO緩沖問題
程序1 和 程序2 區別就是如果是人輸入數據 就會多一個換行符
剛查了下資料
printf的緩存是屬於行緩存的，
「」由於printf函數是行緩沖的(因為它要往終端輸出數據)，而且要列印的字元串不帶換行符，因此在它沒有遇到換行符或者沒有填滿緩沖區之前不會進行實際的IO操作「」
所以程序1 遇到人工輸入的換行符 就會sleep 然後
刷新緩存 輸出緩存的數據
⑤ linux怎麼計算io讀寫速度
Linux下測試磁碟的讀寫IO速度，使用hdparm命令，下面是測試方法：
#hdparm-Tt/dev/sda
/dev/sda:
Timingcachedreads:6676MBin2.00seconds=3340.18MB/sec
Timingbuffereddiskreads:218MBin3.11seconds=70.11MB/sec
#可以看到，2秒鍾讀取了6676MB的緩存，約合3340.18MB/sec；
#在3.11秒中讀取了218MB磁碟(物理讀)，讀取速度約合70.11MB/sec；
⑥ LINUX I/O緩沖區大小
用vmstat監視內存使用情況
vmstat是Virtual Meomory Statistics（虛擬內存統計）的縮寫，可對操作系統的虛擬內存、進程、CPU活動進行監視。它是對系統的整體情況進行統計，不足之處是無法對某個進程進行深入分析。
⑦ linux標准i/o有哪些特點
標准I/O:FILE，
標准庫都是圍繞流進行的，(教訓：fflush就是一種通過刷新緩沖讓緩沖中的數據被讀或者寫)。
我現在憑記憶可以羅列的就只有：FILE結構體， fopen,fread,fwrite,fclose,fgetc,fputc,fgets,fputs,fflush.
標准IO分為全緩沖，行緩沖，不帶緩沖。
全緩沖：填滿緩沖後才執行IO操作。
行緩沖：輸入或輸出中遇到換行符時，標准庫執行IO操作。
對於行緩沖有兩個限制1）行的長度是有限制的，如果一行滿了，即使沒有換行符也會執行IO操作。
2）任何時候，從一個不帶緩沖的流，或者一個行緩沖流得到輸入數據，就會造成沖洗所有緩沖流。【此處，或者很誤解】。
不帶緩沖：字元輸入輸出。通常標准出錯流stderr也是不帶緩沖的。
⑧ Linux系統I/O模型及select、poll、epoll原理和應用
理解Linux的IO模型之前，首先要了解一些基本概念，才能理解這些IO模型設計的依據
操作系統使用虛擬內存來映射物理內存，對於32位的操作系統來說，虛擬地址空間為4G（2^32）。操作系統的核心是內核，為了保護用戶進程不能直接操作內核，保證內核安全，操作系統將虛擬地址空間劃分為內核空間和用戶空間。內核可以訪問全部的地址空間，擁有訪問底層硬體設備的許可權，普通的應用程序需要訪問硬體設備必須通過 系統調用 來實現。
對於Linux系統來說，將虛擬內存的最高1G位元組的空間作為內核空間僅供內核使用，低3G位元組的空間供用戶進程使用，稱為用戶空間。
又被稱為標准I/O，大多數文件系統的默認I/O都是緩存I/O。在Linux系統的緩存I/O機制中，操作系統會將I/O的數據緩存在頁緩存（內存）中，也就是數據先被拷貝到內核的緩沖區（內核地址空間），然後才會從內核緩沖區拷貝到應用程序的緩沖區（用戶地址空間）。
這種方式很明顯的缺點就是數據傳輸過程中需要再應用程序地址空間和內核空間進行多次數據拷貝操作，這些操作帶來的CPU以及內存的開銷是非常大的。
由於Linux系統採用的緩存I/O模式，對於一次I/O訪問，以讀操作舉例，數據先會被拷貝到內核緩沖區，然後才會從內核緩沖區拷貝到應用程序的緩存區，當一個read系統調用發生的時候，會經歷兩個階段：
正是因為這兩個狀態，Linux系統才產生了多種不同的網路I/O模式的方案
Linux系統默認情況下所有socke都是blocking的，一個讀操作流程如下：
以UDP socket為例，當用戶進程調用了recvfrom系統調用，如果數據還沒准備好，應用進程被阻塞，內核直到數據到來且將數據從內核緩沖區拷貝到了應用進程緩沖區，然後向用戶進程返回結果，用戶進程才解除block狀態，重新運行起來。
阻塞模行下只是阻塞了當前的應用進程，其他進程還可以執行，不消耗CPU時間，CPU的利用率較高。
Linux可以設置socket為非阻塞的，非阻塞模式下執行一個讀操作流程如下：
當用戶進程發出recvfrom系統調用時，如果kernel中的數據還沒准備好，recvfrom會立即返回一個error結果，不會阻塞用戶進程，用戶進程收到error時知道數據還沒准備好，過一會再調用recvfrom，直到kernel中的數據准備好了，內核就立即將數據拷貝到用戶內存然後返回ok，這個過程需要用戶進程去輪詢內核數據是否准備好。
非阻塞模型下由於要處理更多的系統調用，因此CPU利用率比較低。
應用進程使用sigaction系統調用，內核立即返回，等到kernel數據准備好時會給用戶進程發送一個信號，告訴用戶進程可以進行IO操作了，然後用戶進程再調用IO系統調用如recvfrom，將數據從內核緩沖區拷貝到應用進程。流程如下：
相比於輪詢的方式，不需要多次系統調用輪詢，信號驅動IO的CPU利用率更高。
非同步IO模型與其他模型最大的區別是，非同步IO在系統調用返回的時候所有操作都已經完成，應用進程既不需要等待數據准備，也不需要在數據到來後等待數據從內核緩沖區拷貝到用戶緩沖區，流程如下：
在數據拷貝完成後，kernel會給用戶進程發送一個信號告訴其read操作完成了。
是用select、poll等待數據，可以等待多個socket中的任一個變為可讀，這一過程會被阻塞，當某個套接字數據到來時返回，之後再用recvfrom系統調用把數據從內核緩存區復制到用戶進程，流程如下：
流程類似阻塞IO，甚至比阻塞IO更差，多使用了一個系統調用，但是IO多路復用最大的特點是讓單個進程能同時處理多個IO事件的能力，又被稱為事件驅動IO，相比於多線程模型，IO復用模型不需要線程的創建、切換、銷毀，系統開銷更小，適合高並發的場景。
select是IO多路復用模型的一種實現，當select函數返回後可以通過輪詢fdset來找到就緒的socket。
優點是幾乎所有平台都支持，缺點在於能夠監聽的fd數量有限，Linux系統上一般為1024，是寫死在宏定義中的，要修改需要重新編譯內核。而且每次都要把所有的fd在用戶空間和內核空間拷貝，這個操作是比較耗時的。
poll和select基本相同，不同的是poll沒有最大fd數量限制（實際也會受到物理資源的限制，因為系統的fd數量是有限的），而且提供了更多的時間類型。
總結：select和poll都需要在返回後通過輪詢的方式檢查就緒的socket，事實上同時連的大量socket在一個時刻只有很少的處於就緒狀態，因此隨著監視的描述符數量的變多，其性能也會逐漸下降。
epoll是select和poll的改進版本，更加靈活，沒有描述符限制。epoll使用一個文件描述符管理多個描述符，將用戶關系的文件描述符的事件存放到內核的一個事件表中，這樣在用戶空間和內核空間的只需一次。
epoll_create()用來創建一個epoll句柄。
epoll_ctl() 用於向內核注冊新的描述符或者是改變某個文件描述符的狀態。已注冊的描述符在內核中會被維護在一棵紅黑樹上，通過回調函數內核會將 I/O 准備好的描述符加入到一個就緒鏈表中管理。
epoll_wait() 可以從就緒鏈表中得到事件完成的描述符，因此進程不需要通過輪詢來獲得事件完成的描述符。
當epoll_wait檢測到描述符IO事件發生並且通知給應用程序時，應用程序可以不立即處理該事件，下次調用epoll_wait還會再次通知該事件，支持block和nonblocking socket。
當epoll_wait檢測到描述符IO事件發生並且通知給應用程序時，應用程序需要立即處理該事件，如果不立即處理，下次調用epoll_wait不會再次通知該事件。
ET模式在很大程度上減少了epoll事件被重復觸發的次數，因此效率要比LT模式高。epoll工作在ET模式的時候，必須使用nonblocking socket，以避免由於一個文件句柄的阻塞讀/阻塞寫操作把處理多個文件描述符的任務餓死。
【segmentfault】 Linux IO模式及 select、poll、epoll詳解
【GitHub】 CyC2018/CS-Notes