linux分頁內存

❶ linux內核：分段和分頁的區別

首先說明內核的保護模式和是模式，在計算機剛剛啟動的時候處於實模式，在該模式下cpu產生20位的地址，然後計算機經過某種變換轉換到保護模式。保護模式下cpu產生32位的地址，也就是說從實模式到保護模式，cpu的定址空間擴大了。

在計算的發展的初期，intel 8086是16位的cpu，它只能運行在實模式下。在該模式下其寄存器是16位的，但是為了可以定址20位的地址空間，所以採用了內存的分段模式。

物理內存地址=段基址×16+偏移 這樣可以定址20位的地址空間。

關於現代計算機內存的分段機制，也是為了向下兼容的需要。單純的向下兼容或許還不夠有說服力，因為在現代cpu中產生的就是32的地址，而由分段機制產生的線性地址也是32位的。32位的地址完全可以訪問4G內存的任何一個地方，看上去分段機制好像完全沒有了作用，其實不然。在多線程，多任務的操作系統中，一個地址能否被一個進程寫入，能被什麼優先順序的進程訪問，是否允許執行這些問題有出來了。而解決這些問題需要在地址上添加一些屬性，也就是說其地址應該還是高於32位的。這時候有體現了分段機制的作用。

關於分頁機制。由分頁機制產生線性地址，加入沒有分頁，這個線性地址就是物理地址。而分頁機制就是把線性地址裝換成物理地址。關於其原因，一方面在進程產生子進程的時候，會復制內存頁，而父子進程無論是代碼數據還是產生的地址都是一樣的，這樣為創建進程提供了便利，可以不必考慮進程在內存中分布的情況而產生地址，至於父子進程的真實物理地址在哪裡，那是mmu（內存控制單元）的問題。另一方面，由於進程不知道真實的物理地址子啊什麼地方，也為操作系統提高了安全性。

❷ linux內核態是實模式還是分頁模式

linux運行在保護模式下，並且在啟動保護模式之前准備好了分頁式內存管理的頁表，在進入保護模式的同時一並開啟了分頁模式（同時置PE和PG位，即or eax,0x80000001）。
需要注意的是不要把保護模式和分頁模式混淆，與實模式相對的是保護模式，與分頁式內存管理相對的是分段式內存管理；當然，也有兩者結合的段頁式。

❸ linux內核參與分頁嗎

參與吧！(答案非常不準確，僅供參考)
頁式管理用以將線性地址轉化成物理地址，並對訪問許可權進行檢查。每個頁面都是一個大小為4KB的連續空間，並按4KB對齊。從80386開始，Intel處理器開始支持頁式管理，CR0寄存器的PG標志位用來表示是否支持分頁。
1、標准分頁
i386採用二級分頁，其線性地址的結構如下：
Dir
Page
Offset
其中，Dir有10位，表示頁表目錄項的下標，指向一個頁表；Page有10位，表示一個具體頁表中的目錄項的下標，指向一個物理頁面；Offset有12位，表示在物理頁面中的偏移量（單位為位元組）。
i386中，從線性地址到物理地址的映射過程為：
（1）從CR3寄存器中取得頁目錄（頁目錄中包含1024條記錄，每個記錄4位元組，正好為4KB，佔用一個頁面）的基地址；
（2）以線性地址中的Dir為下標，從目錄中取出相應頁表的基地址；
（3）以線性地址中的Page為下標，從頁表中取出相應的頁面描述結構；
（4）將頁面描述符中的基地址與線性地址中的Offset偏移量相加，獲得實際的物理地址。
2、頁描述表項
在i386中，頁目錄和頁表的結構相同，頁描述表項的結構如下：
Address
Avail
G
PS
D
A
PCD
PWT
U/S
R/W
P
其中，Address有20位，表示對應頁表或頁的物理地址的高20位（由於頁總是按4KB對其，故低12位恆為0）；Avail有3位，供系統程序員使用；G只有1位，在頁目錄項中表示該頁是否為全局頁，在頁表項中忽略；PS只有1位，在頁表目錄項中為1表示為4MB的頁，為0表示為4KB的頁；D只有1位，在頁表目錄項中未使用，在頁表項中表示該頁是否已被更改；A只有1位，表示該頁是否已被訪問過；PCD只有一位，表示該項是否禁止被緩存；PWT只有一位，為1表示使用write-through緩存策略，0表示使用write-back緩存策略；U/S只有一位，為1表示訪問該頁是否可以在用戶態下訪問；R/W只有一位，表示該項是否可寫；P只有1位，表示該項是否在內存中。
如果要使用4MB的擴展分頁，則要求CR4寄存器中的PSE標志被置1。此時，系統僅採用一級分頁策略，線性地址前10位為頁表項，後22位為偏移量，且頁按4MB對齊，頁描述表項中Address僅有高10位有效。
3、物理地址擴展（PAE）分頁機制
從Pentium Pro開始，Intel處理器的地址匯流排寬度增加到了36位，共支持訪問64GB的內存。同時，Intel提供了PAE和頁大小擴展（PSE-36）兩種機制用以將32位的線性地址轉化成36位的物理地址。其中，後者從Pentium III開始提供，且未在Linux內核中使用。
要啟用PAE機制必須將CR4寄存器中的PAE標志置位。PAE啟用後，處理器會對分頁機製做如下更改：
（1）將64GB的內存空間劃分成2^24個不同頁面，頁表項的體積擴展為64位，物理地址域擴展為24位；
（2）引入新的最高一級頁表，稱為頁目錄指針表（PDPT），其中包含4個64位的項；
（3）CR3寄存器中包含27位的PDPT的高位地址（其低5位地址為0）；
（4）當將線性地址映射到4KB的頁面時，CR3由高位到低位依次為2位PDPT索引，Array位頁目錄索引，Array位頁表索引，12位頁內偏移；當將線性地址映射到4KB的頁面時，CR3由高位到低位依次為2位PDPT索引，Array位頁目錄索引，21位頁內偏移。
但是，PAE機制並未增大單個進程能夠訪問的地址空間，僅僅將內核能夠訪問的地址空間增加到了64GB。
4、Linux內核中的分頁
Linux內核對分頁機制的依賴性很強，其使用一種適合32位和64位結構的通用分頁模型，該模型使用四級分頁，即頁全局目錄、頁上層目錄、頁中層目錄和頁表。
對於不同的體系結構，Linux採用的四級頁表目錄的大小有所不同：對於i386而言，僅採用二級頁表，即頁上層目錄和頁中層目錄長度為0；對於啟用PAE的i386，採用了三級頁表，即頁上層目錄長度為0；對於64位體系結構，可以採用三級或四級頁表，具體選擇由硬體決定。
linux內核中沒有分頁內存嗎？是的，沒有，那麼windows的內核為何就有呢？畢竟不是一個家族不好做全方位的評判，我的結論就是linux上的任何的程序只將內核作為一個平台而不依賴內核。這個事實的結果就是在linux內核中不能分配過大的內存，linux內核中唯一可以分配大內存的地方就是vmalloc區域，僅僅放鬆了對物理內存連續的限制，在vmalloc中分配內存只要求虛擬內存連續，並且事實上最多隻能分配128M的內存，這是linux內核中最寬松的限制了。

在linux中，一切功能都可以由用戶空間應用程序來解決，就連殺毒程序也不例外，這是因為linux有強大的安全機制，單點驗證機制，只要linux保證任何用戶不能隨意su到root許可權就可以了，這事實上就是一個消除一切漏洞的行為，只要操作系統安全機制沒有漏洞，只要內核沒有漏洞，那麼一切惡意程序的得逞完全歸結於該惡意程序所利用的用戶空間應用程序設計的不足，而且這件事在linux看來，內核完全沒有必要過問，正如一個國家的機關只認百姓的請求以及該請求的代理許可權，只要認證通過就給與服務而不再對別的情況加以過問，linux只是一個服務者罷了，它不喜歡任何額外的機制要靠內核來完成，也就是說任何用戶都不要隨意動不動就用內核實現一個機制，只要在用戶空間實現就好了。

看看windows下的殺毒程序這一簡單的使用內核來完成的程序，正是由於windows不能保證復雜但是薄弱的用戶空間機制都是安全的，才會動用內核來實現更高級別的安全管理，它沒有linux的那種簡單但是可以信賴的單點驗證機制。正如微軟建議的那樣，在沒有別的辦法的時候請實現一個驅動程序，在DriverEntry中完成一切。既然微軟會建議程序員編寫內核驅動，那麼微軟的操作系統當然也把內核空間的開發開放給了程序員，於是DDK成了很大一部分人最後的救命稻草，既然將內核驅動的開發開放給了程序員，那麼如何使用內存就不應該有任何限制，再者windows希望用一種簡單一致的機制管理所有的不管是用戶空間還是內核空間的內存，於是內核空間的內存管理和用戶空間的內存管理大體上沒有區別，都可以使用分頁內存，說一句可能讓windows的粉絲不願意聽的話：我們windows實現的不是很安全，所以你們可以用內核這個最高級別的執行緒以權勢壓人。反觀linux，開源的linux難道沒有將內核開放給程序員嗎？不，絕對的開放，看看lkml的熱鬧程度吧！但是不同的是，linux下開發內核是完全為了內核本身的機制擴展而不涉及任何用戶策略，linux的內核和用戶應用分得比較開，不信你去內核郵件列表去問一個應用的問題，看看有沒有人罵。

❹ elasticsearch使用中的問題

目前主要通過插件的形式來控制：
常用的插件主要包括：elasticsearch-http-basic，search-guard，shield

配置名 默認值 說明
http.basic.enabled true 開關，開啟會接管全部HTTP連接
http.basic.user "admin" 賬號
http.basic.password "admin_pw" 密碼
http.basic.ipwhitelist ["localhost", "127.0.0.1"] 白名單內的ip訪問不需要通過賬號和密碼，支持ip和主機名，不支持ip區間或正則
http.basic.trusted_proxy_chains [] 信任代理列表
http.basic.log false 把無授權的訪問事件添加到ES的日誌
http.basic.xforward "" 記載代理路徑的header欄位名

第二步：shutdown你要升級的節點

第三步：升級重啟該節點，並確認該節點重新加入到了集群中
第四步：重復2-3步，升級重啟其它要升級的節點。
第五步：重啟啟動集群的shard均衡

1、內存優化
在bin/elasticsearch.in.sh中進行配置
修改配置項為盡量大的內存：
ES_MIN_MEM=8g
ES_MAX_MEM=8g
兩者最好改成一樣的，否則容易引發長時間GC（stop-the-world）

elasticsearch默認使用的GC是CMS GC
如果你的內存大小超過6G，CMS是不給力的，容易出現stop-the-world
建議使用G1 GC
注釋掉：
java_OPTS=」$JAVA_OPTS -XX:+UseParNewGC」
JAVA_OPTS=」$JAVA_OPTS -XX:+UseConcMarkSweepGC」

JAVA_OPTS=」$JAVA_OPTS -XX:=75″
JAVA_OPTS=」$JAVA_OPTS -XX:+UseCMSInitiatingOccupancyOnly」
修改為：
JAVA_OPTS=」$JAVA_OPTS -XX:+UseG1GC」
JAVA_OPTS=」$JAVA_OPTS -XX:MaxGCPauseMillis=200″

如果G1 GC優點是減少stop-the-world在幾率，但是CPU佔有率高。
需要更優化的性能，你可以參考
http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/index.html

2、合理配置主節點和數據節點
配置文件：conf/elasticsearch.yaml
node.master: true
node.data: true

3、設置合理的刷新時間
建立的索引，不會立馬查到，這是為什麼elasticsearch為near-real-time的原因
需要配置index.refresh_interval參數，默認是1s。
你可以像
http://zhaoyanblog.com/archives/299.html
文件中一樣，調用介面配置
也可以直接寫到conf/elasticsearch.yaml文件中
index.refresh_interval：1s
這樣所有新建的索引都使用這個刷新頻率。

小貼士1：規劃索引、分片 以及集群增長情況

ES使得創建大量索引和超大量分片非常地容易，但更重要的是理解每個索引和分片都是一筆開銷。如果擁有太多的索引或分片，單單是管理負荷就會影響到ES集群的性能，潛在地也會影響到可用性方面。這里我們專注於管理負荷，但運行大量的索引/分片依然會非常顯著地影響到索引和檢索性能。

我們發現影響管理負荷的最大因素是集群狀態數據的大小，因為它包含了集群中每個索引的所有mapping數據。我們曾經一度有單個集群擁有超過900MB的集群狀態數據。該集群雖然在運行但並不可用。

讓我們通過一些數據來了解到底發生了什麼 。。。。。。

假如有一個索引包含50k的mapping數據（我們當時是有700個欄位）。如果每小時生成一個索引，那麼每天將增加24 x 50k的集群狀態數據，或者1.2MB。如果需要在系統中保留一年的數據，那麼集群狀態數據將高達438MB（以及8670個索引，43800個分片）。如果與每天一個索引（18.25MB，365個索引，1825個分片）作比較，會看到每小時的索引策略將會是一個完全不同的境況。

幸運的是，一旦系統中有一些真實數據的話，實際上非常容易做這些預測。我們應當能夠看到集群必須處理多少狀態數據和多少索引/分片。在上到生產環境之前真的應該演練一下，以便防止凌晨3:00收到集群掛掉的電話告警。
小貼士3: 內存設置

Linux把它的物理RAM分成多個內存塊，稱之為分頁。內存交換（swapping）是這樣一個過程，它把內存分頁復制到預先設定的叫做交換區的硬碟空間上，以此釋放內存分頁。物理內存和交換區加起來的大小就是虛擬內存的可用額度。

內存交換有個缺點，跟內存比起來硬碟非常慢。內存的讀寫速度以納秒來計算，而硬碟是以毫秒來計算，所以訪問硬碟比訪問內存要慢幾萬倍。交換次數越多，進程就越慢，所以應該不惜一切代價避免內存交換的發生。

ES的mlockall屬性允許ES節點不交換內存。（注意只有Linux/Unix系統可設置。）這個屬性可以在yaml文件中設置：

bootstrap.mlockall: true
在5.x版本中，已經改成了bootstrap.memory_lock: true.

mlockall默認設置成false，即ES節點允許內存交換。一旦把這個值加到屬性文件中，需要重啟ES節點才可生效。可通過以下方式來確定該值是否設置正確：

curl http://localhost:9200/_nodes/process?pretty
如果你正在設置這個屬性，請使用-DXmx選項或ES_HEAP_SIZE屬性來確保ES節點分配了足夠的內存。

Elasticsearch默認使用服務發現(Zen discovery)作為集群節點間發現和通信的機制。Azure、EC2和GCE也有使用其他的發現機制。服務發現由discovery.zen.*開頭的一系列屬性控制。

在0.x和1.x版本中同時支持單播和多播，且默認是多播。所以要在這些版本的ES中使用單播，需要設置屬性discovery.zen.ping.multicast.enabled為false。

從2.0開始往後服務發現就僅支持單播了。

首先需要使用屬性discovery.zen.ping.unicast.hosts指定一組通信主機。方便起見，在集群中的所有主機上為該屬性設置相同的值，使用集群節點的名稱來定義主機列表。

屬性discovery.zen.minimum_master_nodes決定了有資格作為master的節點的最小數量，即一個應當「看見」集群范圍內運作的節點。如果集群中有2個以上節點，建議設置該值為大於1。一種計算方法是，假設集群中的節點數量為N，那麼該屬性應該設置為N/2+1。
初步判斷該設置可以有效防止腦裂問題

小貼士5：當心DELETE _all

必須要了解的一點是，ES的DELETE API允許用戶僅僅通過一個請求來刪除索引，支持使用通配符，甚至可以使用_all作為索引名來代表所有索引。例如:

curl -XDELETE 『 http://localhost:9200/*/ 』
這個特性非常有用，但也非常危險，特別是在生產環境中。在我們的所有集群中，已通過設置action.destructive_requires_name:true來禁用了它。

這項配置在1.0版本中開始引用，並取代了0.90版本中使用的配置屬性disable_delete_all_indices。

小貼士6：使用Doc Values

2.0及以上版本默認開啟Doc Values特性，但在更早的ES版本中必須顯式地設置。當進行大規模的排序和聚合操作時，Doc Values相比普通屬性有著明顯的優勢。本質上是將ES轉換成一個列式存儲，從而使ES的許多分析類特性在性能上遠超預期。

為了一探究竟，我們可以在ES里比較一下Doc Values和普通屬性。

當使用一個普通屬性去排序或聚合時，該屬性會被載入到屬性數據緩存中。一個屬性首次被緩存時，ES必須分配足夠大的堆空間，以便能保存每一個值，然後使用每個文檔的值逐步填充。這個過程可能會耗費一些時間，因為可能需要從磁碟讀取他們的值。一旦這個過程完成，這些數據的任何相關操作都將使用這份緩存數據，並且會很快。如果嘗試填充太多的屬性到緩存，一些屬性將被回收，隨後再次使用到這些屬性時將會強制它們重新被載入到緩存，且同樣有啟動開銷。為了更加高效，人們會想到最小化或淘汰，這意味著我們的屬性數量將受限於此種方式下的緩存大小。

相比之下，Doc Values屬性使用基於硬碟的數據結構，且能被內存映射到進程空間，因此不影響堆使用，同時提供實質上與屬性數據緩存一樣的性能。當這些屬性首次從硬碟讀取數據時仍然會有較小的啟動開銷，但這會由操作系統緩存去處理，所以只有真正需要的數據會被實際讀取。

Doc Values因此最小化了堆的使用（因為垃圾收集），並發揮了操作系統文件緩存的優勢，從而可進一步最小化磁碟讀操作的壓力。

❺ Linux下如何釋放內存，swap分區滿了怎麼辦

swap的作用可簡單描述為:
當內存不夠用時,將存儲器中的數據塊從DRAM移到swap的磁碟空間中,以釋放更多的空間給當前進程使用.
當再次需要那些數據時,就可以將swap磁碟中的數據重新移到內存,而將那些不用的數據塊從內存移到swap中.
2)數據從內存移動交換區的行為被稱為頁面調用,發生在後台的頁面調用沒有來自應用程序的干涉.
3)swap空間是分頁的,每一頁的大小和內存頁的大小一樣.
4)並不是一定要給每個系統劃分SWAP,比如大多數的嵌入式就沒有swap.

##在執行以上操作以後，查看你的swap分區還是滿了，你首先查看一下你實際的內存剩多少空間，然後在查看自己的swap空間用了多少，首先提前保證實際剩餘的內存比你的swap的內存的空間要大，然後執行一下操作，否則會宕機的！
首先我們停掉swap分區，查看swap分區
swapon -s 會查看到你的swap分區是掛在哪裡！
然後比如說我的是掛到/dev/sda2
swapoff /dev/sda2
停止是需要一段時間的，因為他會把內存釋放到實際內存當中，
然後在啟動我們的swap分區
swapon -a
我們的swap分區內存已經成功釋放到了實際內存當中！

❻ linux內存分頁分段地址轉換由什麼實現

分頁所完全是系統實現，咱們看不到，分段是用戶程序決定到，分頁中用到了頁表和快表，！

❼ linux中使用什麼函數可以獲取操作系統下內存分頁的大小

system（執行shell命令）相關函數fork，execve，waitpid，popen表頭文件#include定義函數intsystem(constchar*string);函數說明system()會調用fork()產生子進程，由子進程來調用/bin/sh-cstring來執行參數string字元串所代表的命令，此命令執行完後隨即返回原調用的進程。在調用system()期間SIGCHLD信號會被暫時擱置，SIGINT和SIGQUIT信號則會被忽略。返回值如果system()在調用/bin/sh時失敗則返回127，其他失敗原因返回-1。若參數string為空指針(NULL)，則返回非零值。如果system()調用成功則最後會返回執行shell命令後的返回值，但是此返回值也有可能為system()調用/bin/sh失敗所返回的127，因此最好能再檢查errno來確認執行成功。附加說明在編寫具有SUID/SGID許可權的程序時請勿使用system()，system()會繼承環境變數，通過環境變數可能會造成系統安全的問題。範例#includemain(){system(「ls-al/etc/passwd/etc/shadow」);}執行-rw-r--r--1rootroot705Sep313:52/etc/passwd-r---------1rootroot572Sep215:34/etc/shadow

❽ linux分頁一塊多大

linux中一塊的容量為4KB

❾ linux中多級分頁的重點是什麼

"重點"是」point「的意思嗎？
使用多級頁表的point在於節省頁表本身的體積。尤其是在虛擬地址64bit的情況下，物理內存一般遠小於2^64位元組。如果用一級頁表的話，假設頁面大小4KB = 2^12B，題主自己可以算算，有2^52個頁表。而用多級頁表，就可以只有一個頂級頁表，二級三級頁表可以很「稀疏」（可以理解為「少」），這樣就大大減少了頁表個數。

❿ linux分頁機制二級頁表問題

linux下的分段分頁機制將一個邏輯地址轉換到物理地址的問題？？？？？
一個邏輯地址經過分段後得到的是線性地址，我挺郁悶的這個線性地址到底如何得到的？？？應為linux的線性地址是個32位的地址，高10為保存目錄項，中間10位保存頁表項，然後低12為對應物理頁偏移地址。。。。然而這個邏輯地址是經過選擇子選出來的段基址，加上段內偏移，出來確實是個32位地址。。。似乎這個中間的步驟被屏蔽了是吧？？？我想知道這裡面是如果把邏輯地址轉換成這個分成三個部分索引的線性地址！前面是段基址然後段偏移就出來個線性地址這叫我無法接受，刨根究底！求助。。。。求助！
【分頁機制對應用程序，操作系統本身的程序都是有作用的。】

這是問題問的比較深入了，弄明白這個問題就要研究操作系統究竟怎麼分配和使用內存。
一般，不管是操作系統還是應用程序都要先分配內存然後才是內存定址和使用，而如何分配不同的系統肯定不同。操作系統種類很多，xp，2000，linux，unix。。。但一般原理還是差不多的。

以linux操作系統為例，
應用程序的內存肯定是由操作系統管的，os按分頁策略給應用程序分配內存。
那麼操作系統呢，這就是你關心的點了？
開機加電的時候linux操作系統內核代碼進入內存，一般這些內存是連續的，但這些內存在後面使用時仍能適用分頁機制去定址，不過是頁面正好是連續的罷了。
而隨著操作系統運行，內核程序也會繼續要求內存，這時候內存管理程序負責分配內存空間，這裡面有不少細節了，暫時就不啰嗦了，但無論怎麼分的，分配後使用這些內存的時候，指令地址都會以分頁機制進行定址找到分配的內存。
所以，分頁機制是整個系統的內存定址機制，對應用程序和操作系統本身都啟作用。