最近運維中遇到的一些問題及解決方法

1.shell腳本死活不執行
問題：某天研發某同事找我說幫他看看他寫的shell腳本，死活不執行，報錯。我看了下，腳本很簡單，也沒有常規性的錯誤，報「: bad interpreter: No such file or directory」錯。一
看這錯，我就問他是否是在windows下編寫的腳本，而後在上傳到linux服務器的……果真。
緣由：在DOS/Windows裏，文本文件的換行符爲\r\n，而在*nix系統裏則爲\n，因此DOS/Windows裏編輯過的文本文件到了*nix裏，每一行都多了個^M。
解決：1）從新在linux下編寫腳本；2）vi :% s/\r//g  :% s/^M//g （^M輸入用Ctrl+v, Ctrl+m）
——————————————————————————————————————————
2.crontab輸出
問題：/var/spool/clientmqueue目錄佔用空間超過100G
緣由：cron中執行的程序有輸出內容，輸出內容會以郵件形式發給cron的用戶，而sendmail沒有啓動因此就產生了/var/spool/clientmqueue目錄下的那些文件，日積月累可能撐破磁盤。
解決：1）直接手動刪除：ls |xargs rm -f  ； 2）完全解決：在cron的自動執行語句後加上 >/dev/null 2>&1
——————————————————————————————————————————
3.telnet很慢
問題：某天研發某同事說10.50訪問10.52memcached服務異常，讓咱們檢查下看網絡/服務/系統是否有異常。檢查發現系統正常，服務正常，10.50ping10.52也正常，但10.50telnet10.52很慢。同時發現該機器的namesever是不起做用的。
緣由：because your PC doesn’t do a reverse DNS lookup on your IP then… when you telnet/ftp into your linux box, it’ll do a dns lookup on you。
解決：1)修改/etc/hosts使hostname和ip對應； 2）在/etc/resolv.conf註釋掉nameserver或者找一個「活的」nameserver。
——————————————————————————————————————————
4.Read-only file system
問題：同事在mysql裏建表建不成功，提示以下：
mysql>create table wosontest (colddname1 char(1));
ERROR 1005 (HY000): Can’t create table ‘wosontest’ (errno: 30）
經檢查mysql用戶權限以及相關目錄權限沒問題；用perror 30提示信息爲：OS error code  30:  Read-only file system
可能緣由：1）文件系統損壞；2）磁盤又壞道；3）fstab文件配置錯誤，如分區格式錯誤錯誤(將ntfs寫成了fat)、配置指令拼寫錯誤等。
解決：1）因爲是測試機，重啓機器後恢復；2）網上說用mount可解決。
——————————————————————————————————————————
5.文件刪了磁盤空間沒釋放
問題：某天發現某臺機器df -h已用磁盤空間爲90G，而du -sh /*顯示全部使用空間加起來才30G，囧。
緣由：可能某人直接用rm刪除某個正在寫的文件，致使文件刪了但磁盤空間沒釋放的問題
解決：
1）最簡單重啓系統或者重啓相關服務。
2）幹掉進程
/usr/sbin/lsof|grep deleted
ora    25575 data   33u      REG              65,65  4294983680  /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 -exec rm -f {} \;
緣由：目錄下有大量文件，用find很耗資源。
解決：
#!/bin/sh
cd /tmp
time=`date -d 「2 day ago」 「+%b %d」`
ls -l|grep 「picture」 |grep 「$time」|awk ‘{print $NF}’|xargs rm -rf
——————————————————————————————————————————
7.獲取不了網關mac地址
問題：從2.14到3.65（映射地址2.141）網絡不通，可是從3端的其餘機器到3.65網絡OK。
緣由：
# arp
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.3.254            ether   incomplet             CM                    bond0
表面現象是機器自動獲取不了網關MAC地址，網絡工程師說是網絡設備的問題，具體不清。
解決：arp綁定，arp -i bond0 -s 192.168.3.254 00:00:5e:00:01:64
——————————————————————————————————————————
8.問題：某天研發某同事說網站前端+1環境http沒法啓動，我上去看了下。報以下錯：
/etc/init.d/httpd start
Starting httpd: [Sat Jan 29 17:49:00 2011] [warn] module antibot_module is already loaded, skipping
Use proxy forward as remote ip : true.
Antibot exclude pattern : .*\.[(js|css|jpg|gif|png)]
Antibot seed check pattern : login
(98)Address already in use: make_sock: could not bind to address [::]:7080
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:7080
no listening sockets available, shutting down
Unable to open log                                                      [FAILED]
緣由：
1）端口被佔用：表面看是7080端口被佔用，因而netstat -npl|grep 7080看了下發現7080沒有佔用；
2）在配置文件中重複寫了端口，若是在如下兩個文件同時寫了Listen 7080
/etc/httpd/conf/http.conf
/etc/httpd/conf.d/t.10086.cn.conf
解決：註釋掉/etc/httpd/conf.d/t.10086.cn.conf的Listen 7080，重啓，OK。
——————————————————————————————————————————
9.too many open file終極解決方案
echo 「」 >> /etc/security/limits.conf
echo 「*                soft   nproc          65535″ >> /etc/security/limits.conf
echo 「*                hard   nproc          65535″ >> /etc/security/limits.conf
echo 「*                soft   nofile         65535″ >> /etc/security/limits.conf
echo 「*                hard   nofile         65535″ >> /etc/security/limits.conf
 
echo 「」 >> /root/.bash_profile
echo 「ulimit  -n   65535″ >> /root/.bash_profile
echo 「ulimit  -u   65535″ >> /root/.bash_profile
 
最後重啓機器 或者執行 ulimit -u 655345 && ulimit -n 65535
 
——————————————————————————————————————————
10.ibdata1和mysql-bin
問題：2.51磁盤空間報警，經查發現ibdata1和mysql-bin日誌佔用空間太多（其中ibdata1超過120G，mysql-bin超過80G）
緣由：ibdata1是存儲格式，在INNODB類型數據狀態下，ibdata1用來存儲文件的數據和索引，而庫名的文件夾裏的那些表文件只是結構而已。
innodb存儲引擎有兩種表空間的管理方式，分別是：
1）共享表空間（可拆分爲多個小的表空間文件），這個是咱們目前多數數據庫使用的方法；
2）獨立表空間，每個表有一個獨立的表空間（磁盤文件）
對於兩種管理方式，各有優劣，具體以下：
①共享表空間：
優勢：能夠將表空間分紅多個文件存放到不一樣的磁盤上（表空間文件大小不受表大小的限制，一個表能夠分佈在不一樣步的文件上）。
缺點：全部數據和索引存放在一個文件中，則隨着數據的增長，將會有一個很大的文件，雖然能夠把一個大文件分紅多個小文件，可是多個表及索引在表空間中混合存儲，這樣若是對於一個表作了大量刪除操做後表空間中將有大量空隙。對於共享表空間管理的方式下，一旦表空間被分配，就不能再回縮了。當出現臨時建索引或是建立一個臨時表的操做表空間擴大後，就是刪除相關的表也沒辦法回縮那部分空間了。
②獨立表空間：在配置文件（my.cnf）中設置： innodb_file_per_table
特色：每一個表都有自已獨立的表空間；每一個表的數據和索引都會存在自已的表空間中。
優勢：表空間對應的磁盤空間能夠被收回（Drop table操做自動回收表空間，若是對於刪除大量數據後的表能夠經過:alter table tbl_name engine=innodb;回縮不用的空間。
缺點：若是單表增長過大，如超過100G，性能也會受到影響。在這種狀況下，若是使用共享表空間能夠把文件分開，但有一樣有一個問題，若是訪問的範圍過大一樣會訪問多個文件，同樣會比較慢。若是使用獨立表空間，能夠考慮使用分區表的方法，在必定程度上緩解問題。此外，當啓用獨立表空間模式時，須要合理調整innodb_open_files參數的設置。
解決:
1）ibdata1數據太大：只能經過dump，導出建庫的sql語句，再重建的方法。
2）mysql-bin Log太大：
①手動刪除：
刪除某個日誌：mysql>PURGE MASTER LOGS TO ‘mysql-bin.010′;
刪除某天前的日誌：mysql>PURGE MASTER LOGS BEFORE ’2010-12-22 13:00:00′;
②在/etc/my.cnf裏設置只保存N天的bin-log日誌
expire_logs_days = 30  //Binary Log自動刪除的天數

 ---★ 本文轉摘自『IT學習者』→ http://www.itlearner.com/article/4820