리눅스 일반적인 문제 해결
1. 쉘 스크립트에서 ^ M을 제거하는 방법
해결책：
sed -i‘s / ^ M // g’ script.sh （입력 “^ 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.텔넷이 매우 느림 / ssh가 매우 느림
문제：어느 날 R & D 동료가 10.52 memcached 서비스에 대한 10.50 액세스가 비정상이라고 말했습니다.，
네트워크 / 서비스 / 시스템이 비정상인지 확인 해보자。시스템이 정상인지 확인，
서비스는 정상입니다，10.50핑 10.52도 정상입니다，그러나 10.50 텔넷 10.52는 매우 느립니다.。
동시에 기계의 이름이 작동하지 않는 것으로 나타났습니다.。
이유：PC는 IP에서 역방향 DNS 조회를 수행하지 않기 때문에…
리눅스 박스에 telnet / ftp를 입력 할 때, 당신에 대한 DNS 조회를 할 것입니다。
풀다：
1)/ etc / hosts를 수정하여 호스트 이름과 IP를 일치 시키십시오.；
2) /etc/resolv.conf에서 네임 서버를 주석 처리하거나 "라이브"네임 서버를 찾으십시오.。 ———————————————————————————————————————————
4.읽기 전용 파일 시스템
문제：내 동료가 mysql에서 테이블을 만들지 못했습니다.，프롬프트는 다음과 같습니다.：
mysql>wosontest 테이블 만들기 (colddname1 문자(1));
오류 1005 (HY000): 'wosontest'테이블을 만들 수 없습니다. (Errno: 30）
mysql 사용자 권한 및 관련 디렉토리 권한을 확인한 후 문제가 없습니다.；공포 30과 함께 프롬프트 메시지는：
OS 오류 코드 30: 읽기 전용 파일 시스템
가능한 원인들：
1) 파일 시스템 손상；
2) 디스크의 불량 섹터；
3) fstab 파일 구성 오류，파티션 형식 오류 등(ntfs를 지방으로 작성)、구성 지침의 맞춤법 오류 등。
풀다：
1) 시험기이기 때문에，머신을 다시 시작한 후 복구；
2) 인터넷에서는 마운트로 해결할 수 있습니다.。
———————————————————————————————————————————
5.파일이 삭제되고 디스크 공간이 해제되지 않습니다.：
어느 날 df -h 머신의 사용 된 디스크 공간이 90G 인 것으로 나타났습니다.，그리고 du -sh / *는 사용 된 모든 공간이 30G까지 추가됨을 보여줍니다.，
죄송합니다。 이유：누군가가 rm을 사용하여 작성중인 파일을 삭제하는 경우，파일이 삭제되었지만 디스크 공간이 해제되지 않은 문제
풀다：
1) 시스템을 다시 시작하거나 관련 서비스를 다시 시작하는 가장 쉬운 방법。
2) / usr / sbin / lsof 프로세스 종료|grep이 ora를 삭제했습니다. 25575 데이터 33u REG
65,65 4294983680 /oradata / DATAPRE / UNDOTBS009.dbf (삭제됨)
lsof의 출력에서，pid가 25575 인 프로세스에 파일 설명 번호 (fd)가 있음을 알 수 있습니다.
33에 대해 열린 파일 /oradata/DATAPRE/UNDOTBS009.dbf。우리가 찾은 곳
이 파일 이후에는 프로세스를 종료하여 점유 공간을 해제 할 수 있습니다.：
에코 > /proc / 25575 / fd / 33 3) 작성중인 파일을 삭제하려면 일반적으로 cat / dev / null > 파일 ——————————————————————————————————————————
6.성능 향상을위한 파일 찾기
문제：tmp 디렉토리에 picture_ *가 포함 된 임시 파일이 많이 있습니다.，매일 밤 2:30전날까지
파일 정리。crontab에서 다음 스크립트를 실행하기 전에，그러나 스크립트가 매우 비효율적이라는 것을 알았습니다.，매번
부하 서지，다른 서비스에 영향。
#!/bin / sh find / tmp -name“picture_ *”-mtime +1 -exec rm -f {} ;
이유：디렉토리에 많은 파일이 있습니다.，찾기 사용은 리소스를 많이 사용합니다.。
풀다： #!/bin / sh cd / tmp time =`date -d“2 일 전”“+
%b % d”`ls -l|grep“그림” |"$ 시간"잡기|awk‘{$ NF 인쇄}’|xargs rm -rf
———————————————————————————————————————————
7.게이트웨이 MAC 주소 문제를 가져올 수 없습니다.：2.14에서 3.65까지의 네트워크 오류 (매핑 된 주소 2.141)，
그러나 세 번째 끝의 다른 컴퓨터에서 3.65 네트워크로 OK。
이유： # arp 주소 HWtype HWaddress 플래그 마스크 Iface 192.168.3.254
에테르 incomplet CM
bond0의 표면 현상은 기계가 게이트웨이 MAC 주소를 자동으로 얻을 수 없다는 것입니다.，네트워크 엔지니어가 네트워크 장비 문제라고 말했습니다.，
불명확。
풀다： arp 바인딩，arp -i 본드 0 -s 192.168.3.254 00:00:5이자형:00:01:64 ———————————————————————————————————————————
8.http 서비스의 예를 시작할 수 없습니다.：어느 날 R & D 동료가 웹 사이트 프론트 엔드 환경 http를 시작할 수 없다고 말했습니다.，
나는 올라가서 보았다。
다음 오류보고：
/etc / init.d / httpd start httpd 시작: [1 월 토 29 17:49:00 2011] [경고] 기준 치수
antibot_module이 이미로드되었습니다., 원격 IP로 프록시 전달 사용 건너 뛰기 :
진실. Antibot 제외 패턴 : .*.[(js|CSS|jpg|gif|png)] 안티 봇 시드 체크 패턴
: 로그인 (98)이미 사용중인 주소: make_sock: 주소에 바인딩 할 수 없습니다 [::]:7080
(98)이미 사용중인 주소: make_sock: 주소에 바인딩 할 수 없습니다 0.0.0.0:7080
사용 가능한 청취 소켓 없음, 로그를 열 수 없습니다. [실패한]
이유：
1) 포트가 점유 됨：표면에는 포트 7080이 사용됩니다.，그래서 netstat -npl|grep 7080 살펴보기
7080이 사용 중이 아님； 2) 구성 파일에서 포트 복제，다음 두 파일을 동시에 쓰면
들리다 7080 /etc / httpd / conf / http.conf /etc/httpd/conf.d/t.10086.cn.conf
풀다： /etc/httpd/conf.d/t.10086.cn.conf에서 Listen을 주석 처리하십시오. 7080，재부팅，확인。 ———————————————————————————————————————————
9.열려있는 파일이 너무 많습니다.
문제：너무 많은 열린 파일 오류보고
풀다：궁극적 인 솔루션
에코 "" >> /etc / security / limits.conf
에코 "* 소프트 nproc 65535" >> /etc / security / limits.conf
echo "* 하드 nproc 65535" >> /etc / security / limits.conf
에코“* 소프트 nofile 65535 ″ >> /etc / security / limits.conf
echo“* hard nofile 65535 ″ >> /etc / security / limits.conf
에코 "" >> /root / .bash_profile
에코 "ulimit -n 65535" >> /root / .bash_profile
에코 "ulimit -u 65535" >> /root / .bash_profile
마지막으로 시스템을 다시 시작하거나 ulimit -u를 실행하십시오. 655345 && ulimit -n 65535 ———————————————————————————————————————————
10. 프롬프트없이 파일 덮어 쓰기
다음 명령을 직접 입력하여 실현할 수 있습니다.
[root @ linuxtest ~]# \cp -rf zongguofeng linuxzgf
[root @ linuxtest ~]#
11.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
풍모：각 테이블에는 고유 한 독립 테이블 스페이스가 있습니다.；각 테이블의 데이터 및 인덱스는 자체 테이블 스페이스에 저장됩니다.。
이점：테이블 공간에 해당하는 디스크 공간을 재 확보 할 수 있습니다 (테이블 삭제 조작은 자동으로 테이블 공간을 재 확보합니다).，경우
많은 양의 데이터를 삭제 한 후 테이블을 전달할 수 있습니다.:테이블 tbl_name engine = innodb 변경;사용하지 않은 공간 축소。
불리：단일 테이블이 너무 많이 증가하면，100G 이상인 경우，성능도 영향을받습니다.。이런 상황에서，사용하는 경우
공유 테이블 스페이스는 파일을 분리 할 수 있습니다.，하지만 같은 문제가 있습니다，방문 범위가 너무 크면 동일하게 방문합니다.
여러 파일，느려질 것입니다。별도의 테이블 스페이스를 사용하는 경우，파티션 테이블 방법 사용을 고려할 수 있습니다.，확실히
문제 완화。 게다가，독립 테이블 스페이스 모드가 활성화 된 경우，innodb_open_files를 합리적으로 조정해야합니다.
매개 변수 설정。 풀다: 1) Ibdata1 데이터가 너무 큽니다.：덤프를 통해서만，데이터베이스 구축을위한 SQL 문 내보내기，다시
재건 방법。
2) Mysql-bin 로그가 너무 큽니다.：
① 수동 삭제： 로그 삭제：mysql>'mysql-bin'에 마스터 로그 제거.010′;
특정 일 전의 로그 삭제：mysql>2010-12-22 이전에 마스터 로그 제거 13:00:00′;
② /etc/my.cnf에서 N 일의 bin-log 로그 만 저장하도록 설정합니다. expire_logs_days = 30 //바이너리 로그
자동 삭제 된 날짜 ———————
이 기사는 KISSING_hu의 CSDN 블로그에서 가져온 것입니다. ，
전체 텍스트 주소를 클릭하십시오：https://blog.csdn.net/KISSING_hu/article/details/42113261?utm_source = copy