聲明：出處-高效運維
第一：常見問題解決集錦
1.shell腳本不執行
問題：
某天研發某同事找我說幫他看看他寫的shell腳本，死活不執行，報錯。我看了下，腳本很簡單，也沒有常規性的錯誤，報“:badinterpreter:Nosuchfileordirectory”錯。
看這錯，我就問他是不是在windows下編寫的腳本，然後在上傳到linux服務器的……果然。
原因：
在DOS/windows裏，文本文件的換行符爲rn，而在nix系統裏則爲n，所以DOS/Windows裏編輯過的文本文件到了nix裏，每一行都多了個^M。
解決：
1）重新在linux下編寫腳本；
2）vi:%s/r//g:%s/^M//g（^M輸入用Ctrl+v,Ctrl+m）
附：sh-x腳本文件名，可以單步執行並回顯結果，有助於排查複雜腳本問題。
2.crontab輸出結果控制
問題：
/var/spool/clientmqueue目錄佔用空間超過100G
原因：
cron中執行的程序有輸出內容，輸出內容會以郵件形式發給cron的用戶，而sendmail沒有啓動所以就產生了/var/spool/clientmqueue目錄下的那些文件，日積月累可能撐破磁盤。
解決：
1）直接手動刪除：ls|xargsrm-f；
2）徹底解決：在cron的自動執行語句後加上>/dev/2>&1
3.telnet很慢/ssh很慢
問題：
某天研發某同事說10.50訪問10.52memcached服務異常，讓我們檢查下看網絡/服務/系統是否有異常。檢查發現系統正常，服務正常，10.50ping10.52也正常，但10.50telnet10.52很慢。同時發現該機器的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’t create table‘wosontest’(errno:30）
經檢查mysql用戶權限以及相關目錄權限沒問題；用perror30提示信息爲：OSerrorcode30:Read-onlyfilesystem
可能原因：
1）文件系統損壞；
2）磁盤又壞道；
3）fstab文件配置錯誤，如分區格式錯誤錯誤(將ntfs寫成了fat)、配置指令拼寫錯誤等。
解決：
1）由於是測試機，重啓機器後恢復；
2）網上說用mount可解決。
5.文件刪了磁盤空間沒釋放
問題：
某天發現某臺機器df-h已用磁盤空間爲90G，而du-sh/*顯示所有使用空間加起來才30G，囧。
原因：
可能某人直接用rm刪除某個正在寫的文件，導致文件刪了但磁盤空間沒釋放的問題
解決：
1）最簡單重啓系統或者重啓相關服務。
2）幹掉進程
/usr/sbin/lsof|grepdeleted
ora25575data33uREG65,654294983680/oradata/DATAPRE/UNDOTBS009.dbf(deleted)
從lsof的輸出中，我們可以發現pid爲25575的進程持有着以文件描述號（fd）爲33打開的文件/oradata/DATAPRE/UNDOTBS009.dbf。
在我們找到了這個文件之後可以通過結束進程的方式來釋放被佔用的空間：echo>/proc/25575/fd/33
3）刪除正在寫的文件一般用cat/dev/null>file
6.find文件提升性能
問題：
在tmp目錄下有大量包含picture*的臨時文件，每天晚上2:30對一天前的文件進行清理。之前在crontab下跑如下腳本，但是發現腳本效率很低，每次執行時負載猛漲，影響到其他服務。
#!/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.獲取不了網關mac地址
問題：
從2.14到3.65（映射地址2.141）網絡不通，但是從3端的其他機器到3.65網絡OK。
原因：
#arp
AddressHWtypeHWaddressFlagsMaskIface
192.168.3.254etherincompletCMbond0
表面現象是機器自動獲取不了網關MAC地址，網絡工程師說是網絡設備的問題，具體不清。
解決：
arp綁定，arp-ibond0-s192.168.3.25400:00:5e:00:01:64
8.http服務無法啓動一例
問題：
某天研發某同事說網站前端環境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看了下發現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
最後重啓機器或者執行：
ulimit-u655345&&ulimit-n65535
10.ibdata1和mysql-bin致磁盤空間問題
問題：
2.51磁盤空間報警，經查發現ibdata1和mysql-bin日誌佔用空間太多（其中ibdata1超過120G，mysql-bin超過80G）
原因：
bdata1是存儲格式，在INNODB類型數據狀態下，ibdata1用來存儲文件的數據和索引，而庫名的文件夾裏的那些表文件只是結構而已。
innodb存儲引擎有兩種表空間的管理方式，分別是：
1）共享表空間（可拆分爲多個小的表空間文件），這個是我們目前多數數據庫使用的方法；
2）獨立表空間，每一個表有一個獨立的表空間（磁盤文件）
對於兩種管理方式，各有優劣，具體如下：
①共享表空間：
優點：
可以將表空間分成多個文件存放到不同的磁盤上（表空間文件大小不受表大小的限制，一個表可以分佈在不同步的文件上）
缺點：
所有數據和索引存放在一個文件中，則隨着數據的增加，將會有一個很大的文件，雖然可以把一個大文件分成多個小文件，但是多個表及索引在表空間中混合存儲，這樣如果對於一個表做了大量刪除操作後表空間中將有大量空隙。
對於共享表空間管理的方式下，一旦表空間被分配，就不能再回縮了。當出現臨時建索引或是創建一個臨時表的操作表空間擴大後，就是刪除相關的表也沒辦法回縮那部分空間了。
②獨立表空間：
在配置文件（my.cnf）中設置：innodb_file_per_table
特點：
每個表都有自已獨立的表空間；每個表的數據和索引都會存在自已的表空間中。
優點：
表空間對應的磁盤空間可以被收回（Droptable操作自動回收表空間，如果對於刪除大量數據後的表可以通過:altertabletbl_nameengine=innodb;回縮不用的空間。
缺點：
如果單表增加過大，如超過100G，性能也會受到影響。在這種情況下，如果使用共享表空間可以把文件分開，但有同樣有一個問題，如果訪問的範圍過大同樣會訪問多個文件，一樣會比較慢。
如果使用獨立表空間，可以考慮使用分區表的方法，在一定程度上緩解問題。此外，當啓用獨立表空間模式時，需要合理調整innodb_open_files參數的設置。
解決:
1）ibdata1數據太大：只能通過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自動刪除的天數
二、故障排查彙總表