9.
問題：
報錯誤
解決：
終極解決方案
echo“”>>/etc/security/limits.conf
echo“*softnproc65535″>>/etc/security/limits.conf
echo“*hardnproc65535″>>/etc/security/limits.conf
echo“*softnofile65535″>>/etc/security/limits.conf
echo“*hardnofile65535″>>/etc/security/limits.conf
echo“”>>/root/.bash_profile
echo“ulimit-n65535″>>/root/.bash_profile
echo“ulimit-u65535″>>/root/.bash_profile
最后重啟機器或者執行-&&-
10.和mysql-bin致磁盤空間問題
問題：
2.51磁盤空間報警，經查發現和mysql-bin日志占用空間太多（其中超過120G，mysql-bin超過80G）
原因：
是存儲格式，在類型數據狀態下，用來存儲文件的數據和索引，而庫名的文件夾里的那些表文件只是結構而已。
存儲引擎有兩種表空間的管理方式，分別是：
1）共享表空間（可拆分為多個小的表空間文件），這個是我們目前多數數據庫使用的方法；
2）獨立表空間，每一個表有一個獨立的表空間（磁盤文件）
對于兩種管理方式，各有優劣，具體如下：
①共享表空間：
優點：可以將表空間分成多個文件存放到不同的磁盤上（表空間文件大小不受表大小的限制，一個表可以分布在不同步的文件上）
缺點：所有數據和索引存放在一個文件中，則隨著數據的增加，將會有一個很大的文件，雖然可以把一個大文件分成多個小文件，但是多個表及索引在表空間中混合存儲，這樣如果對于一個表做了大量刪除操作后表空間中將有大量空隙。對于共享表空間管理的方式下，一旦表空間被分配，就不能再回縮了。當出現臨時建索引或是創建一個臨時表的操作表空間擴大后，就是刪除相關的表也沒辦法回縮那部分空間了。
②獨立表空間：在配置文件（f）中設置：e
特點：每個表都有自已獨立的表空間；每個表的數據和索引都會存在自已的表空間中。
優點：表空間對應的磁盤空間可以被收回（操作自動回收表空間，如果對于刪除大量數據后的表可以通過:gine=;回縮不用的空間。
缺點：如果單表增加過大，如超過100G，性能也會受到影響。在這種情況下，如果使用共享表空間可以把文件分開，但有同樣有一個問題，如果訪問的范圍過大同樣會訪問多個文件，一樣會比較慢。如果使用獨立表空間，可以考慮使用分區表的方法，在一定程度上緩解問題。此外，當啟用獨立表空間模式時，需要合理調整參數的設置。
解決:
1）數據太大：只能通過dump，導出建庫的sql語句，再重建的方法。
2）mysql-太大：
①手動刪除：
刪除某個日志：mysql>‘mysql-bin.010′;
刪除某天前的日志：mysql>E’2010-12-2213:00:00′;
②在/etc/f里設置只保存N天的bin-log日志
=30//自動刪除的天數
二、故障排查匯總表
問題 1：文件系統破壞導致系統無法啟動
root /dev/sda6 a file with ,
check An error the file check
這個錯誤可以看出，操作系統 / dev/sda6 分區文件系統出現了問題，這個問題發生的機率很高，通常引起這個問題的原因主要是系統突然斷電，引起文件系統結構不一致，一般情況下，解決此問題的方法是采用 fsck 命令，進行強制修復。
# umount /dev/sda6
# fsck.ext3 -y /dev/sda6
問題 2：“ list too long” 錯誤與解決方法
# crontab -e
編輯完后保存退出后，報錯 no space left on
根據上面的報錯了解到是磁盤空間滿了，那么首先是檢查磁盤空間，
# df -h
查看到是 / var 磁盤分區空間已經達到 100%，至此定位了問題所在。是 / var 磁盤空間飽滿導致，因為 會在保存時將文件信息寫到 / var 目錄下面，然而這個磁盤沒有空間了，所以報錯。
接著通過命令 du –sh * 命令檢查 / var 目錄下面的所有文件或者目錄的大小，發現 / var/spool/ 目錄占用了 / var 整個分區大小的 90%，那么 / var/spool/ 目錄下的文件都是怎么產生的，能否刪除，基本上都是郵件信息，可以刪除
# rm *
/bin/rm :argument list too long
當在 linux 系統中試圖傳遞太多參數給一個命令時，就會出現 “ list too long” 錯誤，這是 linux 系統一直以來都有的限制，查看這個限制可以通過命令 “ ” 來實現，
# getconf ARG_MAX
# more /etc/issue 查看版本
解決方法：1、
# rm [a-n]* -rf
# rm [o-z]* -rf
2、使用 find 命令來刪除
# find /var/spool/clientmqueue –type f –print –exec rm –f {} ;
3、通過 shell 腳本
#/bin/bash
RM_DIR=’/var/spool/clientmqueue’
cd $RM_DIR
for I in `ls`
do
rm –f $i
done
4、重新編譯內核
需要手動增加內核中分配給命令行參數的頁數，打開 下面的 /linux/.h 文件，找到如下行：
#denfine MAX_ARG_PAGES 32
將 32 改為更大的值，例如 64 或者 128，然后重新編譯內核
問題 3：inode 耗盡導致應用故障
客戶的一臺 數據庫如武器在關機重啟后， 監聽無法啟動，提示報錯 Linux error : No space left on
從輸出信息看出來是因為磁盤耗盡導致監聽無法啟動，因為 在啟動監聽時需要創建監聽日志文件，于是首先查看磁盤空間使用情況
# df -h
從磁盤輸出信息可知，所有的分區磁盤空間都還有剩余不少，而 監聽寫日志的路徑在 / var 分區下，/var 下分區空間足夠。
解決思路：
既然錯誤提示語磁盤空間有關，那就深入研究關于磁盤空間的問題，在 linux 系統中對磁盤空間的占用分為三個部分：第一個是物理磁盤空間，第二個是 inode 節點所占用的磁盤空間，第三個是 linux 用來存放信號量的空間刪除文件后空間沒釋放，而平時接觸較多的是物理磁盤空間。既然不是物理磁盤空間的問題，接著就檢查是否是 inode 節點耗盡的問題，通過執行命令 “df -i” 查看可用的 inode 節點。由輸出結果看出確實是因為 inode 耗盡導致無法寫入文件。
可以通過下面的命令查看某個磁盤分區 inode 的總數
# dumpe2fs -h /dev/sda3 |grep ‘Inode count’
每個 inode 都有一個號碼，操作系統用 inode 號碼來區分不同的文件，通過‘ls -i’命令可以查看文件名對應的 inode 號
如果要查看這個文件更詳細的 inode 信息，可以通過 stat 命令來實現
# stat install.log
解決問題
# find /var/spool/clientmqueue/ -name “*” -exec rm -rf {} ;
問題 4：文件已經刪除，但是空間沒有釋放的原因
運維監控系統發來通知，報告一臺服務器空間滿了，登陸服務器查看刪除文件后空間沒釋放，根分區確實滿了，這里先說一下服務器的一些刪除策略，由于 linux 沒有回收站功能，所以線上服務器上所有要刪除的文件都會先移到系統 / tmp 目錄下，然后定期清除 / tmp 目錄下的數據。這個策略本身沒有什么問題，但是通過檢查發現這臺服務器的系統分區中并沒有單獨劃分 / tmp 分區，這樣 / tmp 下的數據其實占用根分區的空間，既然找到了問題，那么刪除 / tmp 目錄下一些占用空間較大的數據文件即可。
# du -sh /tmp/* | sort -nr |head -3
通過命令發現在 / tmp 目錄下有個 66G 大小的文件 ，這個文件應該是 產生的訪問日志文件，從日志大小來看，應該是很久沒有清理的 日志文件了，基本判定是這個文件導致的根空間爆滿，在確認此文件可以刪除后，執行如下刪除命令，
# rm /tmp/access_Iog
# df -h
從輸出來看，根分區空間仍然沒有釋放，這是怎么回事
一般來說不會出現刪除文件后空間不釋放的情況，但是也存在例外，比如文件進程鎖定，或者有進程一直在向這個文件寫數據，要理解這個問題，就需要知道 linux 下文件的存儲機制和存儲結構。
一個文件在文件系統中存放分為兩個部分：數據部分和指針部分，指針位于文件系統的 meta-data 中，在將數據刪除后，這個指針就從 meta-data 中清除了，而數據部分存儲在磁盤中。在將數據對應的指針從 meta-data 中清除后，文件數據部分占用的空間就可以被覆蓋并寫入新的內容，之所以出現刪除 文件后，空間還沒有釋放，就是因為 httpd 進程還在一直向這個文件寫入內容，導致雖然刪除了 文件，但是由于進程鎖定，文件對應的指針部分并未從 meta-data 中清除，而由于指針并未刪除，系統內核就認為文件并未被刪除，因此通過 df 命令查詢空間并未釋放。
問題排查：
既然有了解決思路，那么接下來看看是否有進程一直在向 文件中寫入數據，這里需要用到 linux 下的 losf 命令，通過這個命令可以獲取一個仍然被應用程序占用的已刪除文件列表
# lsof | grep delete
從輸出可以看出，/tmp/ 文件被進程 httpd 鎖定，而 httpd 進程還一直向這個文件寫入日志數據，最后一列的‘’狀態說明這個日志文件已經被刪除，但是由于進程還在一直向此文件寫入數據，因此空間并未釋放。
解決問題：
到這里問題就基本排查清楚了，解決這一類問題的方法有很多，最簡單的方法就是關閉或者重啟 httpd 進程，當然重啟操作系統也可以。不過這些并不是最好的辦法，對待這種進程不停對文件寫日志的操作，要釋放文件占用的磁盤空間，最好的方法是在線清空這個文件，具體可以通過如下命令完成:
# echo “”>/tmp/access_log
通過這種方法，磁盤空間不但可以馬上釋放，也可以保障進城繼續向文件寫入日志，這種方法經常用于在線清理 //nginx 等 web 服務產生的日志文件。
問題 5：“too many open files” 錯誤與解決方法
問題現象：這是一個基于 java 的 web 應用系統，在后臺添加數據時提示無法添加，于是登陸服務器查看 日志，發現如下異常信息，java.io.: Too many open files
通過這個報錯信息，基本判斷是系統可以用的文件描述符不夠了，由于 服務室系統 www 用戶啟動的，于是以 www 用戶登陸系統，通過 –n 命令查看系統可以打開最大文件描述符的數量，輸出如下：
$ ulimit -n
65535
可以看到這臺服務器設置的最大可以打開的文件描述符已經是 65535 了，這么大的值應該夠用了，但是為什么提示這樣的錯誤呢
解決思路，這個案例涉及 命令的使用
在使用 時，有以下幾種使用方法：
1、 在用戶環境變量中加入
如果用戶使用的是 bash，那么可以在用戶目錄的環境變量文件. 或者. 中加入 “ –u128” 來限制用戶最多可以使用 128 個進程
2、 在應用程序的啟動腳本中加入
如果應用程序是 ，那么可以再 的啟動腳本 .sh 中加入‘ -n 65535’來限制用戶最多可以使用 65535 個文件描述符
3、 直接在 shell 命令終端執行 命令
這種方法的資源限制僅僅在執行命令的終端生效，在退出或者和關閉終端后，設置失效，并且這個設置不影響其他 shell 終端
解決問題：
在了解 知識后，接著上面的案例，既然 設置沒有問題，那么一定是設置沒有生效導致的，接下來檢查下啟動 的 www 用戶環境變量是否添加 限制，檢查后發現，www 用戶并無 限制。于是繼續檢查 啟動腳本 .sh 文件是否添加了 限制，檢查后發現也沒有添加。最后考略是否將限制加到了 .conf 文件中，于是檢查 .conf 文件，操作如下
# cat /etc/security/limits.conf | grep www
www soft nofile 65535
www hard nofile 65535
從輸出可知， 限制加在 .conf 文件中，既然限制已經添加了，配置也沒有什么錯，為何還會報錯，經過思考，判斷只有一種可能，那就是 的啟動時間早于 資源限制的添加時間，于是首先查看下 啟動時間，操作如下
# uptime
Up 283 days
# pgrep -f tomcat
4667
# ps -eo pid,lstart,etime|grep 4667
4667 Sat Jul 6 09;33:39 2013 77-05:26:02
從輸出可以看出，這臺服務器已經有 283 沒有重啟了，而 是在 2013 年 7 月 6 日 9 點啟動的，啟動了將近 77 天，接著繼續看看 .conf 文件的修改時間，
# stat /etc/security/limits.conf
通過 stat 命令清除的看到，.conf 文件最后的修改時間是 2013 年 7 月 12，晚于 啟動時間，清楚問題后，解決問題的方法很簡單，重啟一下 就可以了。
問題 6：Read-only file 錯誤與解決方法
解析：出現這個問題的原因有很多種，可能是文件系統數據塊出現不一致導致的，也可能是磁盤故障造成的，主流 ext3/ext4 文件系統都有很強的自我修復機制，對于簡單的錯誤，文件系統一般都可以自行修復，當遇到致命錯誤無法修復的時候，文件系統為了保證數據一致性和安全，會暫時屏蔽文件系統的寫操作，講文件系統 變為只讀，今兒出現了上面的 “read-only file ” 現象。
手工修復文件系統錯誤的命令式 fsck，在修復文件系統前，最好卸載文件系統所在的磁盤分區
# umount /www/data
Umount : /www/data: device is busy
提示無法卸載，可能是這個磁盤中還有文件對應的進程在運行，檢查如下：
# fuser -m /dev/sdb1
/dev/sdb1: 8800
接著檢查一下 8800 端口對應的什么進程，
# ps -ef |grep 8800
檢查后發現時 沒有關閉，停止
# /usr/local/apache2/bin/apachectl stop
# umount /www/data
# fsck -V -a /dev/sdb1
# mount /dev/sdb1 /www/data
參考鏈接 ：
Linux運維常見故障排查和處理的技巧匯總