1. 程式人生 > >記錄一次Centos磁碟空間佔滿的解決辦法

記錄一次Centos磁碟空間佔滿的解決辦法

解決前 磁碟使用情況:
第二塊磁碟使用率達到97%

[root@feng020 ~]# df -l
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/xvda1      20641404 10565932   9026948  54% /
tmpfs            4029028        0   4029028   0% /dev/shm
/dev/xvdb1     103210940 67011820  30956312  97% /hotdata
[root@feng020 ~]# df -l

既然確定了哪塊磁碟佔用率高,那就切換到這塊磁碟檢查一下這塊磁碟的哪個資料夾佔用高,再逐層去查詢

du -h --max-depth=1

可以看出是kehu這個資料夾佔用了72G。現在需要優化的就是這個檔案夾了

[root@feng020 ~]# cd /hotdata
[root@feng020 hotdata]# du -h --max-depth=1
140K    ./temp
12M ./memcached
16K ./run
72G ./kehu
415M    ./soft
87M ./systemlog
20K ./lost+found
11G ./database
163M    ./interface
91G .

查找出kehu這個資料夾下的檔案佔用情況

從下方結果可以看到哪些資料夾比較大,分析後是程式執行的日誌檔案,長期未處理,導致磁碟佔滿。所以找到這些資料夾下的日誌目錄,刪除即可

[root@fengniu020 hotdata]# cd kehu/
[root@fengniu020 kehu]# du -h --max-depth=1

272M    ./fx_niufeecms
301M    ./otocms_one
84M ./dakehu
84M ./flow
580M    ./tuan123
111M    ./zan-6
61M ./weipin
36M ./htdocs
96M ./huayuan
3.4G    ./mongo
66M ./ecar
97M ./u220
204M    ./u223
94M ./pin-10
580M    ./jiayouka_niufeecms.bak20160606
102
M ./bai00 33M ./139keji 88M ./u206 70M ./test_niufee 94M ./u224 93M ./jiangzhong_new 283M ./otocms_new 196M ./weikesoft_oto 2.3G ./paopao ..................

參考連結:

相關推薦

記錄Centos磁碟空間滿解決辦法

解決前 磁碟使用情況: 第二塊磁碟使用率達到97% [root@feng020 ~]# df -l Filesystem 1K-blocks Used Available Use% Mounted on /dev/xvda1 2

centos /dev/vda1磁碟空間滿 隨筆

今天筆者所在的公司維護的後臺管理系統。突然發現系統跑不動了。 開啟伺服器上一看,連按tab鍵補全命令都很困難。關鍵時刻來了,發現原來是磁碟空間滿了。 輸入命令 df -h 看到  /dev/vda1磁碟的使用率是100%。 既然發現是磁碟空間不夠,刪掉一些不要緊的檔案就好了

Linux磁碟空間滿問題定位

在Linux中,當我們使用rm在linux上刪除了大檔案,但是如果有程序打開了這個大檔案,卻沒有關閉這個檔案的控制代碼,那麼linux核心還是不會釋放這個檔案的磁碟空間,最後造成磁碟空間佔用100%,整個系統無法正常執行。這種情況下,通過df和du命令查詢的磁碟空間。 解決步驟: 1

linux 磁碟空間滿解決方法

執行命令 du -sh /* |sort -h 檢視根目錄下所有資料夾所佔用的磁碟空間。/* 是檢視根目錄開始的磁碟空間,  | sort -h 是按照大小排序  137M /root 150M

記錄mysql不能啟動的解決方案

● mariadb.service - MariaDB 10.3.14 database server Loaded: l

記錄XordDos(BillGates)木馬導致Centos kworker執行緒滿CPU資源的解決過程

1.問題現象 ​ 通過top命令檢視資源佔用發現有大量kworker執行緒佔用CPU資源,如下圖。懷疑是系統問題或平臺程式導致的問題。 2.是否是程式導致的論證過程 ​ 因平臺有兩部分組成socket+web端,考慮可能是兩者中的一個導致的,因此採用以下三種方

記錄刪除大檔案,但磁碟沒有釋放空間的問題

上伺服器檢視/dev/xxx 掛載的/var 快滿了都過了90%,所以需要清理一下日誌檔案了df -h.../dev/xxx xxG xxG 1.0G 93% /var... 去/var/log中檢查到檔案cd /var/logls...-rw-------. 1 root root 26G 10月 20

記錄Oracle VirtualBox 下 Centos 6.5 VM 磁盤擴容

vm磁盤擴容Oracle VirtualBox 創建的 Centos 6.5 VM 默認硬盤大小是8個G(未手工調整),現使用100%,需要擴容。[root@kaola ~]# df -hFilesystem Size Used Avail Use% Mounted o

記錄刪除大文件,但磁盤沒有釋放空間的問題

服務器 restart 啟動 rest 很大的 rep 記錄 -h rsyslogd 上服務器查看/dev/xxx 掛載的/var 快滿了都過了90%,所以需要清理一下日誌文件了df -h.../dev/xxx xxG xxG 1.0G 93% /va

記錄centos下使用gmp的悲傷

      有個作業是需要在linux下做的,並且需要用到gmp這個 library ; 我使用的是虛擬機器centos7。很久沒碰過linux了,忘得差不多了,一點點百度出來的   1、 首先檢查是否已存在gmp庫 (論壇:https://b

運維之記錄磁碟修復

前言 從15年初把筆記本的作業系統從windows換成Ubuntu14.04,已經有3年了,雖然只有瀏覽器。但是學習效果非常好,年初自動升級到了Ubuntu16.04。上個月系統啟動之後無法進入桌面,因為工作忙一直放放著。今天終於修復好了。 步驟 1. 通過sudo fdi

修復磁碟記錄 (ext4 mount: wrong fs type, bad option, bad superblock)

$ sudo e2fsck -f /dev/sdb1 e2fsck 1.41.4 (27-Jan-2009) e2fsck: Attempt to read block from filesystem

記錄記錄超長”

har 語句 類型 執行 如果 可能 事情 縮小 百度 Jdbc報錯“記錄超長”,百度一下推測可能是因為SQL過長導致;但是後來經過老杜指點,發現原來是因為字段(varchar 8000)超長導致; 解決問題的套路: 1. 首先在Sql的客戶端上執行代碼;如果不錯,說明還是

[邏輯漏洞]記錄挖洞

9.png 列表 一次 查詢 urn 找到 ima sting .com 陽光明媚的早上,turn on the PC and 隨意地瀏覽著以往漏洞列表,希望在裏面找到一些遺忘的痕跡。 果然,我發現一個被忽略的漏洞,一個暴露在外網的的一個接口,可以查詢該企業網站是否註冊了的

簡單記錄REDO文件損壞報錯 ORA-00333重做日誌讀取塊出錯

clas 後者 利用 實例恢復 poi cancel true cover html 一.故障描寫敘述 首先是實例恢復須要用到的REDO文件損壞 二、解決方法 1.對於非當前REDO或者當前REDO可是無活動事務使用下面CLEAR命令: 用CLEAR命令重建該日誌

記錄配置http跳轉https的過程

http https 網站跳轉 公司最近搞了一個數據運營平臺,這個平臺會以web界面的形式把各個數據展示出來,這個項目是我們一個經理的重點關照項目。把平臺模塊部署完畢並且啟動之後,又把這個平臺服務器的外網IP綁定到alkaid.lechange.com這個域名上,在瀏覽器裏輸入https://al

記錄concurrent mode failure問題排查過程以及解決思路

tails only cnblogs 策略 executor red execute incr run 背景:後臺定時任務腳本每天淩晨5點30會執行一個批量掃庫做業務的邏輯。 gc錯誤日誌: 2017-07-05T05:30:54.408+0800: 518534

記錄MySQL進程崩潰,無法重啟故障排查

not pool function 解決 variables fail data class 緩沖 最近程序在跑著沒幾天,突然訪問不了,查看應用進程都還在。只有數據庫的進程down掉了。於是找到日誌文件看到如下錯誤 2017-07-24 01:58:53 19934 [N

記錄處理https監聽不正確的過程

負載均衡 https 502 nginx 金山雲 今天開發反饋在測試金山雲設備的時候遇到了這樣的一個現象:wget https://funchlscdn.lechange.cn/LCLR/2K02135PAK01979/0/0/20170726085033/dev_201707260850

記錄基於LV塊做存儲介質的KVM擴容過程

kvm擴容 基於lv的kvm擴容 kvm硬盤擴容 從下圖可看出盤已經不夠用了然後到宿主機執行LVM擴展Lv 擴充過程略然後擴容完,在虛擬機上執行fdils –l在宿主機擴容的LV在虛擬機裏已經有容量顯示,但我們的分區仍然沒有被顯示出來還是原來的310G因為這個分區在分時考慮到後期的擴充,所以用了G