swap腳本

Ⅰ linux查看佔用swap的進程腳本

linux查看佔用swap的進程腳本01#!/bin/bash0203##############################################################################04#
腳本功能
：
列出正在佔用swap的進程。05###############################################################################0607echo
-e
PID/t/tSwap/t/tProc_Name0809#
拿出/proc目錄下所有以數字為名的目錄（進程名是數字才是進程，其他如sys,net等存放的是其他信息）10for
pid
in
`ls
-l
/proc
|
grep
^d
|
awk
'{
print
$9
}'|
grep
-v
[^0-9]`11do12
#
讓進程釋放swap的方法只有一個：就是重啟該進程。或者等其自動釋放。放13
#
如果進程會自動釋放，那麼我們就不會寫腳本來找他了，找他都是因為他沒有自動釋放。14
#
所以我們要列出佔用swap並需要重啟的進程，但是init這個進程是系統里所有進程的祖先進程15
#
重啟init進程意味著重啟系統，這是萬萬不可以的，所以就不必檢測他了，以免對系統造成影響。16
if
[
$pid
-eq
1
];then
continue;fi17
grep
-q
Swap
/proc/$pid/smaps
2>/dev/null18
if
[
$?
-eq
0
];then19
swap=$(grep
Swap
/proc/$pid/smaps
/20
|
gawk
'{
sum+=$2;}
END{
print
sum
}')21
proc_name=$(ps
aux
|
grep
-w
$pid
|
grep
-v
grep
/22
|
awk
'{
for(i=11;i<=NF;i++){
printf(%s
,$i);
}}')23
if
[
$swap
-gt
0
];then24
echo
-e
${pid}/t${swap}/t${proc_name}25
fi26
fi27done
|
sort
-k2
-n
|
awk
-F'/t'
'{28
pid[NR]=$1;29
size[NR]=$2;30
name[NR]=$3;31}32END{33
for(id=1;id<=length(pid);id++)34
{35
if(size[id]<1024)36
printf(%-10s/t%15sKB/t%s/n,pid[id],size[id],name[id]);37
else
if(size[id]<1048576)38
printf(%-10s/t%15.2fMB/t%s/n,pid[id],size[id]/1024,name[id]);39
else40
printf(%-10s/t%15.2fGB/t%s/n,pid[id],size[id]/1048576,name[id]);41
}42}'

Ⅱ Linux - Swap

首先，swap是硬碟上的一塊空間。

其次，當內存沒有多餘空間的時候，可以將一部分數據交換到swap空間。也就是將內存中的一部分數據放到硬碟中，並釋放內存空間。這樣，釋放出的內存空間就又可以被利用來存儲其他數據了。

這樣，本來只有4G的內存，如果swap有2G的話，可使用的內存可以認為是6G。

但是，硬碟的速度比內存慢太多太多了。因此swap只是對內存的一種補充，是在內存不足時對內存的擴充，但是不能代替內存使用。

內存不足時， 操作系統 會選擇 最久沒被使用的內存數據 ，交換到swap空間。

注意，交換操作是由操作系統來進行的。

系統在什麼情況或條件下才會使用Swap分區的空間呢？ 其實是Linux通過一個參數swappiness來控制的。當然還涉及到復雜的演算法。

這個參數值可為 0-100，控制系統 swap 的使用程度。

0告訴內核盡可能的不要將內存數據移到swap中，也即只有在迫不得已的情況下才這么做，而100告訴內核只要有可能，盡量的將內存中不常訪問的數據移到swap中。默認值為 60。注意：這個只是一個權值，不是一個百分比值，涉及到系統內核復雜的演算法

查看當前系統中swappiness的值

修改當前系統中swappiness的值

上面通過sysctl修改的swappiness值在系統重啟後會失效，要想重啟後繼續生效，需要修改配置文件/etc/sysctl.conf，將下面這行修改成10，如果文件中找不到這行的話，在文件末位加上這行就可以了

既然配置swap對桌面系統有幫助，那麼配置多少大小的swap比較合適呢？下面是ubuntu給出的建議：

Linux下有兩種類型的swap空間，swap分區和swap文件，他們有各自的特點：

swap分區上面由於沒有文件系統，所以相當於內核直接訪問連續的磁碟空間，效率相對要高點，但由於swap分區一般安裝系統時就分配好了了，後期要縮減空間和擴容都很不方便。

swap文件放在指定分區的文件系統裡面，所以有可能受文件系統性能的影響，但據說2.6版本以後的內核可以直接訪問swap文件對應的物理磁碟地址，相當於跳過了文件系統直接訪問磁碟，不過如果swap文件在磁碟上的物理位置不連續時，還是會對性能產生不利影響，但其優點就是靈活，隨時可以增加和移除swap文件。

如果配置有多個swap分區或者文件的話，這里將會有多行，每行代表一個正在被系統使用的swap分區或文件，下面是每個欄位的意思：

並不是swap空間佔用多就一定性能下降，真正影響性能是swap in和out的頻率，頻率越高，對系統的性能影響越大，我們可以通過vmstat命令來查看swap in/out的頻率

在添加swap分區前，首先得有一個空閑的分區，如果是一塊新的磁碟，可以用fdisk來創建一個新的分區用於swap。

添加swap文件就簡單多了，也沒有分區操作那麼有風險。

通過如下命令，能查看所有進程的使用swap情況

查看某個進程swap佔用內存大小腳本：

查看所有進程使用swap情況腳本：

Ⅲ linux下查看哪些進程在佔用swap

1、使用top命令查看當前進程swap佔用
2、使用腳本文件
#!/bin/bash

# Get current swap usage for all running processes
# Erik Ljungstrom 27/05/2011
SUM=0
OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d | egrep "^/proc/[0-9]"` ; do
PID=`echo $DIR | cut -d / -f 3`
PROGNAME=`ps -p $PID -o comm --no-headers`
for SWAP in `grep Swap $DIR/smaps 2>/dev/null| awk '{ print $2 }'`
do
let SUM=$SUM+$SWAP
done
echo "PID=$PID - Swap used: $SUM - ($PROGNAME )"
let OVERALL=$OVERALL+$SUM
SUM=0

done
echo "Overall swap used: $OVERALL"
注意:使用sudo或root許可權來執行該腳本,不然的話非執行用戶的進程的輸出結果為0.

Ⅳ linux下查看swap分區被哪些進程佔用實現腳本

相信很多的系統管理員可能都遇見過這樣的情況，用登錄一台伺服器，使用free命令查看內存，卻發現swap分區被佔用。那麼到底是什麼進程佔用了這部分swap分區呢？

從2.6.16版本的kernel開始，我們可以使用proc文件系統中的smaps來查找這個問題。下邊是一個列出所有進程佔用swap分區情況的列表。可以通過簡單修改就可以用於統計在/proc/$PID/smaps查出。以下是腳本：

復制代碼 代碼如下:

for
i in `cd /proc;ls |grep "^[0-9]"|awk ' $0 >100'` ;do awk
'/Swap:/{a=a+$2}END{print '"$i"',a/1024"M"}' /proc/$i/smaps ;done |sort
-k2nr

Ⅳ lvssyncdaemonswap腳本在哪兒

keepalived.conf內容說明如下

●全局定義塊
1、email通知。作用：有故障，發郵件報警。
2、Lvs負載均衡器標識（lvs_id）。在一個網路內，它應該是唯一的。
3、花括弧「{}」。用來分隔定義塊，因此必須成對出現。如果寫漏了，keepalived運行時，不會得到預期的結果。由於定義塊內存在嵌套關系，因此很容易遺漏結尾處的花括弧，這點要特別注意。
●VRRP定義塊
1、同步vrrp組vrrp_sync_group。作用：確定失敗切換（FailOver）包含的路由實例個數。即在有2個負載均衡器的場景，一旦某個負載均衡器失效，需要自動切換到另外一個負載均衡器的實例是哪些？
2、實例組group。至少包含一個vrrp實例。
3、Vrrp實例vrrp_instance。實例名出自實例組group所包含的那些名字。
(1) 實例狀態state。只有MASTER和BACKUP兩種狀態，並且需要大寫這些單詞。其中MASTER為工作狀態，BACKUP為備用狀態。當 MASTER所在的伺服器失效時，BACKUP所在的系統會自動把它的狀態有BACKUP變換成MASTER；當失效的MASTER所在的系統恢復 時，BACKUP從MASTER恢復到BACKUP狀態。
(2)通信介面interface。對外提供服務的網路介面，如eth0,eth1.當前主流的伺服器都有2個或2個以上的介面，在選擇服務介面時，一定要核實清楚。
(3)lvs_sync_daemon_inteface。 負載均衡器之間的監控介面，類似於HA HeartBeat的心跳線。但它的機制優於Heartbeat，因為它沒有「裂腦」這個問題，它是以優先順序這個 機制來規避這個麻煩的。在DR模式中，lvs_sync_daemon_inteface 與服務介面interface 使用同一個網路介面。
(4)虛擬路由標識virtual_router_id。這個標識是一個數字，並且同一個vrrp實例使用唯一的標識。即同一個vrrp_stance，MASTER和BACKUP的virtual_router_id是一致的，同時在整個vrrp內是唯一的。
(5)優先順序priority。這是一個數字，數值愈大，優先順序越高。在同一個vrrp_instance里，MASTER 的優先順序高於BACKUP。若MASTER的priority值為150，那麼BACKUP的priority只能是140或更小的數值。
(6)同步通知間隔advert_int。MASTER與BACKUP負載均衡器之間同步檢查的時間間隔，單位為秒。
(7)驗證authentication。包含驗證類型和驗證密碼。類型主要有PASS、AH兩種，通常使用的類型為PASS，據說AH使用時有問題。驗證密碼為明文，同一vrrp實例MASTER與BACKUP 使用相同的密碼才能正常通信。
4、 虛擬ip地址virtual_ipaddress。可以有多個地址，每個地址佔一行，不需要指定子網掩碼。注意：這個ip必須與我們在lvs客戶端設定的vip相一致！
●虛擬伺服器virtual_server定義塊
虛擬伺服器定義是keepalived框架最重要的項目了，是keepalived.conf必不可少的部分。
1、虛擬伺服器virtual_server。這個ip來自於vrrp定義塊的第「4」步，後面一個空格，然後加上埠號。定義一個vip，可以實現多個tcp埠的負載均衡功能。
(1)delay_loop。健康檢查時間間隔，單位是秒。
(2)lb_algo。負載均衡調度演算法，互聯網應用常使用wlc或rr。
(3)lb_kind。負載均衡轉發規則。一般包括DR、NAT、TUN3種，在我的方案中，都使用DR的方式。
(4)persistence_timeout。 會話保持時間，單位是秒。這個選項對動態網站很有用處：當用戶從遠程用帳號進行登陸網站時，有了這個會話保持功能，就能把用戶的請求轉發給同一個應用服務 器。在這里，我們來做一個假設，假定現在有一個lvs 環境，使用DR轉發模式，真實伺服器有3個， 負載均衡器不啟用會話保持功能。當用戶第一次訪問的時候，他的訪問請求被負載均衡器轉給某個真實伺服器，這樣他看到一個登陸頁面，第一次訪問完畢；接著他 在登陸框填寫用戶名和密碼，然後提交；這時候，問題就可能出現了---登陸不能成功。因為沒有會話保持，負載均衡器可能會把第2次的請求轉發到其他的伺服器。
(5)轉發協議protocol。一般有tcp和udp兩種。實話說，我還沒嘗試過udp協議類的轉發。
2、真實伺服器real_server，也即伺服器池。Real_server的值包括ip地址和埠號，多個連續的真實ip。
(1)權重weight，權重值是一個數字，數值越大，權重越高。使用不同的權重值的目的在於為不同性能的機器分配不同的負載，性能較好的機器，負載分擔大些；反之，性能差的機器，則分擔較少的負載，這樣就可以合理的利用不同性能的機器資源。
(2)Tcp檢查tcp_check。

第③版更新內容如下:
每台伺服器都有二塊網卡，分別連接內外網；後端的mysql資料庫與web連接採用內網方式，整個網路環境採用內網；
增加了keepalived.conf語法內容；
刪除了lvs.sh腳本內容，直接讓keepalived內容更直接明了；
lvs主從機上的keepalived.conf文件我直接從生產伺服器上download下來了，可方便大家使用。

※值得注意的是：
1、你必須向你的伺服器所在機房IDC多申請一個IP供VIP使用；多關注/var/log/messages和ipvsadm -ln，利用其有效信息排錯。
2、伺服器的iptables、Selinux均關閉；在生產環境中，我就遇到了iptables的NAT轉發問題，導致了lvs失敗。
3、 keepalived的啟動過程並不會對配置文件進行語法檢查，就算沒有配置文件，keepalived的守護進程照樣能夠被運行起來。在默認狀態下，即 不指定配置文件的位置--keepalived先查找文件/etc/keepalived/keepalived.conf。
4、session的過程默認是以文件的形式存在，在瀏覽器關閉或重啟時刪除；會話保持我建議寫成120秒，如果這個值設置得不合理，用戶將得到非常糟糕的訪問效果。
5、 keepalived是lvs的擴展項目，因此它們之間具備良好的兼容性，這點應該是keepalived部署比其他類似工具能更簡潔的原因 吧，lvs+keepalived目前是一個應用於生產環境的成熟架構，實現了真正意義上的負載均衡高可用，尤其適用於bbs和blog(它們均是訪問頻 繁，用戶量大的對象)，建議熟練掌握。

LVS 演算法說明

LVS的常見八種調度演算法：
一:輪叫調度（Round-Robin Scheling）

輪叫調度（Round Robin Scheling）演算法就是以輪叫的方式依次將請求調度不同的伺服器，即每次調度執行i = (i + 1) mod n，並選出第i台伺服器。演算法的優點是其簡潔性，它無需記錄當前所有連接的狀態，所以它是一種無狀態調度。

二:加權輪叫調度（Weighted Round-Robin Scheling）

加權輪叫調度 （Weighted Round-Robin Scheling）演算法可以解決伺服器間性能不一的情況，它用相應的權值表示伺服器的處理性能，伺服器的預設權值為1。假設伺服器A的權值為1，B的權值為2，則表示伺服器B的處理性能是A的兩倍。加權輪叫調度演算法是按權值的高低和輪叫方式分配請求到各伺服器。權值高的伺服器先收到的連接，權值高的伺服器比權值低的伺服器處理更多的連接，相同權值的伺服器處理相同數目的連接數。

三:最小連接調度（Least-Connection Scheling）

最 小連接調度（Least- Connection Scheling）演算法是把新的連接請求分配到當前連接數最小的伺服器。最小連接調度是一種動態調 度演算法，它通過伺服器當前所活躍的連接數來估計伺服器的負載情況。調度器需要記錄各個伺服器已建立連接的數目，當一個請求被調度到某台伺服器，其連接數加1；當連接中止或超時，其連接數減一。
四:加權最小連接調度（Weighted Least-Connection Scheling）

加權最小連接調 度（Weighted Least-Connection Scheling）演算法是最小連接調度的超集，各個伺服器用相應的權值表示其處理性能。伺服器的預設權值為1，系統管理員可以動態地設置伺服器的權值。加權最小連接調度在調度新連接時盡可能使伺服器的已建立連接數和其權值成比例。

五:基於局部性的最少鏈接（Locality-Based Least Connections Scheling）

基 於局部性的最少鏈接調度（Locality-Based Least Connections Scheling，以下簡稱為LBLC）演算法是針對請 求報文的目標IP地址的負載均衡調度，目前主要用於Cache集群系統，因為在Cache集群中客戶請求報文的目標IP地址是變化的。這里假設任何後端服 務器都可以處理任一請求，演算法的設計目標是在伺服器的負載基本平衡情況下，將相同目標IP地址的請求調度到同一台伺服器，來提高各台伺服器的訪問局部性和 主存Cache命中率，從而整個集群系統的處理能力。LBLC調度演算法先根據請求的目標IP地址找出該目標IP地址最近使用的伺服器，若該伺服器是可用的 且沒有超載，將請求發送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處於其一半的工作負載，則用「最少鏈接」的原則選出一個可用的伺服器，將 請求發送到該伺服器。

六: 帶復制的基於局部性最少鏈接（Locality-Based Least Connections with Replication Scheling）

帶 復制的基於局部性最少鏈接調度（Locality- Based Least Connections with Replication Scheling，以下簡稱為LBLCR）演算法也是針對目標 IP地址的負載均衡，目前主要用於Cache集群系統。它與LBLC演算法的不同之處是它要維護從一個目標IP地址到一組伺服器的映射，而LBLC演算法維護 從一個目標IP地址到一台伺服器的映射。對於一個「熱門」站點的服務請求，一台Cache 伺服器可能會忙不過來處理這些請求。這時，LBLC調度演算法會 從所有的Cache伺服器中按「最小連接」原則選出一台Cache伺服器，映射該「熱門」站點到這台Cache伺服器，很快這台Cache伺服器也會超 載，就會重復上述過程選出新的Cache伺服器。這樣，可能會導致該「熱門」站點的映像會出現在所有的Cache伺服器上，降低了Cache伺服器的使用 效率。LBLCR調度演算法將「熱門」站點映射到一組Cache伺服器（伺服器集合），當該「熱門」站點的請求負載增加時，會增加集合里的Cache服務 器，來處理不斷增長的負載；當該「熱門」站點的請求負載降低時，會減少集合里的Cache伺服器數目。這樣，該「熱門」站點的映像不太可能出現在所有的 Cache伺服器上，從而提供Cache集群系統的使用效率。LBLCR演算法先根據請求的目標IP 地址找出該目標IP地址對應的伺服器組；按「最小連 接」原則從該伺服器組中選出一台伺服器，若伺服器沒有超載，將請求發送到該伺服器；若伺服器超載；則按 「最小連接」原則從整個集群中選出一台伺服器，將 該伺服器加入到伺服器組中，將請求發送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除，以降低復制的程度。

七:目標地址散列調度（Destination Hashing Scheling）

目 標地址散列調度 （Destination Hashing Scheling）演算法也是針對目標IP地址的負載均衡，但它是一種靜態映射演算法，通過 一個散列（Hash）函數將一個目標IP地址映射到一台伺服器。目標地址散列調度演算法先根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分 配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。

八:源地址散列調度（Source Hashing Scheling）

源 地址散列調度（Source Hashing Scheling）演算法正好與目標地址散列調度演算法相反，它根據請求的源IP地址，作為散列鍵 （Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。它採用的散列函數與目標地址 散列調度演算法的相同。它的演算法流程與目標地址散列調度演算法的基本相似，除了將請求的目標IP地址換成請求的源IP地址，所以這里不一一敘述。在實際應用 中，源地址散列調度和目標地址散列調度可以結合使用在防火牆集群中，它們可以保證整個系統的唯一出入口。