歡迎光臨
每天分享高質量文章

請收藏 | Linux運維常見故障及處理的 32 個錦囊妙計

來自:馬哥Linux運維,內容整理自網絡,原作者不詳

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

下麵彙總了我做專案過程可能出現的故障及解決方法,看看是否與你有共鳴,並對你有幫助?

第一:常見問題解決集錦

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自動刪除的天數

二、故障排查彙總表


●編號603,輸入編號直達本文

●輸入m獲取文章目錄

推薦↓↓↓

 

運維

更多推薦18個技術類微信公眾號

涵蓋:程式人生、演算法與資料結構、黑客技術與網絡安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。

赞(0)

分享創造快樂