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

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

第一：常見問題解決集錦

    1.shell腳本不執(zhí)行
    問題：某天研發(fā)某同事找我說幫他看看他寫的shell腳本，死活不執(zhí)行，報錯。我看了下，腳本很簡單，也沒有常規(guī)性的錯誤，報“:badinterpreter:Nosuchfileordirectory”錯。
    看這錯，我就問他是不是在windows下編寫的腳本，然后在上傳到linux服務器的……果然。
    原因：在DOS/windows里，文本文件的換行符為rn，而在*nix系統(tǒng)里則為n，所以DOS/Windows里編輯過的文本文件到了*nix里，每一行都多了個^M。
    解決：
    1）重新在linux下編寫腳本；
    2）vi:%s/r//g:%s/^M//g（^M輸入用Ctrl+v,Ctrl+m）
    附：sh-x腳本文件名，可以單步執(zhí)行并回顯結(jié)果，有助于排查復雜腳本問題。

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

    問題：
    /var/spool/clientmqueue目錄占用空間超過100G
    原因：
    cron中執(zhí)行的程序有輸出內(nèi)容，輸出內(nèi)容會以郵件形式發(fā)給cron的用戶，而sendmail沒有啟動所以就產(chǎn)生了/var/spool/clientmqueue目錄下的那些文件，日積月累可能撐破磁盤。
    解決：
    1）直接手動刪除：ls|xargsrm-f；
    2）徹底解決：在cron的自動執(zhí)行語句后加上>/dev/null2>&1

    3.telnet很慢/ssh很慢
    問題：
    某天研發(fā)某同事說10.50訪問10.52memcached服務異常，讓我們檢查下看網(wǎng)絡/服務/系統(tǒng)是否有異常。檢查發(fā)現(xiàn)系統(tǒng)正常，服務正常，10.50ping10.52也正常，但10.50telnet10.52很慢。同時發(fā)現(xiàn)該機器的namesever是不起作用的。
    原因：
    becauseyourPCdoesn’tdoareverseDNSlookuponyourIPthen…whenyoutelnet/ftpintoyourlinuxbox,it’lldoadnslookuponyou。
    解決：
    1)修改/etc/hosts使hostname和ip對應；
    2）在/etc/resolv.conf注釋掉nameserver或者找一個“活的”nameserver。

    4.Read-onlyfilesystem
    問題：
    同事在mysql里建表建不成功，提示如下：
    mysql>createtablewosontest(colddname1char(1));
    ERROR1005(HY000):Can’tcreatetable‘wosontest’(errno:30）
    經(jīng)檢查mysql用戶權(quán)限以及相關目錄權(quán)限沒問題；用perror30提示信息為：OSerrorcode30:Read-onlyfilesystem
    可能原因：
    1）文件系統(tǒng)損壞；
    2）磁盤又壞道；
    3）fstab文件配置錯誤，如分區(qū)格式錯誤錯誤(將ntfs寫成了fat)、配置指令拼寫錯誤等。
    解決：
    1）由于是測試機，重啟機器后恢復；
    2）網(wǎng)上說用mount可解決。

    5.文件刪了磁盤空間沒釋放
    問題：
    某天發(fā)現(xiàn)某臺機器df-h已用磁盤空間為90G，而du-sh/*顯示所有使用空間加起來才30G，囧。
    原因：
    可能某人直接用rm刪除某個正在寫的文件，導致文件刪了但磁盤空間沒釋放的問題
    解決：
    1）最簡單重啟系統(tǒng)或者重啟相關服務。
    2）干掉進程
    /usr/sbin/lsof|grepdeleted
    ora25575data33uREG65,654294983680/oradata/DATAPRE/UNDOTBS009.dbf(deleted)
    從lsof的輸出中，我們可以發(fā)現(xiàn)pid為25575的進程持有著以文件描述號（fd）為33打開的文件/oradata/DATAPRE/UNDOTBS009.dbf。在我們找到了這個文件之后可以通過結(jié)束進程的方式來釋放被占用的空間：echo>/proc/25575/fd/33
    3）刪除正在寫的文件一般用cat/dev/null>file

    6.find文件提升性能
    問題：
    在tmp目錄下有大量包含picture_*的臨時文件，每天晚上2:30對一天前的文件進行清理。之前在crontab下跑如下腳本，但是發(fā)現(xiàn)腳本效率很低，每次執(zhí)行時負載猛漲，影響到其他服務。
    #!/bin/sh
    find/tmp-name“picture_*”-mtime+1-execrm-f{};
    原因：
    目錄下有大量文件，用find很耗資源。
    解決：
    #!/bin/sh
    cd/tmp
    time=`date-d“2dayago”“+%b%d”`
    ls-l|grep“picture”|grep“$time”|awk‘{print$NF}’|xargsrm-rf

    7.獲取不了網(wǎng)關mac地址
    問題：
    從2.14到3.65（映射地址2.141）網(wǎng)絡不通，但是從3端的其他機器到3.65網(wǎng)絡OK。
    原因：
    #arp
    AddressHWtypeHWaddressFlagsMaskIface
    192.168.3.254etherincompletCMbond0
    表面現(xiàn)象是機器自動獲取不了網(wǎng)關MAC地址，網(wǎng)絡工程師說是網(wǎng)絡設備的問題，具體不清。
    解決：
    arp綁定，arp-ibond0-s192.168.3.25400:00:5e:00:01:64

    8.http服務無法啟動一例
    問題：某天研發(fā)某同事說網(wǎng)站前端環(huán)境http無法啟動，我上去看了下。報如下錯：
    /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]
    原因：
    1）端口被占用：表面看是7080端口被占用，于是netstat-npl|grep7080看了下發(fā)現(xiàn)7080沒有占用；
    2）在配置文件中重復寫了端口，如果在以下兩個文件同時寫了Listen7080
    /etc/httpd/conf/http.conf
    /etc/httpd/conf.d/t.10086.cn.conf
    解決：
    注釋掉/etc/httpd/conf.d/t.10086.cn.conf的Listen7080，重啟，OK。

    9.toomanyopenfile
    問題：
    報toomanyopenfile錯誤
    解決：
    終極解決方案
    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
    最后重啟機器或者執(zhí)行ulimit-u655345&&ulimit-n65535

    10.ibdata1和mysql-bin致磁盤空間問題
    問題：
    2.51磁盤空間報警，經(jīng)查發(fā)現(xiàn)ibdata1和mysql-bin日志占用空間太多（其中ibdata1超過120G，mysql-bin超過80G）
    原因：
    ibdata1是存儲格式，在INNODB類型數(shù)據(jù)狀態(tài)下，ibdata1用來存儲文件的數(shù)據(jù)和索引，而庫名的文件夾里的那些表文件只是結(jié)構(gòu)而已。
    innodb存儲引擎有兩種表空間的管理方式，分別是：
    1）共享表空間（可拆分為多個小的表空間文件），這個是我們目前多數(shù)數(shù)據(jù)庫使用的方法；
    2）獨立表空間，每一個表有一個獨立的表空間（磁盤文件）
    對于兩種管理方式，各有優(yōu)劣，具體如下：
    ①共享表空間：
    優(yōu)點：可以將表空間分成多個文件存放到不同的磁盤上（表空間文件大小不受表大小的限制，一個表可以分布在不同步的文件上）
    缺點：所有數(shù)據(jù)和索引存放在一個文件中，則隨著數(shù)據(jù)的增加，將會有一個很大的文件，雖然可以把一個大文件分成多個小文件，但是多個表及索引在表空間中混合存儲，這樣如果對于一個表做了大量刪除操作后表空間中將有大量空隙。對于共享表空間管理的方式下，一旦表空間被分配，就不能再回縮了。當出現(xiàn)臨時建索引或是創(chuàng)建一個臨時表的操作表空間擴大后，就是刪除相關的表也沒辦法回縮那部分空間了。
    ②獨立表空間：在配置文件（my.cnf）中設置：innodb_file_per_table
    特點：每個表都有自已獨立的表空間；每個表的數(shù)據(jù)和索引都會存在自已的表空間中。
    優(yōu)點：表空間對應的磁盤空間可以被收回（Droptable操作自動回收表空間，如果對于刪除大量數(shù)據(jù)后的表可以通過:altertabletbl_nameengine=innodb;回縮不用的空間。
    缺點：如果單表增加過大，如超過100G，性能也會受到影響。在這種情況下，如果使用共享表空間可以把文件分開，但有同樣有一個問題，如果訪問的范圍過大同樣會訪問多個文件，一樣會比較慢。如果使用獨立表空間，可以考慮使用分區(qū)表的方法，在一定程度上緩解問題。此外，當啟用獨立表空間模式時，需要合理調(diào)整innodb_open_files參數(shù)的設置。
    解決:
    1）ibdata1數(shù)據(jù)太大：只能通過dump，導出建庫的sql語句，再重建的方法。
    2）mysql-binLog太大：
    ①手動刪除：
    刪除某個日志：mysql>PURGEMASTERLOGSTO‘mysql-bin.010′;
    刪除某天前的日志：mysql>PURGEMASTERLOGSBEFORE’2010-12-2213:00:00′;
    ②在/etc/my.cnf里設置只保存N天的bin-log日志
    expire_logs_days=30//BinaryLog自動刪除的天數(shù)

二、故障排查匯總表