문제점 : 최근에 서버 중 하나를 개정하여 사용하기 전에 테스트를 거쳤지만 며칠 전에 제대로 작동했지만 루트 볼륨에 대한 일반적인 쓰기 량의 약 4 배를 발견했습니다. 이것은 성능 문제가 아닙니다. 서버가 정상적으로 실행됩니다.
내 개조는 상당히 광범위했기 때문에 (전체 재 구축) 원인에 관해서는 할 일이 많지 않습니다. 간단히, 내 변경 사항은 다음과 같습니다.
- Amazon Linux 업그레이드 (2011.02에서 2011.09로)-루트 볼륨의 ext3에서 ext4로 변경됨
- php-fcgi에서 php-fpm으로 이동 (현재 tcp 사용)
- 리버스 프록시 (nginx-> apache) 설정에서 nginx로만 이동
- vsftpd를 pure-ftpd로 교체
- dkim-proxy를 opendkim으로 교체
- webmin을 ispconfig로 교체
- 동적 파일의 캐싱 레이어로 니스 추가 (이러한 사이트의 히트 량에 대한 과잉이지만 실험)
- 스왑 파티션 추가
기본 설정 :
- 스왑 볼륨에 쓰기 무시할 - - 내 스왑 공간이 자신의 EBS 볼륨에 장착되어 나는 본질적 원인이 할인 한 (이 충분한 여유 메모리가 - 모두
free와는iostat최소한의 스왑 사용량을 보여줍니다). - 내 데이터 (mysql 데이터베이스, 사용자 파일 (웹 사이트), 모든 로그 (/ var / log의), 메일 및 니스 파일 (자신의 EBS 볼륨
mount --bind)를 사용하여 기본 EBS 볼륨이에 마운트됩니다./mnt/data - 운영 체제 및 핵심 서버 응용 프로그램 (예 : nginx, postfix, dovecot 등)과 같은 나머지 파일은 루트 볼륨에있는 유일한 것입니다 (총 1.2GB).
새로운 설정은 이전 시스템보다 '스모 더'(빠른 메모리, 적은 메모리 등)를 실행하며 20 일 동안 안정적으로 유지되었습니다. .
내가 기대하는 것과는 반대로, 나는 낮은 읽기 볼륨을 가지고 있습니다 (내 읽기는 루트 볼륨의 블록 및 바이트 측면에서 내 쓰기의 약 1.5 %입니다). 지난 며칠 동안 루트 볼륨 (예 : 새 설치 등)에서 아무것도 변경하지 않았지만 쓰기 볼륨은 계속 예상보다 훨씬 높습니다.
목표 : 루트 볼륨에 대한 쓰기 증가 원인을 확인합니다 (본질적으로 프로세스 (및 프로세스), 다른 (ext4) 파일 시스템 또는 다른 문제 (예 : 메모리)인지 파악).
시스템 정보:
- 플랫폼 : 아마존 EC2 (t1.micro)
- O / S : Amazon Linux 2011.09 (CentOS / RHEL 파생)
- 리눅스 커널 : 2.6.35.14-97.44.amzn1.i686
- 아키텍처 : 32 비트 / i686
- 디스크 : 3 개의 EBS 볼륨 :
- xvdap1, 루트, ext4 파일 시스템 (noatime으로 마운트)
- xvdf, 데이터, xfs 파일 시스템 (noatime, usrquota, grpquota로 마운트 됨)
- xvdg, 스왑
루트 및 데이터 볼륨은 하루에 한 번 스냅 샷되지만 쓰기 작업이 아니라 '읽기'작업이어야합니다. 또한 이전 서버에서도 동일한 방법이 사용되었으며 이전 서버는 t1.micro였습니다.
내가 I / O를 조사하게 한 데이터는 마지막 AWS 청구서의 세부 사항에있었습니다 (이 서버를 설정하고 처음에 많은 것을 설치했기 때문에 예상치 않은 정상적인 I / O보다 높았습니다) 해당 월에 연결 한 다음 연결된 EBS 볼륨에 대한 CloudWatch 지표에서 월 값을 추정하기 위해 11 월 (서버를 변경하지 않은 경우)의 I / O 활동을 추정하고 내가 근무하지 않았던 지난 몇 달의 I / O와 비교하여 '정상적인 4 배'수치에 도달합니다. 이전 서버에서. (이전 서버의 정확한 iostat 데이터가 없습니다). 11 월까지 170-330MB / hr로 동일한 양의 쓰기가 지속되었습니다.
진단 정보 (다음 출력의 가동 시간은 20.6 일입니다) :
클라우드 워치 지표 :
- 루트 볼륨 (쓰기) : 5.5GB / 일
- 루트 볼륨 (읽기) : 60MB / 일
- 데이터 볼륨 (쓰기) : 400MB / 일
- 데이터 볼륨 (읽기) : 85MB / 일
- 스왑 볼륨 (쓰기) : 3MB / 일
- 스왑 볼륨 (읽기) : 2MB / 일
출력 : df -h(루트 볼륨에만 해당)
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 4.0G 1.2G 2.8G 31% /
이 시스템이 시작된 이후 사용 된 공간이 눈에 띄게 증가하지 않았습니다 (파일 생성 / 추가가 아니라 파일이 업데이트되고 있음을 나타냅니다).
출력 : iostat -x(로 Blk_read, Blk_wrtn추가) :
Linux 2.6.35.14-95.38.amzn1.i686 11/05/2011 _i686_
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s Blk_read Blk_wrtn avgrq-sz avgqu-sz await svctm %util
xvdap1 0.00 3.42 0.03 2.85 0.72 50.19 2534636 177222312 17.68 0.18 60.93 0.77 0.22
xvdf 0.00 0.03 0.04 0.35 1.09 8.48 3853710 29942167 24.55 0.01 24.28 2.95 0.12
xvdg 0.00 0.00 0.00 0.00 0.02 0.04 70808 138160 31.09 0.00 48.98 4.45 0.00
출력 : iotop -d 600 -a -o -b
Total DISK READ: 6.55 K/s | Total DISK WRITE: 117.07 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
852 be/4 root 0.00 B 26.04 M 0.00 % 0.42 % [flush-202:1]
539 be/3 root 0.00 B 528.00 K 0.00 % 0.08 % [jbd2/xvda1-8]
24881 be/4 nginx 56.00 K 120.00 K 0.00 % 0.01 % nginx: worker process
19754 be/4 mysql 180.00 K 24.00 K 0.00 % 0.01 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
3106 be/4 mysql 0.00 B 176.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19751 be/4 mysql 4.00 K 0.00 B 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
3194 be/4 mysql 8.00 K 40.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
3156 be/4 mysql 4.00 K 12.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
3099 be/4 mysql 0.00 B 4.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
24216 be/4 web14 8.00 K 10.43 M 0.00 % 0.00 % php-fpm: pool web14
24465 be/4 web19 0.00 B 7.08 M 0.00 % 0.00 % php-fpm: pool web19
3110 be/4 mysql 0.00 B 100.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
579 be/4 varnish 0.00 B 76.00 K 0.00 % 0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
582 be/4 varnish 0.00 B 144.00 K 0.00 % 0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
586 be/4 varnish 0.00 B 4.00 K 0.00 % 0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
587 be/4 varnish 0.00 B 40.00 K 0.00 % 0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
1648 be/4 nobody 0.00 B 8.00 K 0.00 % 0.00 % in.imapproxyd
18072 be/4 varnish 128.00 K 128.00 K 0.00 % 0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
3101 be/4 mysql 0.00 B 176.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19749 be/4 mysql 0.00 B 32.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19750 be/4 mysql 0.00 B 0.00 B 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19752 be/4 mysql 0.00 B 108.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19788 be/4 mysql 0.00 B 12.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
853 be/4 root 4.00 K 0.00 B 0.00 % 0.00 % [flush-202:80]
22011 be/4 varnish 0.00 B 188.00 K 0.00 % 0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
위의 내용을 요약하고 (일별 값으로 추정) 10 분 동안 다음과 같이 보입니다.
- [flush-202]는 26MB = 3.6GB / day를 썼습니다.
- php-fpm 작성 17.5MB = 2.4GB / 일
- MySQL은 684KB = 96MB / 일을 썼습니다.
- 니스는 580KB = 82MB / 일을 썼습니다.
- [jbd2] 528KB = 74MB / 일 작성
- Nginx는 120KB = 17MB / 일을 썼습니다.
- IMAP 프록시는 8KB = 1.1MB / 일을 썼습니다
흥미롭게도,이 사이에 있음을 나타납니다 [flush-202]와 php-fpm는 쓰기의 일상 볼륨 계정에 가능하다.
사용하여 ftop, 나는 추적 드릴 수 없습니다 중 하나 flush또는 php-fpm쓰기 (예 ftop -p php-fpm.
내 문제의 적어도 일부는 루트 볼륨에 쓰는 프로세스를 식별하는 데 있습니다. 그 위에 나열된, 나는 (관련 디렉토리가이 심볼릭 링크되기 때문에) 모든 데이터 볼륨에 기록 될 예상 (예를 들어 nginx, mysql, php-fpm, varnish다른 EBS 볼륨 디렉토리의 모든 지점)
나는 JBD2ext4의 저널링 블록 장치 라고 생각 flush-202하며 더티 페이지의 배경 플러시입니다. 는 dirty_ratio20이며,이 dirty_background_ratio(10. 더티 메모리이다 /proc/meminfo) 일반적 50-150kB 사이였다). 페이지 크기 ( getconf PAGESIZE)가 시스템 기본값 (4096)입니다.
출력 : vmstat -s | grep paged
104625313 페이지에 3248858 페이지가 페이지 아웃 됨
출력 : sar -B | grep Average
pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff
Average: 1.38 39.57 113.79 0.03 36.03 0.38 0.02 0.29 73.66
위의 내용은 많은 페이지가 페이지 아웃되는 것으로 보이지만 필요한 경우 루트 볼륨이 아닌 스왑 파티션에 페이지가 기록 될 것으로 예상합니다. 총 메모리 중에서 시스템은 일반적으로 35 % 사용, 10 % 버퍼, 40 % 캐시, 15 % 사용되지 않음 (즉, 65 % 사용 가능)을 갖습니다.
출력 : vmstat -d
disk- ------------reads------------ ------------writes----------- -----IO------
total merged sectors ms total merged sectors ms cur sec
xvda1 105376 14592 2548092 824418 10193989 12264020 179666824 626582671 0 7872
xvdf 126457 579 3882950 871785 1260822 91395 30081792 32634413 0 4101
xvdg 4827 4048 71000 21358 1897 15373 138160 307865 0 29
vmstat지속적으로 표시 si및 so0 값
출력 : swapon -s
Filename Type Size Used Priority
/dev/xvdg partition 1048572 9252 -1
직감적으로 I / O 쓰기는 메모리와 관련이있을 수 있으며, 니스를 비활성화하고 서버를 다시 시작했습니다. 이로 인해 내 메모리 프로필이 사용 중 10 %, 버퍼 2 %, 캐시 20 %, 68 % 사용되지 않음 (예 : 90 % 사용 가능)으로 변경되었습니다. 그러나 10 분 동안 iotop을 실행하면 이전과 비슷한 결과가 나타납니다.
- [flush-202]는 19MB를 썼습니다
- php-fpm은 10MB를 썼습니다
다시 시작한 이후 1 시간 동안 이미 370K 페이지가 스왑 아웃 된 루트 볼륨에 330MB가 기록되었습니다.
출력 inotifywatch -v -e modify -t 600 -r /[^mnt]*
Establishing watches...
Setting up watch(es) on /bin /boot /cgroup /dev /etc/ home /lib /local /lost+found /opt /proc /root /sbin /selinux /src /sys /usr /var
OK, /bin /boot /cgroup /dev /etc/ home /lib /local /lost+found /opt /proc /root /sbin /selinux /src /sys /usr /var is now being watched.
Total of 6753 watches.
Finished establishing watches, now collecting statistics.
Will listen for events for 600 seconds.
total modify filename
23 23 /var/log/
20 20 /usr/local/ispconfig/server/temp/
18 18 /dev/
15 15 /var/log/sa/
11 11 /var/spool/postfix/public/
5 5 /var/log/nginx/
2 2 /var/run/pure-ftpd/
1 1 /dev/pts/
위의 내용을 조금 더 살펴보면 거의 모든 쓰기가 5 분마다 실행되고 chkservdcPanel 과 같은 다양한 서비스의 상태를 확인하는 (알 수없는) 프로세스에 기인 할 수 있지만 cPanel을 사용하지 않습니다. 설치하지 않았습니다). 10 분 동안 업데이트 된 4 개의 로그 파일 (cron, maillog, ftp, imapproxy)과 몇 가지 관련 항목 (접두사 소켓, 순수 ftpd 연결)에 해당합니다. 다른 항목은 주로 ispconfig 세션, 시스템 계정 업데이트 및 유효하지 않은 server_name 웹 액세스 시도 (/ var / log / nginx에 로그인)로 수정됩니다.
결론 및 질문 :
나는 약간 당황한 말로 시작하겠습니다. 나는 보통 상당히 철저하지만, 나는 이것에 명백한 것을 놓치고 있다고 생각합니다. 분명히, flush그리고 php-fpm이 경우 수 있습니다 왜 쓰기의 대부분을위한 계정, 그러나, 나는 모른다. 먼저, php-fpm을 가져 오십시오-루트 볼륨에도 쓰지 않아야합니다. 디렉토리 (파일과 로그 모두)가 다른 EBS 볼륨에 심볼릭 링크되어 있습니다. 두 번째로, php-fpm이 작성해야 할 주요 사항은 세션과 페이지 캐시입니다. 세션 캐시와 페이지 캐시는 크거나 작지만 1MB / min (1K / min 정도) 정도는 아닙니다. 대부분의 사이트는 읽기 전용이며 가끔 업데이트됩니다. 마지막 날에 수정 된 모든 웹 파일의 총 크기는 2.6MB입니다.
두 번째로, 플러시를 고려하면-더러운 페이지가 자주 디스크로 플러시되고 있음을 알 수 있습니다.하지만 일반적으로 스왑 공간을 위해 65 %의 여유 메모리와 별도의 EBS 볼륨이 있다고 가정하면 이것이 왜 그런지 설명 할 수 없습니다 루트 볼륨의 쓰기, 특히 발생하는 범위에 영향을줍니다. 일부 프로세스는 시스템 스왑 공간을 사용하지 않고 자체 스왑 공간에 더티 페이지를 기록하지만, 대부분의 메모리가 비어있는 상태에서 다시 시작한 직후에는 상당한 양의 메모리를 사용해서는 안됩니다. 더러운 페이지. 이것이 원인이라고 생각되면 어떤 프로세스가 자신의 스왑 공간에 쓰고 있는지 식별하는 방법을 알려주십시오.
전체 더러운 페이지 아이디어가 단순히 청어 일뿐 아니라 내 문제와 전혀 관련이없는 것이 전적으로 가능합니다 (실제로 바랍니다). 그렇다면 ext3에는 없었던 ext4 저널링과 관련된 것이 있다는 유일한 아이디어입니다. 그 외에도 저는 현재 아이디어가 없습니다.
업데이트 :
2011 년 11 월 6 일 :
설정 dirty_ratio = 10하고 dirty_background_ratio = 5; sysctl -p(/ proc을 통해 확인)으로 업데이트 ; 비슷한 결과를 가진 10 분 요오드 테스트 재실행 (플러시 쓰기 17MB, php-fpm 쓰기 16MB, MySQL 쓰기 1MB, JBD2 쓰기 0.7MB).
mount --bind대신 사용하도록 설정 한 모든 심볼릭 링크를 변경 했습니다. 바니시를 다시 활성화하고 서버를 다시 시작했습니다. 비슷한 결과를 가진 10 분 요오드 테스트 재실행 (플러시 12.5MB, php-fpm 11.5MB, Varnish 0.5MB, JBD2 0.5MB, MySQL 0.3MB)
위의 실행에서와 같이 내 메모리 프로필은 사용 중 20 %, 버퍼 2 %, 캐시 된 58 %, 사용되지 않은 20 % (예 : 80 %)였습니다.이 상황에서 사용 가능한 메모리에 대한 해석에 결함이있는 경우를 대비하여, 여기에 출력이 있습니다 free -m(t1.micro입니다). 캐시 된 총 사용 가능한 공유 버퍼 Mem : 602478124 014 347-/ + 버퍼 / 캐시 : 116486 스왑 : 1023 1023
일부 추가 정보 : 출력 : dmesg | grep EXT4
[ 0.517070] EXT4-fs (xvda1): mounted filesystem with ordered data mode. Opts: (null)
[ 0.531043] EXT4-fs (xvda1): mounted filesystem with ordered data mode. Opts: (null)
[ 2.469810] EXT4-fs (xvda1): re-mounted. Opts: (null)
또한 ftop과 iotop을 동시에 실행했으며 iotop에 표시되는 항목이 ftop에 나타나지 않았다는 사실에 놀랐습니다. ftop 목록은 php-fpm으로 필터링되었습니다.이 프로세스의 쓰기를 상당히 안정적으로 시작할 수 있기 때문입니다. 나는 php-fpm에 대한 페이지 뷰당 약 2MB의 쓰기를 기록했으며, 작성 가능한 내용을 아직 파악하지 못했습니다. 작성중인 내용을 확인하는 아이디어는 높이 평가됩니다.
앞으로 며칠 안에 저널링을 끄려고 노력하고 그것이 개선 될 수 있는지 살펴볼 것입니다. 그러나 현재 I / O 문제 나 메모리 문제 (또는 둘 다)가 있는지 궁금해하지만 메모리 문제가 있으면 어려움을 겪고 있습니다.
2011 년 11 월 13 일 :
파일 시스템이 익스텐트를 사용하기 때문에 익스텐트를 ext3으로 마운트 할 수 없었으며 추가로이를 읽기 전용으로 마운트하려고 시도하여 단순히 읽기 / 쓰기로 다시 마운트되었습니다.
파일 시스템에는 실제로 다음과 같이 저널링이 활성화되어 있습니다 (128MB 저널).
출력 : tune2fs -l /dev/sda1 | grep features
has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
다음에 따르면 약 140GB가 한 달에 조금씩 (약 5GB / 일)이 볼륨에 기록되었습니다.
출력 : dumpe2fs -h /dev/sda1
Filesystem volume name: /
Last mounted on: /
Filesystem UUID: af5a3469-6c36-4491-87b1-xxxxxxxxxxxx
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 262144
Block count: 1048576
Reserved block count: 10478
Free blocks: 734563
Free inodes: 210677
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 511
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
RAID stride: 32582
Flex block group size: 16
Filesystem created: Wed Sep 21 21:28:43 2011
Last mount time: Sun Nov 13 16:10:11 2011
Last write time: Sun Oct 16 16:12:35 2011
Mount count: 13
Maximum mount count: 28
Last checked: Mon Oct 10 03:04:13 2011
Check interval: 0 (<none>)
Lifetime writes: 139 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
First orphan inode: 18610
Default directory hash: half_md4
Directory Hash Seed: 6c36b2cc-b230-45e2-847e-xxxxxxxxxxx
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length: 32768
Journal sequence: 0x0002d91c
Journal start: 1
열린 파일을 계속 찾기 위해 fuser루트 볼륨에서 사용해 보았습니다 .
출력 : fuser -vm / 2>&1 | awk '$3 ~ /f|F/'
root 1111 Frce. dhclient
root 1322 frce. mysqld_safe
mysql 1486 Fr.e. mysqld
root 1508 Frce. dovecot
root 1589 Frce. master
postfix 1600 Frce. qmgr
root 1616 Frce. crond
root 1626 Frce. atd
nobody 1648 Frce. in.imapproxyd
postfix 1935 Frce. tlsmgr
root 2808 Frce. varnishncsa
root 25818 frce. sudo
root 26346 Fr.e. varnishd
postfix 26925 Frce. pickup
postfix 28057 Frce. smtpd
postfix 28070 Frce. showq
불행히도 예기치 않은 것은 없습니다. 기본 하드웨어로 인한 오프 기회에서 어제 루트 볼륨의 스냅 샷을 복원하고 (마지막 날에는 아무것도 변경되지 않음) 인스턴스의 루트 볼륨을 새로운 것으로 교체했습니다. 예상대로 이것은 문제에 영향을 미치지 않았습니다.
다음 단계는 저널링을 제거하는 것이었지만 해결책을 찾기 전에 넘어졌습니다.
파일 백업 mmap을 사용하여 APC에 문제가 있습니다. 이 삭제 된 디스크 i / o를 약 35 배-(추정치) 150MB / 일 (5GB 대신) 저널링을 제거하는 것이이 값의 주요 기여자 인 것처럼 보이기는하지만 여전히이 숫자는 당분간 허용됩니다. APC 결론에 도달하기 위해 취한 단계는 아래 답변에 게시됩니다.
watch. 파일이 거의 없었습니다 (17) – 대부분 PID 파일 또는 잠금 파일, 존재하지 않는 임시 파일이 몇 개 있습니다. watch -d -n 0.5 'lsof / | grep REG | awk '"'"'$4 ~ /.*[wu]/ { print $9}'"'"' | sort -u'