5,5 ГБ записывается ежедневно в корневой объем 1,2 ГБ - в 4 раза больше предыдущих уровней

Проблема: я недавно обновил один из своих серверов, он был протестирован перед использованием и хорошо функционирует, однако несколько дней назад я заметил примерно в 4 раза больше обычного количества записей в корневой том. Это не проблема производительности - сервер работает нормально.

Моя модернизация была довольно обширной (полная перестройка), поэтому мне не о чем рассказывать причину. Вкратце мои изменения включали:

• Обновление Amazon Linux (с 2011.02 по 2011.09), что также привело к изменению с ext3 на ext4 для корневого тома
• Переход от php-fcgi к php-fpm (в настоящее время используется tcp)
• Переход от настройки обратного прокси (nginx -> apache) только к nginx
• Замена vsftpd на чистый ftpd
• Замена dkim-прокси на opendkim
• Замена webmin на ispconfig
• Добавление лака в качестве слоя кеширования для динамических файлов (избыточное количество обращений к этим сайтам, но это эксперимент)
• Добавление раздела подкачки

Базовая настройка:

• Мой раздел подкачки установлен на своем собственном объеме EBS - то записывает в объем подкачки незначительны - я , по существу , дисконтированных это как причина (имеется достаточно свободной памяти - и как freeи iostatпоказывают минимальное использование свопа).
• Мои данные (база данных mysql, пользовательские файлы (веб-сайты), все журналы (из / var / log), файлы почты и лаки на их собственном томе EBS (используется mount --bind). Базовый том EBS смонтирован в/mnt/data
• Мои оставшиеся файлы - приложения операционной системы и главного сервера (например, nginx, postfix, dovecot и т. Д.) - единственные на корневом томе - всего 1,2 ГБ.

Новая установка работает «плавнее» (быстрее, меньше памяти и т. Д.), Чем старая система, и была стабильной в течение 20 дней (середина октября) - насколько я могу судить, повышенные записи существовали все это время ,

Вопреки тому, что я ожидал, у меня низкий объем чтения (мои чтения составляют около 1,5% моих записей, как с точки зрения блоков, так и байтов на моем корневом томе). За последние несколько дней я ничего не менял в корневом томе (например, новые установки и т. Д.), Но объем записи по-прежнему намного выше ожидаемого.

Цель: определить причину увеличения числа записей в корневом томе (по сути, выяснить, является ли это процессом (и каким процессом), другой (ext4) файловой системой или другой проблемой (например, памятью)).

Системная информация:

• Платформа: Amazon EC2 (t1.micro)
• O / S: Amazon's Linux 2011.09 (производная от CentOS / RHEL)
• Ядро Linux: 2.6.35.14-97.44.amzn1.i686
• Архитектура: 32-битная / i686
• Диски: 3 тома EBS:
  • файловая система xvdap1, root, ext4 (смонтирована с noatime)
  • xvdf, данные, файловая система xfs (смонтированы с noatime, usrquota, grpquota)
  • xvdg, своп

Корневой том и данные копируются один раз в день, однако это должна быть операция чтения, а не запись. (Кроме того, такая же практика использовалась на предыдущем сервере - и предыдущий сервер также был t1.micro.)

Данные, которые побудили меня взглянуть на ввод-вывод, были в деталях моего последнего счета AWS (который был выше обычного ввода-вывода - не удивительно, так как я настраивал этот сервер и устанавливал много вещей в начале) месяца), а затем в метриках CloudWatch для подключенных томов EBS. Я прихожу к показателю «в 4 раза больше нормального», экстраполируя активность ввода-вывода с ноября (когда я не изменял сервер), чтобы оценить ежемесячное значение и сравнивая его с данными ввода-вывода прошлых месяцев, когда я не работал на моем предыдущем сервере. (У меня нет точных данных iostat с моего предыдущего сервера). Такое же количество записей сохранялось до ноября 170-330 МБ / час.

Диагностическая информация (время безотказной работы для следующих выходов составляет 20,6 дня):

Метрики Cloudwatch:

• Корневой том (запись): 5,5 ГБ / день
• Корневой том (читай): 60 МБ / день
• объем данных (запись): 400 МБ / день
• объем данных (чтение): 85 МБ / день
• объем подкачки (запись): 3MB / день
• объем подкачки (читай): 2 МБ / день

Вывод: 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 / день
• php-fpm написал 17.5MB = 2.4GB / день
• MySQL написал 684 КБ = 96 МБ / день
• Лак написал 580KB = 82MB / день
• [jbd2] написал 528KB = 74MB / день
• Nginx написал 120KB = 17MB / день
• IMAP Proxy написал 8 КБ = 1,1 МБ / день

Интересно, что между [flush-202]и php-fpmможно учитывать ежедневный объем записей.

Используя ftop, я не могу отследить ни flushили php-fpmпишет (например ftop -p php-fpm.

По крайней мере, часть моей проблемы связана с определением того, какие процессы записывают в корневой том. Из тех , которые перечислены выше, я бы ожидать , что все будет писать к объему данных (поскольку соответствующие каталоги слинкован там) (например nginx, mysql, php-fpm, varnishкаталоги указывают на другом томе EBS)

Я полагаю, JBD2что это устройство блочного журналирования для ext4 и flush-202фоновый поток грязных страниц. Значение dirty_ratioравно 20, а значение dirty_background_ratioравно 10. Грязная память (от /proc/meminfo) обычно составляет от 50 до 150 кБ). Размер страницы ( getconf PAGESIZE) - это системное значение по умолчанию (4096).

Выход: vmstat -s | grep paged

3248858 страниц, разбитых на 104625313 страниц, разбитых на страницы

Выход: 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и soзначения 0

Выход: swapon -s

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

Если предположить, что записи ввода / вывода могут быть связаны с памятью, я отключил лак и перезапустил сервер. Это изменило мой профиль памяти на 10% при использовании, 2% в буферах и 20% в кеше, 68% неиспользованных (т.е. 90% свободных). Тем не менее, за 10 минут, iotop дал результаты, аналогичные ранее:

• [flush-202] написал 19MB
• php-fpm написал 10MB

За час после перезагрузки в корневой том уже было записано 330 МБ, а выгружено 370 КБ страниц.

Выход из 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 минут и проверяет состояние различных служб (например, chkservdна cPanel, но я не использую cPanel, и не установил это). Он состоит из 4 файлов журнала (cron, maillog, ftp, imapproxy), обновленных в течение 10 минут, и нескольких связанных элементов (постфиксные сокеты, соединения чистого ftpd). Другие элементы - это в основном измененные сеансы ispconfig, обновления системы учета и недопустимые (несуществующие имя_сервера) попытки веб-доступа (записанные в / var / log / nginx).

Выводы и вопросы:

Позвольте мне начать с того, что я немного озадачен - обычно я достаточно тщателен, но чувствую, что упускаю что-то очевидное в этом. Очевидно, что flushи php-fpmприходится основная часть записи, однако, я не знаю , почему это может быть дело. Во-первых, давайте возьмем php-fpm - он даже не должен писать в корневой том. Его каталоги (и файлы, и журналы) связаны с другим томом EBS. Во-вторых, основными вещами, которые php-fpm должен писать, являются сессии и кэши страниц - которые бывают как небольшими, так и небольшими - конечно, не порядка 1 МБ / мин (больше похоже на 1 КБ / мин, если таковой). Большинство сайтов доступны только для чтения, и только изредка обновляются. Общий размер всех веб-файлов, измененных за последний день, составляет 2,6 МБ.

Во-вторых, с учетом сброса - значимые записи из него предполагают, что грязные страницы часто сбрасываются на диск - но, учитывая, что у меня обычно есть 65% свободной памяти и отдельный том EBS для пространства подкачки, я не могу объяснить, почему это влияет на записи в моем корневом томе, особенно в той степени, в которой это происходит. Я понимаю, что некоторые процессы будут записывать грязные страницы в свое собственное пространство подкачки (вместо использования системного пространства подкачки), но, конечно же, сразу после перезапуска, когда подавляющее большинство моей памяти свободно, я не должен запускаться в какое-либо существенное грязные страницы. Если вы считаете, что это является причиной, пожалуйста, дайте мне знать, как я могу определить, какие процессы записывают в свое собственное пространство подкачки.

Вполне возможно, что вся идея «грязных страниц» - просто красная сельдь и совершенно не связана с моей проблемой (надеюсь, что это действительно так). Если это так, моя единственная другая идея, что есть что-то, связанное с журналированием ext4, которого не было в ext3. Кроме того, у меня сейчас нет идей.

Обновление (ы):

6 ноября 2011 г .:

Установить dirty_ratio = 10и dirty_background_ratio = 5; обновляется с sysctl -pпомощью (подтверждено через / proc); перезапустить 10-минутный тест iotop с похожими результатами (flush написал 17MB, php-fpm написал 16MB, MySQL написал 1MB, а JBD2 написал 0.7MB).

Я изменил все символические ссылки, которые я установил, чтобы использовать mount --bindвместо этого. Повторно включен лак, перезапущен сервер; перезапустить 10-минутный тест iotop с похожими результатами (flush написал 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: 602 478 124 0 14 347 - / + буферов / кэш: 116 486 Обмен: 1023 0 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, поскольку я мог достаточно надежно инициировать записи этого процесса. Я отметил около 2 МБ записей на просмотр страницы для php-fpm - и мне еще предстоит выяснить, что он может писать - любые идеи по выяснению того, что пишется, будут оценены.

Я постараюсь отключить ведение журнала в ближайшие несколько дней и посмотреть, улучшится ли это. На данный момент я задаюсь вопросом, есть ли у меня проблема ввода-вывода или проблемы с памятью (или и то, и другое) - но мне трудно увидеть проблему с памятью, если она есть.

13 ноября 2011 г .:

Поскольку файловая система использует экстенты, было невозможно смонтировать его как ext3, кроме того, попытки монтировать его как доступный только для чтения, просто привели к его повторному подключению как чтение-запись.

В файловой системе действительно включено журналирование (журнал 128 МБ), как видно из следующего:

Выход: 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

Согласно следующему, около 140 ГБ было записано на этот том чуть менее чем за месяц - всего около 5 ГБ / день.

Выход: 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

К сожалению, ничего неожиданного. На случай, если это произошло из-за аппаратного обеспечения, я восстановил вчерашний снимок корневого тома (ничего не изменилось за последний день) и заменил корневой том экземпляра новым. Как и ожидалось, это не повлияло на проблему.

Моим следующим шагом было бы удалить журналирование, однако я наткнулся на решение, прежде чем перейти к этому.

Проблема заключалась в APC с использованием файла mmap. Исправление сброшенного дискового ввода-вывода примерно в 35 раз - до (примерно) 150 МБ / день (вместо 5 ГБ). Я мог бы все еще рассмотреть удаление журналирования, поскольку это, кажется, основной оставшийся вклад в это значение, однако, это число вполне приемлемо в настоящее время. Шаги, предпринятые для получения заключения APC, опубликованы в ответе ниже.

Поскольку главной причиной, казалось, было ведение дневника, это был бы мой следующий шаг. Однако, чтобы удалить ведение журнала, мне нужно подключить том EBS к другому экземпляру. Я решил протестировать процедуру с использованием (дневного) снимка, однако перед удалением ведения журнала я повторно запустил 10-минутный тест iotop (на экземпляре теста). К моему удивлению, я увидел нормальные (то есть не повышенные) значения, и это был первый раз, который flush-202даже не появился в списке. Это был полностью функциональный экземпляр (я также восстановил моментальные снимки своих данных) - за 12 часов или около того с момента его создания изменений в корневом томе не было. Все тесты показали, что на обоих серверах выполнялись одинаковые процессы. Это заставило меня поверить, что причина кроется в некоторых запросах, которые обрабатывает «живой» сервер.

Глядя на различия между iotop выходами сервера отображаются проблемы и , казалось бы , идентичный сервер , который не имел никаких проблем, только различия были flush-202и php-fpm. Это заставило меня задуматься о том, что, возможно, это была проблема, связанная с конфигурацией PHP.

Теперь эта часть не была идеальной - но поскольку ни одна из служб, работающих на работающем сервере, не пострадает от нескольких минут простоя, это не имело значения. Чтобы сузить проблему, все основные сервисы (postfix, dovecot, imapproxy, nginx, php-fpm, varnish, mysqld, varnishncsa) на работающем сервере были остановлены, а тест iotop перезапущен - не было ввода-вывода с повышенными дисками , Службы были перезапущены в 3 пакетах, оставив php-fpm до конца. После каждой перезапуска тест iotop подтвердил, что проблем не было. После запуска php-fpm проблема вернулась. (Было бы достаточно легко смоделировать несколько запросов PHP на тестовом сервере, но в этот момент я не был уверен, что это на самом деле PHP).

К сожалению, сервер был бы довольно бессмысленным без PHP, так что это не идеальный вывод. Однако, поскольку flush-202казалось, что-то связано с памятью (несмотря на наличие достаточно свободной памяти), я решил отключить APC. Повторный запуск теста iotop показал, что уровни дискового ввода-вывода были нормальными. Более внимательное изучение вопроса показало, что mmap был включен и для apc.mmap_file_maskнего установлено значение /tmp/apc.XXXXXX(по умолчанию для этой установки). Этот путь устанавливает APC для использования файлового mmap. Просто закомментировав эту строку (следовательно, используя заданную по умолчанию анонимную память при поддержке) и повторно запустив тест iotop, показал, что проблема была решена.

Я до сих пор не знаю, почему ни один из прогонов диагностики не идентифицировал записи как поступающие с php и идущие в файлы apc в каталоге / tmp. Единственным тестом, в котором упоминался даже каталог / tmp, было то lsof, что перечисленные в нем файлы отсутствовали.