在近期的實際工作中,遇到過幾次因為磁碟空間滿而導致服務不可用的情況,所以免不了要對系統進行清理。 在最開始的幾次清理過程中,通過刪除一些大日誌檔案可以得到立竿見影的效果,所以就沒怎麼注意;但是在最近一次的清理過程中,發現根目錄的使用率已經到達百分百,但是並沒有在根目錄下發現有什麼大檔案,所以無法僅通過rm -rf ***這種簡單粗暴的方式來解決問題。
說起被刪除檔案的磁碟空間並未釋放問題,還存在乙個與之類似的說法:df、du結果不一致,這兩個問題在很大程度上指的是一回事:即就是被刪除檔案在被執行rm命令時,還有其他程序在操作該檔案;所以該檔案只是被標記為「deleted」,而非立馬被刪除;除非等到操作該檔案的所有程序都結束後該檔案才會被刪除。
俗話說好記性不如賴筆頭,既然知道了原因,那就親自實踐一下,在驗證結論正確與否的同時加深記憶也未嘗不可。
首先執行命令df -h,可以看到當前機器的根目錄的大小為48g,可用空間為35g;
然後在當前使用者目錄(/home/yhyr)下新建乙個資料檔案,為了提公升試驗的效果,這裡生成檔案的大小為1g;資料檔案生成 命令dd if=/dev/zero of=./data_file bs=1m count=1024;然後分別檢視當前目錄的檔案大小資訊du -sh ./*和磁碟的占用情況df -h
可以看到此時相較於之前35g的可用空間,現在已經少了乙個g,符合我們的預期。接下來分別驗證一下有無程序操作下,刪除資料檔案後磁碟空間的使用情況:
場景一:當沒有任何程序操作該資料檔案時,執行rm -f data_file後磁碟空間成功釋放了1g的空間,執行結果如下所示:
場景二:首先通過tail data_file &模擬操作該資料檔案,然後刪除該檔案並檢視磁碟空間的釋放情況:
這樣就可以復現磁碟空間未釋放的情況;然後通過lsof | grep data_file檢視檔案的占用資訊:
通過lsof命令可以看到該檔案被tail程序所占用,對應的程序pid為92489,檔案的路徑即就是當初刪除前檔案的實際路徑,只是目前被標記為deleted;現在通過kill -9 pid命令殺死tail程序後,磁碟空間資訊如下所示:
到這有關如何解決因為程序占用而導致磁碟空間無法釋放的問題應該都已有所了解;因為這個問題看起沒什麼難度,網上有關此問題的描述也要很多,在這裡就不做過多的贅述。接下來基於此次問題的發現和實踐解決過程,更進一步的了解一些有關系統監控基本系統監控命令、程序命令,來提公升問題的排查和定位能力。
面向檔案的命令;通過計算檔案的大小來統計指定目錄磁碟的使用情況;通俗的講就是計算檔案具體的占用空間
常用命令
du -sh 統計當前目錄的總大小面向檔案系統的命令;通過檔案系統獲取分割槽資訊;eg:分割槽大小、使用量、剩餘量、使用率du -sh ./* 檢視當前目錄下各檔案(資料夾)的大小,不統計隱藏檔案(夾)
du -h --max-depth=1 檢視當前目錄下各檔案(夾)的大小【囊括隱藏檔案(夾)】;等價於du -h -d 1
常用命令
df -hlsof(list open file),列出開啟檔案;
方案一:通過ps命令檢視
ps -aux | grep pid
方案二:進入程序目錄檢視
# step 1
cd /proc/pid
# step 2
ls -lt
# cwd表示程序所在的目錄;exe表示程序型別
方案一:lsof -i:pid
方案二:netstat -nlp | grep pid
檔案刪了磁碟空間沒釋放
問題 某天發現某台機器df h已用磁碟空間為90g,而du sh 顯示所有使用空間加起來才30g,囧。原因 可能某人直接用rm刪除某個正在寫的檔案,導致檔案刪了但磁碟空間沒釋放的問題 解決 1 最簡單重啟系統或者重啟相關服務。2 乾掉程序 usr sbin lsof grep deleted ora...
linux擴充套件磁碟空間
利用剩下的自由空間 建立乙個物理分割槽 將這個物理分割槽裝換為物理卷 把這個物理卷新增到要擴充套件的卷組中 然後才能用extend命令擴充套件此卷組中的邏輯卷 1.首先要再建立乙個物理分割槽 使用fdisk dev sda,選擇n來建立乙個新的分割槽比如sda3,主分割槽還是邏輯分割槽對此例子無所謂...
linux檢視磁碟空間
如果要檢視磁碟還剩多少空間,當然是用df的命令了。root localhost df h 檔案 系統 容量 已用 可用 已用 掛載點 dev sda2 14g 11g 2.6g 82 dev sda1 99m 14m 81m 14 boot tmpfs 442m 275m 168m 63 dev s...