作為linux運(yùn)維，多多少少會(huì)碰見這樣那樣的問題或故障，從中總結(jié)經(jīng)驗(yàn)，查找問題，匯總并分析故障的原因，這是一個(gè)Linux運(yùn)維工程師良好的習(xí)慣。每一次技術(shù)的突破，都經(jīng)歷著苦悶，伴隨著快樂，可我們還是執(zhí)著的繼續(xù)努力，從中也積累了更多的經(jīng)驗(yàn)，這就是實(shí)踐給予我們的豐厚回報(bào)。

[[242899]]

下面匯總了我做項(xiàng)目過程可能出現(xiàn)的故障及解決方法，看看是否與你有共鳴，并對(duì)你有幫助?

***、常見問題解決集錦

1. shell腳本不執(zhí)行

(1) 問題：

某天研發(fā)某同事找我說幫他看看他寫的shell腳本，死活不執(zhí)行，報(bào)錯(cuò)。我看了下，腳本很簡(jiǎn)單，也沒有常規(guī)性的錯(cuò)誤，報(bào)“:badinterpreter:Nosuchfileordirectory”錯(cuò)。

看這錯(cuò)，我就問他是不是在windows下編寫的腳本，然后在上傳到linux服務(wù)器的……果然。

(2) 原因：

在DOS/windows里，文本文件的換行符為rn，而在nix系統(tǒng)里則為n，所以DOS/Windows里編輯過的文本文件到了nix里，每一行都多了個(gè)^M。

(3) 解決：

• 重新在linux下編寫腳本;
• vi:%s/r//g:%s/^M//g(^M輸入用Ctrl+v,Ctrl+m)

附：sh-x腳本文件名，可以單步執(zhí)行并回顯結(jié)果，有助于排查復(fù)雜腳本問題。

2. crontab輸出結(jié)果控制

(1) 問題：

/var/spool/clientmqueue目錄占用空間超過100G

(2) 原因：

cron中執(zhí)行的程序有輸出內(nèi)容，輸出內(nèi)容會(huì)以郵件形式發(fā)給cron的用戶，而sendmail沒有啟動(dòng)所以就產(chǎn)生了/var/spool/clientmqueue目錄下的那些文件，日積月累可能撐破磁盤。

(3) 解決：

• 直接手動(dòng)刪除：ls|xargsrm-f;
• 徹底解決：在cron的自動(dòng)執(zhí)行語句后加上>/dev/2>&1

3. telnet很慢/ssh很慢

(1) 問題：

某天研發(fā)某同事說10.50訪問10.52memcached服務(wù)異常，讓我們檢查下看網(wǎng)絡(luò)/服務(wù)/系統(tǒng)是否有異常。檢查發(fā)現(xiàn)系統(tǒng)正常，服務(wù)正常，10.50ping10.52也正常，但10.50telnet10.52很慢。同時(shí)發(fā)現(xiàn)該機(jī)器的namesever是不起作用的。

(2) 原因：

• becauseyourPCdoesn’tdoareverseDNSlookuponyourIPthen…
• whenyoutelnet/ftpintoyourlinuxbox,it’lldoadnslookuponyou。

(3) 解決：

• 修改/etc/hosts使hostname和ip對(duì)應(yīng);
• 在/etc/resolv.conf注釋掉nameserver或者找一個(gè)“活的”nameserver。

4. Read-onlyfilesystem

(1) 問題：

同事在mysql里建表建不成功，提示如下：

mysql>createtablewosontest(colddname1char(1)); 
ERROR1005(HY000):Can’t create table‘wosontest’(errno:30） 

經(jīng)檢查mysql用戶權(quán)限以及相關(guān)目錄權(quán)限沒問題;用perror30提示信息為：OSerrorcode30:Read-onlyfilesystem

(2) 可能原因：

• 文件系統(tǒng)損壞;
• 磁盤又壞道;
• fstab文件配置錯(cuò)誤，如分區(qū)格式錯(cuò)誤錯(cuò)誤(將ntfs寫成了fat)、配置指令拼寫錯(cuò)誤等。

(3) 解決：

• 由于是測(cè)試機(jī)，重啟機(jī)器后恢復(fù);
• 網(wǎng)上說用mount可解決。

5. 文件刪了磁盤空間沒釋放

(1) 問題：

某天發(fā)現(xiàn)某臺(tái)機(jī)器df-h已用磁盤空間為90G，而du-sh/*顯示所有使用空間加起來才30G，囧。

(2) 原因：

可能某人直接用rm刪除某個(gè)正在寫的文件，導(dǎo)致文件刪了但磁盤空間沒釋放的問題

(3) 解決：

• 最簡(jiǎn)單重啟系統(tǒng)或者重啟相關(guān)服務(wù)。
• 干掉進(jìn)程

/usr/sbin/lsof|grepdeleted 
   ora25575data33uREG65,654294983680/oradata/DAT 

從lsof的輸出中，我們可以發(fā)現(xiàn)pid為25575的進(jìn)程持有著以文件描述號(hào)(fd)為33打開的文件/oradata/DATAPRE/UNDOTBS009.dbf。

在我們找到了這個(gè)文件之后可以通過結(jié)束進(jìn)程的方式來釋放被占用的空間：

echo>/proc/25575/fd/33 

• 刪除正在寫的文件一般用cat/dev/null>file

6. find文件提升性能

(1) 問題：

在tmp目錄下有大量包含picture_*的臨時(shí)文件，每天晚上2:30對(duì)一天前的文件進(jìn)行清理。之前在crontab下跑如下腳本，但是發(fā)現(xiàn)腳本效率很低，每次執(zhí)行時(shí)負(fù)載猛漲，影響到其他服務(wù)。

#!/bin/sh 
find/tmp-name“picture_*”-mtime+1-execrm-f{}; 

(2) 原因：

目錄下有大量文件，用find很耗資源。

(3) 解決：

#!/bin/sh 
cd/tmp 
time=`date-d“2dayago”“+%b%d”` 
ls-l|grep“picture”|grep“$time”|awk‘{print$NF}’|xa 

7. 獲取不了網(wǎng)關(guān)mac地址

(1) 問題：

從2.14到3.65(映射地址2.141)網(wǎng)絡(luò)不通，但是從3端的其他機(jī)器到3.65網(wǎng)絡(luò)OK。

(2) 原因：

#arp 
AddressHWtypeHWaddressFlagsMaskIface 
192.168.3.254etherincompletCMbond0 

表面現(xiàn)象是機(jī)器自動(dòng)獲取不了網(wǎng)關(guān)MAC地址，網(wǎng)絡(luò)工程師說是網(wǎng)絡(luò)設(shè)備的問題，具體不清。

(3) 解決：

arp綁定，arp-ibond0-s192.168.3.25400:00:5e:00:01:64

8. http服務(wù)無法啟動(dòng)一例

(1) 問題：

某天研發(fā)某同事說網(wǎng)站前端環(huán)境http無法啟動(dòng)，我上去看了下。報(bào)如下錯(cuò)：

/etc/init.d/httpdstart 
Startinghttpd:[SatJan2917:49:002011][warn]moduleantibot_moduleisalreadyloaded,skipping 
Useproxyforwardasremoteip:true. 
Antibotexcludepattern:.*.[(js|css|jpg|gif|png)] 
Antibotseedcheckpattern:login 
(98)Addressalreadyinuse:make_sock:couldnotbindtoaddress[::]:7080 
(98)Addressalreadyinuse:make_sock:couldnotbindtoaddress0.0.0.0:7080 
nolisteningsocketsavailable,shuttingdown 
Unabletoopenlog[FAILED] 

(2) 原因：

• 端口被占用：表面看是7080端口被占用，于是netstat-npl|grep7080看了下發(fā)現(xiàn)7080沒有占用;
• 在配置文件中重復(fù)寫了端口，如果在以下兩個(gè)文件同時(shí)寫了Listen7080

/etc/httpd/conf/http.conf 
/etc/httpd/conf.d/t.10086.cn.conf 

(3) 解決：

注釋掉/etc/httpd/conf.d/t.10086.cn.conf的Listen7080，重啟，OK。

9. toomanyopenfile

(1) 問題：

報(bào)toomanyopenfile錯(cuò)誤

(2) 解決：

***解決方案

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 

***重啟機(jī)器或者執(zhí)行：

ulimit-u655345&&ulimit-n65535 

10. ibdata1和mysql-bin致磁盤空間問題

(1) 問題：

2.51磁盤空間報(bào)警，經(jīng)查發(fā)現(xiàn)ibdata1和mysql-bin日志占用空間太多(其中ibdata1超過120G，mysql-bin超過80G)

(2) 原因：

bdata1是存儲(chǔ)格式，在INNODB類型數(shù)據(jù)狀態(tài)下，ibdata1用來存儲(chǔ)文件的數(shù)據(jù)和索引，而庫(kù)名的文件夾里的那些表文件只是結(jié)構(gòu)而已。

innodb存儲(chǔ)引擎有兩種表空間的管理方式，分別是：

• 共享表空間(可拆分為多個(gè)小的表空間文件)，這個(gè)是我們目前多數(shù)數(shù)據(jù)庫(kù)使用的方法;
• 獨(dú)立表空間，每一個(gè)表有一個(gè)獨(dú)立的表空間(磁盤文件)

對(duì)于兩種管理方式，各有優(yōu)劣，具體如下：

① 共享表空間：

優(yōu)點(diǎn)：可以將表空間分成多個(gè)文件存放到不同的磁盤上(表空間文件大小不受表大小的限制，一個(gè)表可以分布在不同步的文件上)

缺點(diǎn)：

• 所有數(shù)據(jù)和索引存放在一個(gè)文件中，則隨著數(shù)據(jù)的增加，將會(huì)有一個(gè)很大的文件，雖然可以把一個(gè)大文件分成多個(gè)小文件，但是多個(gè)表及索引在表空間中混合存儲(chǔ)，這樣如果對(duì)于一個(gè)表做了大量刪除操作后表空間中將有大量空隙。
• 對(duì)于共享表空間管理的方式下，一旦表空間被分配，就不能再回縮了。當(dāng)出現(xiàn)臨時(shí)建索引或是創(chuàng)建一個(gè)臨時(shí)表的操作表空間擴(kuò)大后，就是刪除相關(guān)的表也沒辦法回縮那部分空間了。

②獨(dú)立表空間：

在配置文件(my.cnf)中設(shè)置：

innodb_file_per_table 

特點(diǎn)：每個(gè)表都有自已獨(dú)立的表空間;每個(gè)表的數(shù)據(jù)和索引都會(huì)存在自已的表空間中。

優(yōu)點(diǎn)：表空間對(duì)應(yīng)的磁盤空間可以被收回(Droptable操作自動(dòng)回收表空間，如果對(duì)于刪除大量數(shù)據(jù)后的表可以通過:altertabletbl_nameengine=innodb;回縮不用的空間。

缺點(diǎn)：

• 如果單表增加過大，如超過100G，性能也會(huì)受到影響。在這種情況下，如果使用共享表空間可以把文件分開，但有同樣有一個(gè)問題，如果訪問的范圍過大同樣會(huì)訪問多個(gè)文件，一樣會(huì)比較慢。
• 如果使用獨(dú)立表空間，可以考慮使用分區(qū)表的方法，在一定程度上緩解問題。此外，當(dāng)啟用獨(dú)立表空間模式時(shí)，需要合理調(diào)整innodb_open_files參數(shù)的設(shè)置。

(3) 解決:

①ibdata1數(shù)據(jù)太大：只能通過dump，導(dǎo)出建庫(kù)的sql語句，再重建的方法。

②mysql-binLog太大：

手動(dòng)刪除：

• 刪除某個(gè)日志：

mysql>PURGEMASTERLOGSTO‘mysql-bin.010′; 

• 刪除某天前的日志：

mysql>PURGEMASTERLOGSBEFORE’2010-12-2213:00:00′; 

在/etc/my.cnf里設(shè)置只保存N天的bin-log日志

expire_logs_days=30//BinaryLog自動(dòng)刪除的天數(shù)

二、故障排查匯總表