5,5 ГБ, що записується щодня, до 1,2 ГБ кореневого обсягу - у 4 рази попередні рівні

Проблема: Нещодавно я оновив один із моїх серверів, він був протестований перед використанням, і він працює добре, проте кілька днів тому я помітив приблизно в 4 рази більше звичайної кількості записів до кореневого обсягу. Це не проблема продуктивності - сервер працює нормально.

Моє оновлення було досить масштабним (повна перебудова), тому мені не потрібно багато продовжувати з точки зору причини. Якщо коротко, мої зміни включали:

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

Основна настройка:

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

Нова установка працює "плавніше" (швидше, менше пам'яті тощо), ніж стара система, і стабільна протягом 20 днів (середина жовтня) - наскільки я можу сказати, підвищені записи існували весь цей час .

На відміну від того, що я очікував, у мене низький обсяг читання (моє читання становить приблизно 1,5% моїх записів, як з точки зору блоків, так і в байтах мого кореневого тома). За останні кілька днів я нічого не змінив у кореневому томі (наприклад, нові установки тощо), але обсяг запису продовжує бути значно більшим, ніж очікувалося.

Мета: визначити причину збільшення запису в кореневий об'єм (по суті, з'ясувати, чи це процес (і який процес), інша файлова система (ext4) чи інша проблема (наприклад, пам'ять)).

Інформація про систему:

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

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

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

Діагностична інформація (час роботи для наступних результатів становить 20,6 днів):

Показники Cloudwatch:

• об'єм кореня (записувати): 5,5 ГБ / день
• об'єм кореня (читання): 60 Мб / день
• об'єм даних (запис): 400 Мб / день
• об'єм даних (читання): 85 Мб / день
• об'єм заміни (запис): 3 Мб / день
• об'єм заміни (читання): 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] написав 26 Мб = 3,6 ГБ / день
• php-fpm записав 17,5 МБ = 2,4 ГБ / день
• MySQL писав 684 Кб = 96 МБ / день
• На лак писали 580 КБ = 82 МБ / день
• [jbd2] писав 528KB = 74MB / день
• Nginx писав 120 КБ = 17 МБ / день
• 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_ratio20 і dirty_background_ratio10. Брудні пам'яті (від /proc/meminfo) була зазвичай між 50-150kB). Розмір сторінки ( 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

Згадане вище передбачає велику кількість завантажених сторінок, однак я б очікував, що сторінки будуть записані у мій розділ swap, якщо це необхідно, а не в мій кореневий обсяг. З загальної пам’яті система зазвичай використовує 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] написав 19 МБ
• php-fpm написав 10 Мб

За годину з моменту перезавантаження вже було записано 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 хвилин - та кілька пов’язаних елементів (розетки postfix, з'єднання pure-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); reran 10-хвилинний тест на іотопі з аналогічними результатами (флеш написав 17 МБ, php-fpm написав 16 Мб, MySQL написав 1 МБ, а JBD2 написав 0,7 МБ).

Я змінив усі посилання, які я налаштував, щоб використовувати mount --bindзамість цього. Повторно включений лак, перезапущений сервер; reran 10-хвилинний іотопний тест з подібними результатами (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, що підтримується файлами. Виправлення цього впаденого дискового вводу / виводу приблизно на 35x - до (приблизно) 150MB / день (замість 5GB). Я все ще можу розглянути питання про видалення журналів, оскільки це, як видається, є основним, що залишився вкладником у цю величину, однак ця цифра наразі є цілком прийнятною. Кроки, зроблені для досягнення висновку APC, розміщені у відповіді нижче.

Оскільки головною причиною здавалося, що це журнал, це був би мій наступний крок. Однак для того, щоб видалити журнал, мені потрібно було б приєднати том EBS до іншого екземпляра. Я вирішив перевірити процедуру, використовуючи (добовий) знімок, проте перед тим, як видалити журнал, я повторно запустив 10-хвилинний іотопний тест (на тестовому екземплярі). На моє здивування, я побачив нормальні (тобто не підвищені) значення, і це було впершеflush-202 він навіть не з’явився у списку. Це був повністю функціональний екземпляр (я також відновив знімки моїх даних) - за 12 годин або близько того часу не було змінено об’єм кореня. Всі тести показали, що на обох серверах працювали однакові процеси. Це змусило мене вважати, що причина повинна зводитися до деяких запитів, які обробляє сервер "live".

Дивлячись на відмінності між iotop виходами сервера, що відображають проблему, і здавалося б однаковим сервером, який не мав проблеми, єдиними відмінностями були flush-202іphp-fpm . Це змусило мене думати, що, мабуть, довго, але це була проблема, пов’язана з конфігурацією PHP

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

На жаль, сервер був би безглуздим без PHP, тому це було не ідеальним висновком. Однак, оскільки, flush-202здавалося, пропонується щось, що стосується пам’яті (незважаючи на наявність достатньої кількості вільної пам’яті), я вирішив відключити APC. Перевірка іотопного тесту показала, що рівень вводу / виводу диска був нормальним. При більш детальному розгляді питання було показано, що mmap увімкнено, і apc.mmap_file_maskвстановлено значення /tmp/apc.XXXXXX(за замовчуванням для цієї установки). Цей шлях встановлює APC для використання файлів mmap, що підтримується файлами. Просто прокоментувавши цей рядок (отже, використовуючи за замовчуванням - підтримку анонімної пам'яті) та повторну перевірку iotop, показали, що проблема вирішена.

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