5,5 GB zapisywane codziennie do głównego woluminu 1,2 GB - 4 razy poprzednie poziomy

Problem: Niedawno odnowiłem jeden z moich serwerów, został przetestowany przed użyciem i działa dobrze, jednak kilka dni temu zauważyłem około 4 razy więcej niż zwykle zapisuje do woluminu głównego. To nie jest problem z wydajnością - serwer działa dobrze.

Moja modernizacja była dość obszerna (pełna przebudowa), więc nie mam wiele do zrobienia pod względem przyczyny. W skrócie, moje zmiany obejmowały:

• Aktualizacja Linux-a Amazon (od 2011.02 do 2011.09) - co również spowodowało zmianę z ext3 na ext4 dla woluminu root
• Przejście z php-fcgi na php-fpm (obecnie używa tcp)
• Przechodzenie z konfiguracji odwrotnego proxy (nginx -> apache), tylko do nginx
• Zastąpienie vsftpd czystym ftpd
• Zastąpienie dkim-proxy opendkim
• Zamiana webmina na ispconfig
• Dodanie lakieru jako warstwy pamięci podręcznej dla plików dynamicznych (przesada w stosunku do liczby odsłon tych witryn, ale to eksperyment)
• Dodanie partycji wymiany

Podstawowe ustawienia:

• Moja przestrzeń wymiany jest zamontowany na własnej objętości EBS - The zapisuje wolumenu wymiany są znikome - Mam zasadniczo dyskontowane to jako przyczynę (istnieje wystarczająca ilość wolnej pamięci - i oba freei iostatwykazują minimalne zużycie wymiany).
• Moje dane (baza danych mysql, pliki użytkownika (strony internetowe), wszystkie dzienniki (z / var / log), poczta i pliki lakierów na własnym wolumenie EBS (za pomocą mount --bind). Podstawowy wolumin EBS jest montowany na/mnt/data
• Moje pozostałe pliki - system operacyjny i podstawowe aplikacje serwera (np. Nginx, postfix, dovecot itp.) - są jedynymi rzeczami w woluminie głównym - łącznie 1,2 GB.

Nowa konfiguracja działa „płynniej” (szybciej, mniej pamięci itp.) Niż stary system i jest stabilna przez 20 dni (połowa października) - o ile wiem, podwyższone zapisy istniały przez cały ten czas .

Wbrew oczekiwaniom mam niski wolumin odczytu (moje odczyty stanowią około 1,5% moich zapisów, zarówno pod względem bloków, jak i bajtów w woluminie głównym). W ciągu ostatnich kilku dni nic nie zmieniłem w woluminie głównym (np. Nowe instalacje itp.), Ale wolumen zapisu nadal jest znacznie wyższy niż oczekiwano.

Cel: ustalenie przyczyny zwiększonego zapisu w woluminie głównym (w zasadzie, dowiedz się, czy jest to proces (i jaki proces), inny system plików (ext4) lub inny problem (np. Pamięć)).

Informacje o systemie:

• Platforma: Amazon's EC2 (t1.micro)
• O / S: Amazon's Linux 2011.09 (pochodzący z CentOS / RHEL)
• Jądro Linux: 2.6.35.14-97.44.amzn1.i686
• Architektura: 32-bit / i686
• Dyski: 3 woluminy EBS:
  • system plików xvdap1, root, ext4 (montowany z Noatime)
  • xvdf, dane, system plików xfs (montowany z noatime, usrquota, grpquota)
  • xvdg, zamiana

Rdzenie i woluminy danych są migawki raz dziennie - jednak powinna to być operacja „odczytu”, a nie zapisu. (Dodatkowo ta sama praktyka została zastosowana na poprzednim serwerze - a poprzedni serwer był również t1.micro.)

Dane, które spowodowały, że zajrzałem do I / O, były w szczegółach mojego ostatniego rachunku AWS (który miał powyżej normalnego I / O - nie było niespodzianki, ponieważ konfigurowałem ten serwer i instalowałem wiele rzeczy na początku miesiąca), a następnie według danych CloudWatch dla dołączonych woluminów EBS. Dochodzę do wartości „4 razy normalna”, ekstrapolując aktywność we / wy z listopada (kiedy nie zmieniłem serwera) w celu oszacowania wartości miesięcznej i porównując ją z operacjami we / wy z poprzednich miesięcy, kiedy nie pracowałem na moim poprzednim serwerze. (Nie mam dokładnych danych iostat z mojego poprzedniego serwera). Ta sama ilość zapisów utrzymała się do listopada, 170-330 MB / godz.

Informacje diagnostyczne (czas przestoju dla następujących wyjść wynosi 20,6 dni):

Dane Cloudwatch:

• wolumin główny (zapis): 5,5 GB / dzień
• wolumin główny (odczyt): 60 MB / dzień
• objętość danych (zapis): 400 MB / dzień
• objętość danych (odczyt): 85 MB / dzień
• Zamiana objętości (zapis): 3 MB / dzień
• Zamień głośność (odczyt): 2 MB / dzień

Wyjście: df -h(tylko dla woluminu głównego)

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

Wykorzystane miejsce nie wzrosło zauważalnie od momentu uruchomienia tego systemu (co sugeruje mi, że pliki są aktualizowane, a nie tworzone / dołączane).

Wyjście: iostat -x(z Blk_read, Blk_wrtndodane):

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

Wyjście: 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

Podsumowując powyższe (i ekstrapolując do wartości dziennych), wygląda to tak w okresie 10 minut:

• [flush-202] napisał 26 MB = 3,6 GB / dzień
• php-fpm napisał 17,5 MB = 2,4 GB / dzień
• MySQL napisał 684 KB = 96 MB / dzień
• Lakier napisał 580 KB = 82 MB / dzień
• [jbd2] napisał 528 KB = 74 MB / dzień
• Nginx napisał 120 KB = 17 MB / dzień
• Serwer proxy IMAP napisał 8 KB = 1,1 MB / dzień

Co ciekawe, wydaje się, że pomiędzy [flush-202]i php-fpmmożna uwzględnić dzienną liczbę zapisów.

Używając ftop, nie jestem w stanie wyśledzić ani, flushani php-fpmpisze (np ftop -p php-fpm.

Przynajmniej część mojego problemu wynika ze zidentyfikowania, które procesy zapisują do woluminu głównego. Spośród wymienionych powyżej, spodziewam wszystko się pisemnie do ilości danych (ponieważ odpowiednie katalogi są tam dowiązane) (na przykład nginx, mysql, php-fpm, varnishkatalogi wszystko wskazuje na inny wolumin EBS)

Uważam, że JBD2jest urządzeniem blokującym kronikowanie dla ext4 i flush-202stanowi tło brudnych stron. dirty_ratio20 i dirty_background_ratiojest 10 Brudna pamięci (z /proc/meminfo), to typowo od 50-150kB). Rozmiar strony ( getconf PAGESIZE) jest ustawieniem domyślnym systemu (4096).

Wyjście: vmstat -s | grep paged

3248858 stron stronicowanych w 104625313 stronicowanych stronach

Wyjście: 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

Powyższe wydaje się sugerować dużą liczbę stron stronicowanych - spodziewam się jednak, że strony zostaną zapisane na mojej partycji wymiany, jeśli to konieczne, a nie na moim głównym woluminie. Z całej pamięci system zwykle ma 35% w użyciu, 10% w buforach i 40% w pamięci podręcznej, 15% nieużywane (tj. 65% wolne).

Wyjście: 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

vmstatkonsekwentnie wyświetla sii sowartości 0

Wyjście: swapon -s

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

Na przeczucie, że operacje we / wy mogą być związane z pamięcią, wyłączyłem lakier i zrestartowałem serwer. To zmieniło mój profil pamięci na 10% w użyciu, 2% w buforach i 20% w pamięci podręcznej, 68% nieużywane (tj. 90% za darmo). Jednak w ciągu 10 minut pracy iotop dał podobne wyniki jak poprzednio:

• [flush-202] napisał 19 MB
• php-fpm napisał 10 MB

W ciągu godziny od ponownego uruchomienia do woluminu głównego zapisano już 330 MB, a stron zamieniono na 370 000.

Wyjście z 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/

Patrząc nieco dalej, prawie wszystkie zapisy można przypisać (nieznanemu) procesowi, który jest uruchamiany co 5 minut i sprawdza status różnych usług (jak chkservdna cPanel, ale nie używam cPanel, i nie zainstalowałem tego). Jest to 4 pliki dziennika (cron, maillog, ftp, imapproxy) zaktualizowane w ciągu 10 minut - oraz kilka powiązanych elementów (gniazda Postfix, połączenia pure-ftpd). Pozostałe elementy to przede wszystkim zmodyfikowane sesje ispconfig, aktualizacje księgowości systemu i nieprawidłowe (nieistniejące nazwa_serwera) próby dostępu do sieci (zalogowane do / var / log / nginx).

Wnioski i pytania:

Zacznę od stwierdzenia, że ​​jestem trochę zakłopotany - zazwyczaj jestem dość dokładny, ale wydaje mi się, że brakuje mi czegoś oczywistego w tym temacie. Oczywiście flushi php-fpmrozliczam się z większością zapisów, nie wiem jednak, dlaczego tak się dzieje. Po pierwsze, weźmy php-fpm - nie powinno nawet pisać do woluminu głównego. Jego katalogi (zarówno pliki, jak i dzienniki) są dowiązane symbolicznie do innego wolumenu EBS. Po drugie, podstawowe rzeczy, które powinien pisać php-fpm, to sesje i pamięci podręczne stron - które są nieliczne i małe - na pewno nie rzędu 1 MB / min (bardziej jak 1 K / min, jeśli to). Większość witryn jest tylko do odczytu, z okazjonalnymi aktualizacjami. Całkowity rozmiar wszystkich plików internetowych zmodyfikowanych w ostatnim dniu wynosi 2,6 MB.

Po drugie, biorąc pod uwagę flush - znaczące zapisy z niego sugerują mi, że brudne strony są często opróżniane na dysk - ale biorąc pod uwagę, że zazwyczaj mam 65% wolnej pamięci i oddzielny wolumin EBS dla przestrzeni wymiany, nie mogę wyjaśnić, dlaczego wpływać na zapisy w moim głównym woluminie, szczególnie w takim stopniu, w jakim się to dzieje. Zdaję sobie sprawę z tego, że niektóre procesy zapisują brudne strony w swoim własnym obszarze wymiany (zamiast korzystać z systemowego obszaru wymiany), ale z pewnością natychmiast po ponownym uruchomieniu z ogromną większością mojej pamięci jest wolna, nie powinienem być narażony na znaczną ilość brudne strony. Jeśli uważasz, że to jest przyczyną, daj mi znać, jak mogę określić, które procesy zapisują w swojej przestrzeni wymiany.

Całkiem możliwe, że cały pomysł na brudne strony jest po prostu czerwonym śledziem i jest całkowicie niezwiązany z moim problemem (mam nadzieję, że tak naprawdę jest). Jeśli tak jest, moim jedynym innym pomysłem, że istnieje coś związanego z kronikowaniem ext4, którego nie było w ext3. Poza tym obecnie brakuje mi pomysłów.

Aktualizacje:

6 listopada 2011:

Ustaw dirty_ratio = 10i dirty_background_ratio = 5; zaktualizowane o sysctl -p(potwierdzone przez / proc); reran 10-minutowy test iotop z podobnymi wynikami (flush napisał 17 MB, php-fpm napisał 16 MB, MySQL napisał 1 MB, a JBD2 napisał 0,7 MB).

mount --bindZamiast tego zmieniłem wszystkie dowiązania symboliczne, które skonfigurowałem . Ponownie włączony lakier, zrestartowany serwer; reran 10-minutowy test iotop z podobnymi wynikami (flush napisał 12,5 MB, php-fpm 11,5 MB, Varnish 0,5 MB, JBD2 0,5 MB, a MySQL 0,3 MB).

Jak w powyższym przebiegu, mój profil pamięci był w użyciu 20%, 2% w buforach i 58% w pamięci podręcznej, 20% nieużywane (tj. 80% wolne) Na wszelki wypadek moja interpretacja wolnej pamięci w tym kontekście jest błędna, oto wynik działania free -m(to jest t1.micro). Łącznie wykorzystane wolne buforowane bufory współdzielone Mem: 602478 124 0 14 347 - / + Bufory / pamięć podręczna: 116 486 Zamień: 1023 0 1023

Kilka dodatkowych informacji: Dane wyjściowe: 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)

Uruchomiłem jednocześnie ftop i iotop i z zaskoczeniem zauważyłem, że wpisy wyświetlane w iotop nie pojawiły się w ftop. Lista ftop została przefiltrowana do php-fpm, ponieważ mogłem dość niezawodnie wywoływać zapisy tego procesu. Zauważyłem około 2 MB zapisów na wyświetlenie strony dla php-fpm - i muszę jeszcze dowiedzieć się, co to może być pisanie - mile widziane będą wszelkie pomysły na ustalenie, co jest pisane.

Spróbuję wyłączyć dziennikarstwo w ciągu kilku najbliższych dni i zobaczę, czy to poprawi sytuację. W tej chwili zastanawiam się, czy mam problem z wejściem / wyjściem, czy z pamięcią (lub z obydwoma) - ale trudno mi dostrzec problem z pamięcią, jeśli taki występuje.

13 listopada 2011:

Ponieważ system plików korzysta z zakresów, nie było możliwe zamontowanie go jako ext3, dodatkowo próba zamontowania go jako tylko do odczytu, po prostu spowodowała, że ​​został on ponownie zamontowany jako odczyt-zapis.

System plików rzeczywiście ma włączone kronikowanie (kronika 128 MB), co wynika z następujących informacji:

Wyjście: 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

Jak podano poniżej, około 140 GB zostało zapisanych w tym tomie w nieco mniej niż miesiąc - zaledwie około 5 GB dziennie.

Wyjście: 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

Kontynuując wyszukiwanie otwartych plików, próbowałem użyć fuserwoluminu głównego:

Wyjście: 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

Niestety nic nieoczekiwanego. Na przypadek, że było to spowodowane sprzętem, przywróciłem wczorajszą migawkę woluminu głównego (nic się nie zmieniło w ostatnim dniu) i zastąpiłem wolumin główny instancji nowym. Zgodnie z oczekiwaniami nie miało to wpływu na problem.

Moim następnym krokiem byłoby usunięcie dzienników, jednak natknąłem się na rozwiązanie, zanim do tego doszedłem.

Problem leżał w APC przy użyciu mmapa z kopią pliku. Naprawienie upuszczonego dysku we / wy o około 35x - do (szacunkowo) 150 MB / dzień (zamiast 5 GB). Nadal mogę rozważyć usunięcie dzienników, ponieważ wydaje się, że jest to główny pozostały czynnik przyczyniający się do tej wartości, jednak liczba ta jest na razie do przyjęcia. Kroki podjęte w celu dojścia do wniosku APC zamieszczono w odpowiedzi poniżej.

Ponieważ główną przyczyną wydawało się prowadzenie dziennika, byłby to mój kolejny krok. Aby jednak usunąć kronikowanie, musiałbym dołączyć wolumin EBS do innej instancji. Postanowiłem przetestować tę procedurę przy użyciu migawki (starej), jednak przed usunięciem kronikowania ponownie uruchomiłem 10-minutowy test iotop (na instancji testowej). Ku mojemu zdziwieniu zobaczyłem normalne (tj. Nie podwyższone) wartości i po raz pierwszy flush-202nawet nie pojawił się na liście. To była w pełni funkcjonalna instancja (przywróciłem również migawki moich danych) - w ciągu około 12 godzin nie było żadnych zmian w woluminie głównym. Wszystkie testy wykazały, że te same procesy działały na obu serwerach. Doprowadziło mnie to do przekonania, że ​​przyczyną muszą być niektóre żądania, które przetwarza serwer „na żywo”.

Patrząc na różnice między wyjściami iotop serwera wyświetlającego problem a pozornie identycznym serwerem, który nie miał problemu, jedynymi różnicami były flush-202i php-fpm. To sprawiło, że pomyślałem, że choć z daleka, być może był to problem związany z konfiguracją PHP.

Ta część nie była idealna - ale ponieważ żadna z usług działających na serwerze na żywo nie ucierpiałaby z powodu kilku minut przestoju, nie miało to tak naprawdę znaczenia. Aby zawęzić problem, wszystkie główne usługi (postfix, dovecot, imapproxy, nginx, php-fpm, lakier, mysqld, varnishncsa) na serwerze na żywo zostały zatrzymane i ponownie uruchomiono test iotop - nie było podniesionego dysku we / wy . Usługi uruchomiono ponownie w 3 partiach, pozostawiając php-fpm do końca. Po każdej partii restartów test iotop potwierdził, że nie wystąpił problem. Po uruchomieniu php-fpm problem powrócił. (Łatwo byłoby zasymulować kilka żądań PHP na serwerze testowym, ale w tym momencie nie byłem pewien, czy to rzeczywiście PHP).

Niestety serwer bez PHP byłby bezcelowy, więc nie był to idealny wniosek. Ponieważ jednak flush-202wydawało się sugerować coś związanego z pamięcią (pomimo dużej ilości wolnej pamięci), postanowiłem wyłączyć APC. Ponowne uruchomienie testu iotop wykazało, że poziomy we / wy dysku były prawidłowe. Bliższe przyjrzenie się tej sprawie wykazało, że mmap jest włączony i apc.mmap_file_maskustawiony na /tmp/apc.XXXXXX(domyślny dla tej instalacji). Ścieżka ta ustawia APC na użycie mmapa zabezpieczonego plikiem. Samo skomentowanie tego wiersza (a więc użycie domyślnej - kopii zapasowej pamięci anonimowej) i ponowne uruchomienie testu iotop pokazało, że problem został rozwiązany.

Nadal nie wiem, dlaczego żaden z testów diagnostycznych nie zidentyfikował zapisu jako pochodzącego z php i przechodzącego do plików apc w katalogu / tmp. Jedynym testem, który wspomniał nawet o katalogu / tmp, były lsofjednak pliki, które wymienił, nie istniały.