5,5 GB được ghi hàng ngày đến 1,2 GB dung lượng gốc - gấp 4 lần mức trước đó

Vấn đề: Gần đây tôi đã tân trang một trong các máy chủ của mình, nó đã được kiểm tra trước khi sử dụng và hoạt động tốt, tuy nhiên, vài ngày trước, tôi nhận thấy khoảng 4 lần số lượng ghi thông thường vào ổ đĩa gốc. Đây không phải là một vấn đề hiệu suất - máy chủ chạy tốt.

Việc sửa chữa của tôi khá rộng rãi (xây dựng lại hoàn toàn) vì vậy tôi không có nhiều điều để tiếp tục về mặt nguyên nhân. Tóm lại, những thay đổi của tôi bao gồm:

• Nâng cấp Linux của Amazon (từ 2011.02 đến 2011/09) - điều này cũng dẫn đến sự thay đổi từ ext3 sang ext4 cho khối lượng gốc
• Chuyển từ php-fcgi sang php-fpm (hiện đang sử dụng tcp)
• Chuyển từ thiết lập proxy ngược (nginx -> apache), chỉ sang nginx
• Thay thế vsftpd bằng ftpd thuần
• Thay thế dkim-proxy bằng opendkim
• Thay thế webmin bằng ispconfig
• Thêm véc ni làm lớp lưu trữ cho các tệp động (quá mức cho khối lượng truy cập mà các trang web này nhận được, nhưng đây là một thử nghiệm)
• Thêm một phân vùng trao đổi

Thiết lập cơ bản:

• Không gian hoán đổi của tôi được gắn trên khối lượng EBS của chính nó - ghi vào khối lượng trao đổi là không đáng kể - về cơ bản tôi đã giảm giá này là nguyên nhân (có bộ nhớ trống lớn - và cả hai freevà iostathiển thị mức sử dụng trao đổi tối thiểu).
• Dữ liệu của tôi (cơ sở dữ liệu mysql, tệp người dùng (trang web), tất cả các nhật ký (từ / var / log), thư và tệp vecni trên khối lượng EBS của riêng họ (sử dụng mount --bind). Khối lượng EBS cơ bản được gắn tại/mnt/data
• Các tệp còn lại của tôi - các ứng dụng hệ điều hành và máy chủ lõi (ví dụ nginx, postfix, dovecot, v.v.) - là thứ duy nhất trên ổ đĩa gốc - tổng cộng là 1,2 GB.

Thiết lập mới chạy 'mượt hơn' (nhanh hơn, ít bộ nhớ hơn, v.v.) so với hệ thống cũ và đã ổn định trong 20 ngày (giữa tháng 10) - theo như tôi có thể nói, việc ghi cao đã tồn tại trong suốt thời gian này .

Trái với những gì tôi mong đợi, tôi có khối lượng đọc thấp (số lần đọc của tôi chiếm khoảng 1,5% số lần viết của tôi, cả về khối và byte trên khối lượng gốc của tôi). Tôi đã không thay đổi bất cứ điều gì trên khối lượng gốc (ví dụ như cài đặt mới, v.v.) trong vài ngày qua, nhưng khối lượng ghi tiếp tục cao hơn nhiều so với dự kiến.

Mục tiêu: để xác định nguyên nhân của việc ghi tăng lên khối lượng gốc (về cơ bản, hãy tìm hiểu xem đó có phải là một quá trình (và quá trình nào), hệ thống tệp (ext4) khác nhau hay vấn đề khác (ví dụ như bộ nhớ)).

Thông tin hệ thống:

• Nền tảng: EC2 của Amazon (t1.micro)
• O / S: Linux's Linux 2011/09 (có nguồn gốc CentOS / RHEL)
• Nhân Linux: 2.6,35,14-97,44.amzn1.i686
• Kiến trúc: 32-bit / i686
• Đĩa: 3 khối EBS:
  • hệ thống tập tin xvdap1, root, ext4 (được gắn với noatime)
  • hệ thống tập tin xvdf, dữ liệu, xfs (được gắn với noatime, usrquota, grpquota)
  • xvdg, trao đổi

Khối lượng gốc và dữ liệu được chụp nhanh mỗi ngày một lần - tuy nhiên, đây phải là thao tác 'đọc', không phải là ghi. (Ngoài ra, thực tế tương tự đã được sử dụng trên máy chủ trước đó - và máy chủ trước đó cũng là một t1.micro.)

Dữ liệu khiến tôi xem xét I / O là chi tiết về hóa đơn AWS cuối cùng của tôi (có I / O bình thường - không bất ngờ, vì tôi đã thiết lập máy chủ này và cài đặt rất nhiều thứ khi bắt đầu của tháng) và sau đó là số liệu CloudWatch cho các tập EBS đính kèm. Tôi đến con số '4 lần bình thường' bằng cách ngoại suy hoạt động i / o từ tháng 11 (khi tôi không thay đổi máy chủ) để ước tính giá trị hàng tháng và so sánh với I / O từ những tháng trước khi tôi không làm việc trên máy chủ trước của tôi. (Tôi không có dữ liệu chính xác từ máy chủ trước của mình). Số lượng ghi tương tự đã tồn tại đến hết tháng 11, 170-330 MB / giờ.

Thông tin chẩn đoán (thời gian hoạt động của các đầu ra sau là 20,6 ngày):

Số liệu của Cloudwatch:

• khối lượng gốc (ghi): 5,5 GB / ngày
• khối lượng gốc (đọc): 60MB / ngày
• khối lượng dữ liệu (ghi): 400MB / ngày
• khối lượng dữ liệu (đọc): 85MB / ngày
• khối lượng trao đổi (ghi): 3MB / ngày
• khối lượng trao đổi (đọc): 2MB / ngày

Đầu ra của: df -h(chỉ cho khối lượng gốc)

Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            4.0G  1.2G  2.8G  31% /

Không gian sử dụng đã không tăng đáng kể kể từ khi hệ thống này được khởi chạy (theo tôi gợi ý rằng các tệp đang được cập nhật, không được tạo / nối thêm).

Đầu ra của: iostat -x(có Blk_read, Blk_wrtnthêm vào):

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

Đầu ra của: 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

Để tóm tắt những điều trên (và ngoại suy thành các giá trị hàng ngày), có vẻ như trong khoảng thời gian 10 phút:

• [flush-202] đã viết 26MB = 3,6GB / ngày
• php-fpm đã viết 17,5 MB = 2,4 GB / ngày
• MySQL đã viết 684KB = 96MB / ngày
• Varnish đã viết 580KB = 82MB / ngày
• [jbd2] đã viết 528KB = 74MB / ngày
• Nginx đã viết 120KB = 17MB / ngày
• Proxy IMAP đã viết 8KB = 1,1 MB / ngày

Thật thú vị, nó sẽ xuất hiện giữa [flush-202]và php-fpmcó thể tính đến khối lượng viết hàng ngày.

Sử dụng ftop, tôi không thể theo dõi flushhoặc php-fpmviết (ví dụ ftop -p php-fpm.

Ít nhất một phần của vấn đề của tôi bắt nguồn từ việc xác định quá trình nào đang ghi vào ổ đĩa gốc. Trong số những liệt kê ở trên, tôi mong chờ tất cả để được văn bản cho khối lượng dữ liệu (từ các thư mục có liên quan được symlinked có) (ví dụ nginx, mysql, php-fpm, varnishdanh bạ tất cả các điểm đến một khối lượng EBS khác nhau)

Tôi tin JBD2là thiết bị chặn nhật ký cho ext4 và flush-202là nền tảng của các trang bẩn. Giá trị dirty_ratiolà 20 và dirty_background_ratiolà 10. Bộ nhớ bẩn (từ /proc/meminfo) thường nằm trong khoảng từ 50-150kB). Kích thước trang ( getconf PAGESIZE) là mặc định hệ thống (4096).

Đầu ra của: vmstat -s | grep paged

3248858 trang phân trang trong 104625313 trang phân trang

Đầu ra của: 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

Ở trên dường như cho thấy một số lượng lớn các trang được phân trang - tuy nhiên, tôi hy vọng rằng các trang sẽ được ghi vào phân vùng trao đổi của tôi nếu cần thiết, không phải cho khối lượng gốc của tôi. Trong tổng số bộ nhớ, hệ thống thường có 35% sử dụng, 10% bộ đệm và 40% được lưu trong bộ nhớ cache, 15% không sử dụng (tức là miễn phí 65%).

Đầu ra của: 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

vmstathiển thị nhất quán sivà sogiá trị 0

Đầu ra của: swapon -s

Filename                                Type            Size    Used    Priority
/dev/xvdg                               partition       1048572 9252    -1

Theo linh cảm rằng ghi I / O có thể liên quan đến bộ nhớ, tôi đã vô hiệu hóa véc ni và máy chủ khởi động lại. Điều này đã thay đổi hồ sơ bộ nhớ của tôi thành 10% khi sử dụng, 2% trong bộ đệm và 20% được lưu trong bộ nhớ cache, 68% không sử dụng (tức là miễn phí 90%). Tuy nhiên, sau hơn 10 phút chạy, iotop đã cho kết quả tương tự như trước đây:

• [flush-202] đã viết 19MB
• php-fpm đã viết 10MB

Trong một giờ kể từ khi khởi động lại, đã có 330 MB được ghi vào ổ đĩa gốc với 370K trang được hoán đổi.

Đầu ra của 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/

Nhìn xa hơn một chút về vấn đề trên, hầu như tất cả các bài viết có thể được quy cho một quy trình (chưa biết) đang chạy cứ sau 5 phút và kiểm tra trạng thái của một loạt các dịch vụ (như chkservdtrên cPanel, nhưng tôi không sử dụng cPanel, và không cài đặt cái này). Nó lên tới 4 tệp nhật ký (cron, maillog, ftp, imapproxy) được cập nhật trong 10 phút - và một vài mục liên quan (ổ cắm postfix, kết nối thuần ftpd). Các mục khác chủ yếu là các phiên ispconfig được sửa đổi, cập nhật kế toán hệ thống và các lần truy cập web không hợp lệ (không tồn tại server_name) (đăng nhập vào / var / log / nginx).

Kết luận và câu hỏi:

Hãy để tôi bắt đầu bằng cách nói rằng tôi hơi bối rối - tôi thường khá kỹ lưỡng, nhưng tôi cảm thấy rằng tôi đang thiếu một cái gì đó rõ ràng trên cái này. Rõ ràng, flushvà php-fpmchiếm phần lớn các bài viết, tuy nhiên, tôi không biết tại sao điều này có thể là trường hợp. Đầu tiên, hãy dùng php-fpm - nó thậm chí không nên ghi vào ổ đĩa gốc. Các thư mục của nó (cả tệp và nhật ký) được liên kết với một khối EBS khác. Thứ hai, những thứ chính mà php-fpm nên viết là các phiên và bộ đệm trang - cả hai và nhỏ - chắc chắn không theo thứ tự 1MB / phút (giống như 1K / phút, nếu vậy). Hầu hết các trang web là chỉ đọc, chỉ có cập nhật thường xuyên. Tổng kích thước của tất cả các tệp web được sửa đổi trong ngày qua là 2,6 MB.

Thứ hai, khi xem xét tuôn ra - việc ghi đáng kể từ nó gợi ý cho tôi rằng các trang bẩn thường xuyên bị xóa vào đĩa - nhưng do tôi thường có bộ nhớ trống 65% và khối lượng EBS riêng cho không gian hoán đổi, tôi không thể giải thích tại sao điều này sẽ ảnh hưởng đến việc ghi vào khối lượng gốc của tôi, đặc biệt là đến mức độ đang xảy ra. Tôi nhận ra rằng một số quy trình sẽ ghi các trang bẩn vào không gian hoán đổi của riêng chúng (thay vì sử dụng không gian hoán đổi hệ thống), nhưng chắc chắn, ngay sau khi khởi động lại với phần lớn bộ nhớ của tôi là miễn phí, tôi không nên chạy vào bất kỳ số lượng đáng kể nào trang bẩn. Nếu bạn tin rằng đây là nguyên nhân, xin vui lòng cho tôi biết làm thế nào tôi có thể xác định quy trình nào được ghi vào không gian hoán đổi của riêng họ.

Hoàn toàn có thể là toàn bộ ý tưởng trang bẩn chỉ đơn giản là một cá trích đỏ và hoàn toàn không liên quan đến vấn đề của tôi (tôi hy vọng nó thực sự). Nếu đó là trường hợp, ý tưởng duy nhất khác của tôi là có một cái gì đó liên quan đến nhật ký ext4 không có trong ext3. Ngoài ra, tôi hiện đang hết ý tưởng.

Cập nhật:

Ngày 6 tháng 11 năm 2011:

Đặt dirty_ratio = 10và dirty_background_ratio = 5; cập nhật với sysctl -p(xác nhận qua / Proc); chạy thử nghiệm iotop 10 phút với kết quả tương tự (tuôn ra 17 MB, php-fpm đã viết 16 MB, MySQL viết 1 MB và JBD2 viết 0,7 MB).

Tôi đã thay đổi tất cả các liên kết tượng trưng mà tôi thiết lập để sử dụng mount --bindthay thế. Kích hoạt lại véc ni, máy chủ khởi động lại; chạy thử nghiệm iotop 10 phút với kết quả tương tự (tuôn ra 12,5 MB, php-fpm viết 11,5 MB, Varnish viết 0,5 MB, JBD2 viết 0,5 MB và MySQL viết 0,3 MB).

Như ở lần chạy trên, hồ sơ bộ nhớ của tôi được sử dụng 20%, bộ đệm 2% và bộ nhớ cache 58%, không sử dụng 20% ​​(tức là miễn phí 80%) Chỉ trong trường hợp tôi giải thích bộ nhớ trống, trong ngữ cảnh này, là thiếu sót, đây là đầu ra của free -m(đây là một t1.micro). tổng số bộ đệm chia sẻ miễn phí được sử dụng được lưu trong bộ nhớ cache Mem: 602 478 124 0 14 347 - / + bộ đệm / bộ đệm: 116 486 Hoán đổi: 1023 0 1023

Một số thông tin bổ sung: Đầu ra của: 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)

Tôi cũng đã chạy ftop và iotop cùng một lúc, và rất ngạc nhiên khi nhận thấy rằng các mục hiển thị trong iotop, không xuất hiện trong ftop. Danh sách ftop đã được lọc thành php-fpm, vì tôi có thể kích hoạt ghi quá trình đó một cách khá đáng tin cậy. Tôi đã lưu ý về 2 MB lượt ghi trên mỗi lượt xem trang cho php-fpm - và tôi vẫn chưa tìm ra những gì nó có thể viết - bất kỳ ý tưởng nào về việc xác định những gì được viết sẽ được đánh giá cao.

Tôi sẽ cố gắng tắt nhật ký trong vài ngày tới, và xem điều đó có cải thiện mọi thứ không. Hiện tại, tôi thấy mình băn khoăn không biết mình có vấn đề I / O hay vấn đề bộ nhớ (hoặc cả hai) - nhưng tôi gặp khó khăn khi nhìn thấy vấn đề bộ nhớ, nếu có.

Ngày 13 tháng 11 năm 2011:

Vì hệ thống tệp sử dụng phạm vi, nên không thể gắn kết nó dưới dạng ext3, ngoài ra, cố gắng gắn kết nó dưới dạng chỉ đọc, chỉ đơn giản là kết quả là nó được đọc lại dưới dạng đọc-ghi.

Hệ thống tập tin thực sự đã kích hoạt tính năng ghi nhật ký (tạp chí 128 MB), như đã thấy rõ sau đây:

Đầu ra của: 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

Theo như sau, khoảng 140 GB đã được ghi vào ổ đĩa này trong một chút dưới một tháng - chỉ khoảng 5 GB / ngày.

Đầu ra của: 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

Tiếp tục tìm kiếm các tệp đang mở, tôi đã thử sử dụng fusertrên ổ đĩa gốc:

Đầu ra của: 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

Không có gì bất ngờ, thật không may. Nếu không may là do phần cứng cơ bản, tôi đã khôi phục ảnh chụp nhanh của khối lượng gốc ngày hôm qua (không có gì thay đổi trong ngày hôm trước) và thay thế âm lượng gốc của cá thể bằng cái mới. Như mong đợi, điều này không có tác dụng đối với vấn đề.

Bước tiếp theo của tôi sẽ là loại bỏ nhật ký, tuy nhiên tôi đã tình cờ tìm ra giải pháp trước khi đến đó.

Vấn đề nằm ở APC khi sử dụng mmap dựa trên tệp. Sửa lỗi đĩa bị mất i / o khoảng 35 lần - thành (ước tính) 150MB / ngày (thay vì 5GB). Tôi vẫn có thể xem xét xóa nhật ký vì điều này dường như là đóng góp chính còn lại cho giá trị này, tuy nhiên, con số này hoàn toàn có thể chấp nhận được trong thời điểm hiện tại. Các bước thực hiện để đi đến kết luận APC được đăng trong câu trả lời, bên dưới.

Vì nguyên nhân hàng đầu dường như là viết nhật ký, đó sẽ là bước tiếp theo của tôi. Tuy nhiên, để xóa nhật ký, tôi cần phải gắn âm lượng EBS vào một thể hiện khác. Tôi đã quyết định kiểm tra quy trình bằng cách sử dụng ảnh chụp nhanh (ngày cũ), tuy nhiên, trước khi xóa nhật ký, tôi đã chạy lại bài kiểm tra iotop 10 phút (trong ví dụ kiểm tra). Thật ngạc nhiên, tôi thấy các giá trị bình thường (tức là không tăng) và đây là lần đầu tiên flush-202thậm chí không xuất hiện trong danh sách. Đây là một ví dụ đầy đủ chức năng (tôi cũng đã khôi phục ảnh chụp nhanh dữ liệu của mình) - không có thay đổi nào đối với âm lượng gốc trong 12 giờ hoặc lâu hơn kể từ khi nó được thực hiện. Tất cả các thử nghiệm cho thấy các quy trình tương tự đang chạy trên cả hai máy chủ. Điều này khiến tôi tin rằng nguyên nhân phải xuất phát từ một số yêu cầu mà máy chủ 'sống' đang xử lý.

Nhìn vào sự khác biệt giữa các đầu ra iotop của máy chủ hiển thị vấn đề và máy chủ dường như giống hệt nhau không có vấn đề, sự khác biệt duy nhất là flush-202và php-fpm. Điều này khiến tôi nghĩ rằng, trong khi một cú sút xa, có lẽ đó là một vấn đề liên quan đến cấu hình PHP.

Bây giờ, phần này không lý tưởng - nhưng vì không có dịch vụ nào chạy trên máy chủ trực tiếp sẽ bị một vài phút ngừng hoạt động nên nó không thực sự quan trọng. Để thu hẹp vấn đề, tất cả các dịch vụ chính (postfix, dovecot, imapproxy, nginx, php-fpm, véc ni, mysqld, var Vecncsa) trên máy chủ trực tiếp đã bị dừng và chạy thử iotop . Các dịch vụ đã được khởi động lại trong 3 đợt, để lại php-fpm cho đến khi kết thúc. Sau mỗi đợt khởi động lại, thử nghiệm iotop xác nhận rằng không có vấn đề gì. Khi php-fpm được bắt đầu, vấn đề được trả về. (Nó có thể đủ dễ dàng để mô phỏng một vài yêu cầu PHP trên máy chủ thử nghiệm, nhưng tại thời điểm này, tôi không chắc chắn đó thực sự là PHP).

Thật không may, máy chủ sẽ khá vô nghĩa nếu không có PHP, vì vậy đây không phải là một kết luận lý tưởng. Tuy nhiên, vì flush-202dường như đề xuất một cái gì đó liên quan đến bộ nhớ (mặc dù có bộ nhớ trống lớn), tôi đã quyết định vô hiệu hóa APC. Chạy lại kiểm tra iotop cho thấy mức i / o của đĩa là bình thường. Quan sát kỹ hơn vấn đề cho thấy mmap đã được bật và apc.mmap_file_maskđược đặt thành /tmp/apc.XXXXXX(mặc định cho cài đặt này). Đường dẫn đó đặt APC để sử dụng mmap được hỗ trợ tệp. Chỉ cần bình luận dòng này (do đó sử dụng mặc định - được hỗ trợ bộ nhớ ẩn danh) và chạy lại kiểm tra iotop cho thấy vấn đề đã được giải quyết.

Tôi vẫn không biết tại sao không có chẩn đoán nào chạy không xác định được ghi là đến từ php và đi đến các tệp apc trong thư mục / tmp. Thử nghiệm duy nhất thậm chí đề cập đến thư mục / tmp là lsof, tuy nhiên, các tệp mà nó liệt kê là không tồn tại.