5.5GB günlük 1.2GB kök hacmine yazılmıştır - önceki seviyelerin 4 katı

Sorun: Son zamanlarda sunucularımdan birini yeniledim, kullanmadan önce test edildi ve iyi çalışıyor, ancak birkaç gün önce, kök birime normal yazma sayısının yaklaşık 4 katı olduğunu fark ettim. Bu bir performans sorunu değildir - sunucu iyi çalışır.

Benim yenileme oldukça geniş (tam bir yeniden), bu yüzden neden açısından devam edecek çok şey yok. Kısaca, değişikliklerim şunları içeriyordu:

• Amazon'un Linux'unu yükseltmek (2011.02'den 2011.09'a) - bu da kök hacmi için ext3'ten ext4'e bir değişiklikle sonuçlandı
• Php-fcgi'den php-fpm'ye geçiş (şu anda tcp kullanılıyor)
• Bir ters proxy (nginx -> apache) kurulumundan yalnızca nginx'e geçiş
• Vsftpd'yi pure-ftpd ile değiştirme
• Dkim-proxy yerine opendkim değiştirme
• Webmin'i ispconfig ile değiştirme
• Dinamik dosyalar için önbellek katmanı olarak vernik ekleme (bu sitelerin aldığı isabetlerin hacmi için aşırı doldurma, ancak bir deneme)
• Takas bölümü ekleme

Temel kurulum:

• Takas hacmine yazma önemsiz olan - - My takas alanı kendi EBS hacmi üzerine monte edilmiştir Ben aslında nedeni olarak bu indirimli var (orada geniş ücretsiz hafıza - ve hem freeve iostatminimum takas kullanımını gösterir).
• Verilerim (mysql veritabanı, kullanıcı dosyaları (web siteleri), tüm günlükler (/ var / log'dan), posta ve vernik dosyaları kendi EBS birimlerindeki (kullanılarak mount --bind)./mnt/data
• Kalan dosyalarım - işletim sistemi ve çekirdek sunucu uygulamaları (örn. Nginx, postfix, dovecot, vb.) - kök birimindeki tek şey - toplam 1,2 GB.

Yeni kurulum, eski sistemden 'daha pürüzsüz' (daha hızlı, daha az bellek, vb.) Çalışıyor ve 20 gün boyunca (Ekim ortası) istikrarlıydı - anlayabildiğim kadarıyla, yükseltilmiş yazılar tüm bu zaman boyunca var oldu .

Beklediğimden farklı olarak, düşük bir okuma hacmim var (okumalarım hem yazımlarımın% 1.5'i, hem de kök hacmimdeki bloklar ve baytlar açısından). Son birkaç gün içinde kök biriminde (örneğin yeni kurulumlar, vb.) Hiçbir şey değiştirmedim, ancak yazma hacmi beklenenden çok daha yüksek olmaya devam ediyor.

Amaç: Kök birime artan yazmaların nedenini belirlemek (esas olarak, bunun bir işlem (ve hangi işlem), farklı (ext4) dosya sistemi veya başka bir sorun (örn. Bellek) olup olmadığını anlamak).

Sistem bilgisi:

• Platform: Amazon'un EC2'si (t1.micro)
• O / S: Amazon'un Linux 2011.09 (CentOS / RHEL türevi)
• Linux çekirdeği: 2.6.35.14-97.44.amzn1.i686
• Mimari: 32 bit / i686
• Diskler: 3 EBS birimi:
  • xvdap1, root, ext4 dosya sistemi (noatime ile monte edilmiş)
  • xvdf, veri, xfs dosya sistemi (noatime, usrquota, grpquota ile monte edilir)
  • xvdg, takas

Kök ve veri hacimleri günde bir kez anlık olarak çekilir - ancak bu yazma işlemi değil 'okuma' işlemi olmalıdır. (Ayrıca, önceki sunucuda aynı uygulama kullanıldı - ve önceki sunucu da t1.micro'ydu.)

G / Ç'ye bakmama neden olan veriler, bu sunucuyu kurduğumdan ve başlangıçta çok fazla şey yüklediğimden, son AWS faturamın ayrıntılarındaydı (normal G / Ç'nin üzerinde - beklenmedik değil). ve ardından ekli EBS birimlerine ilişkin CloudWatch metriklerinde. Aylık bir değer tahmin etmek için Kasım ayından itibaren (sunucuyu değiştirmediğimde) G / Ç etkinliğini tahmin ederek ve çalışmadığımda son aylardaki G / Ç ile karşılaştırarak '4 kat normal' rakamına ulaşıyorum önceki sunucumda. (Önceki sunucumdan kesin iostat verilerine sahip değilim). Aynı miktarda yazma, 170-330MB / saat Kasım ayına kadar devam etti.

Teşhis bilgileri (aşağıdaki çıkışlar için çalışma süresi 20.6 gündür):

Cloudwatch metrikleri:

• kök hacmi (yazma): 5.5GB / gün
• kök hacmi (okuma): 60MB / gün
• veri hacmi (yazma): 400MB / gün
• veri hacmi (okuma): 85MB / gün
• takas hacmi (yazma): 3MB / gün
• takas hacmi (okuma): 2MB / gün

Çıktı: df -h(yalnızca kök hacmi için)

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

Bu sistem başlatıldığından beri kullanılan alan belirgin bir şekilde artmadı (bu bana göre dosyaların güncellendiğini, oluşturulmadığını / eklenmediğini gösteriyor).

Çıktı: iostat -x(ile Blk_read, Blk_wrtneklendi):

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

Çıktı: 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

Yukarıdakileri özetlemek (ve günlük değerlere ekstrapolate etmek), 10 dakikalık süre zarfında şöyle görünür:

• [flush-202] 26MB = 3.6GB / gün yazdı
• php-fpm yazdı 17.5MB = 2.4GB / gün
• MySQL yazdı 684KB = 96MB / gün
• Vernik 580KB = 82MB / gün yazdı
• [jbd2] 528KB = 74MB / gün yazdı
• Nginx 120KB = 17MB / gün yazdı
• IMAP Proxy yazdı 8 KB = 1.1 MB / gün

İlginçtir ki, arasında [flush-202]ve php-fpmgünlük yazma hacmini açıklamak mümkündür.

Kullanarak ftop, ya flushda php-fpmyazıyor (ör ftop -p php-fpm.

Sorunumun en azından bir kısmı, hangi işlemlerin kök birime yazıldığını belirlemekten kaynaklanıyor. Bu yukarıda sıralanan ki, ben (ilgili dizinleri oraya sembolik olarak beri) tüm veri hacmine yazılı olması beklenir (örneğin nginx, mysql, php-fpm, varnishfarklı bir EBS hacme dizinleri bütün noktası)

JBD2Ext4 için günlük kaydı bloğu cihazı ve flush-202kirli sayfaların arka plan sifonu olduğuna inanıyorum . dirty_ratio20 ve dirty_background_ratio(10. Kirli bellek /proc/meminfo) tipik 50-150kB arasındaydı). Sayfa boyutu ( getconf PAGESIZE) sistem varsayılanıdır (4096).

Çıktı: vmstat -s | grep paged

104625313 sayfada 3248858 sayfa sayfalandı

Çıktı: 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

Yukarıdaki sayfalar çok sayıda sayfanın önerildiğini gösteriyor - ancak, sayfaların kök birimime değil, gerekirse takas bölümüme yazılmasını beklerim. Toplam bellekte, sistem tipik olarak% 35 kullanımda,% 10 tamponda ve% 40 önbelleğe alınmış,% 15 kullanılmamış (yani% 65 boş).

Çıktı: 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

vmstatsürekli olarak 0 değerini görüntüler sive görüntülerso

Çıktı: swapon -s

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

G / Ç'nin yazdığı bellekte bellekle ilgili olabilir, verniği devre dışı bıraktım ve sunucuyu yeniden başlattım. Bu, bellek profilimi kullanımda% 10, tamponlarda% 2 ve önbellekte% 20,% 68 kullanılmamış (yani% 90 boş) olarak değiştirdi. Bununla birlikte, 10 dakikalık bir koşu boyunca, iotop daha önce olduğu gibi benzer sonuçlar verdi:

• [flush-202] 19MB yazdı
• php-fpm yazdı 10MB

Yeniden başlatmadan bu yana bir saat içinde, 370K sayfa değiştirilerek kök birimine 330 MB yazılmıştır.

Çıktı 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/

Yukarıdakilere biraz daha yakından baktığımızda, neredeyse tüm yazılar her 5 dakikada bir çalışan ve çeşitli hizmetlerin durumunu kontrol eden ( chkservdcPanel'de olduğu gibi , ancak cPanel kullanmıyorum), ve bunu yüklemedi). 10 dakika boyunca güncellenen 4 günlük dosyasına (cron, maillog, ftp, imapproxy) ve birkaç ilgili öğeye (postfix soketleri, salt ftpd bağlantıları) karşılık gelir. Diğer öğeler öncelikli olarak değiştirilmiş ispconfig oturumları, sistem muhasebe güncellemeleri ve geçersiz (var olmayan sunucu_adı) web erişim denemeleri (/ var / log / nginx'e giriş yapılır).

Sonuç ve Sorular:

Biraz şaşkın olduğumu söyleyerek başlayayım - genellikle oldukça titizim, ama bu konuda bariz bir şey eksik olduğumu hissediyorum. Açıkçası flushve php-fpmyazarların büyük bir kısmını açıklasa da, bunun neden böyle olduğunu bilmiyorum. İlk olarak, php-fpm alalım - kök birime bile yazılmamalıdır. Dizinleri (dosyalar ve günlükler) başka bir EBS birimine bağlanmıştır. İkincisi, php-fpm'nin yazması gereken birincil şeyler, hem 1 hem de küçük olan oturumlar ve sayfa önbellekleridir (kesinlikle 1MB / dak.) Sitelerin çoğu yalnızca zaman zaman yapılan güncelleştirmelerle salt okunurdur. Son gün değiştirilen tüm web dosyalarının toplam boyutu 2,6 MB'dir.

İkincisi, floş düşünüldüğünde - ondan gelen önemli yazılar bana kirli sayfaların sık sık diske akıtıldığını gösteriyor - ancak takas alanı için genellikle% 65 boş belleğim ve ayrı bir EBS hacmim olduğu göz önüne alındığında, bunun neden olacağını açıklayamıyorum Kök hacmimdeki yazıları, özellikle de meydana geldiği ölçüde etkiler. Bazı işlemlerin kendi takas alanlarına kirli sayfalar yazacağının farkındayım (sistem takas alanı kullanmak yerine), ancak, hemen, belleğimin büyük çoğunluğunun serbest kalmasıyla bir yeniden başlatmanın hemen ardından, önemli miktarda kirli sayfalar. Bunun neden olduğuna inanıyorsanız, lütfen hangi işlemlerin kendi takas alanlarına yazdıklarını nasıl belirleyebileceğimi bana bildirin.

Tüm kirli sayfalar fikrinin sadece kırmızı bir ringa balığı olması ve sorunumla tamamen ilgisiz olması tamamen mümkündür (umarım aslında). Eğer durum buysa, ext4 günlüğe kaydetmeyle ilgili ext3'te bulunmayan başka bir fikrim var. Bunun ötesinde, şu anda fikirlerim bitti.

Güncelleme (ler):

6 Kasım 2011:

Set dirty_ratio = 10ve dirty_background_ratio = 5; ile güncellendi sysctl -p(/ proc ile onaylandı); Benzer sonuçlarla 10 dakikalık iotop testini tekrarlayın (floş 17MB, php-fpm 16MB, MySQL 1MB ve JBD2 0.7MB yazdı).

Kullanmak için kurduğum tüm simgeleri değiştirdim mount --bind. Yeniden etkinleştirilen vernik, yeniden başlatılan sunucu; benzer sonuçlarla 10 dakika iotop testi reran (floş 12.5MB, php-fpm 11.5MB, Varnish 0.5MB, JBD2 0.5MB ve MySQL 0.3MB yazdı).

Yukarıdaki çalışmada olduğu gibi, bellek profilim% 20 kullanımda, tamponlarda% 2 ve önbellekte% 58,% 20 kullanılmamış (yani% 80 boş) Bu bağlamda, boş bellek yorumumun kusurlu olması durumunda, İşte çıktı free -m(bu bir t1.micro). Toplam kullanılan ücretsiz paylaşılan arabellekleri önbelleğe alınan Mem: 602 478 124 0 14 347 - / + tamponlar / önbellek: 116486 Takas: 1023 0 1023

Bazı ek bilgiler: Çıktıları: 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)

Aynı zamanda ftop ve iotop'u aynı anda çalıştırdım ve iotop'ta gösterilen girişlerin ftop'ta görünmediğini fark ettim. Ftop listesi php-fpm'ye göre filtrelendi, çünkü bu işlemin yazmalarını oldukça güvenilir bir şekilde tetikleyebilirim. Ben php-fpm için sayfa görünümü başına yaklaşık 2MB yazma kaydetti - ve henüz ne yazıyor olabilir anlamak için henüz - yazılan ne olduğunu tespit herhangi bir fikir mutluluk duyacağız.

Önümüzdeki birkaç gün içinde günlüğe kaydetmeyi kapatmaya çalışacağım ve bunun gelişip gelişmediğini göreceğim. Yine de, kendimi bir G / Ç problemi veya bir bellek problemi (veya her ikisi) olup olmadığını merak ediyorum - ama varsa, bellek problemini görmekte zorlanıyorum.

13 Kasım 2011:

Dosya sistemi uzantıları kullandığından, onu ext3 olarak monte etmek mümkün değildi, ek olarak, salt okunur olarak monte etmeye çalışır, sadece okuma-yazma olarak yeniden monte edilmesiyle sonuçlanır.

Aşağıdakilerden de anlaşılacağı gibi, dosya sisteminde günlük kaydı etkinleştirilmiş (128 MB günlük):

Çıktı: 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

Aşağıdakilere göre, bu cilde bir ayın altında yaklaşık 140GB yazılmıştır - sadece yaklaşık 5GB / gün.

Çıktı: 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

Açık dosyaları aramaya devam ederken fuser, kök birimde kullanmayı denedim :

Çıktı: 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

Maalesef beklenmedik bir şey yok. Altta yatan donanımdan kaynaklanma olasılığına karşı, dünün kök hacminin anlık görüntüsünü geri yükledim (son gün hiçbir şey değişmedi) ve örneğin kök hacmini yenisiyle değiştirdim. Beklendiği gibi, bunun sorun üzerinde hiçbir etkisi yoktu.

Bir sonraki adım dergiyi kaldırmak olacaktı, ancak buna ulaşmadan önce çözümün karşısında tökezledim.

Sorun dosya destekli mmap kullanarak APC'de yatıyordu. Bu bırakılan disk giriş / çıkışını yaklaşık 35x - (tahmini) 150MB / gün (5GB yerine) sabitlemek. Yine de bu değere kalan en büyük katkı olarak göründüğü için günlük kaydını kaldırmayı düşünebilirim, ancak bu sayı şimdilik oldukça kabul edilebilir. APC sonucuna varmak için atılan adımlar aşağıda bir cevapta yayınlanmaktadır.

Başlıca neden günlük kaydı gibi göründüğünden, bu benim bir sonraki adımım olurdu. Ancak günlük kaydını kaldırmak için EBS birimini başka bir örneğe eklemem gerekir. Prosedürü (günlük) bir anlık görüntü kullanarak test etmeye karar verdim, ancak günlük kaydını kaldırmadan önce 10 dakikalık iotop testini (test örneğinde) yeniden çalıştırdım. Şaşırtıcı bir şekilde, normal (yani yükseltilmemiş) değerler gördüm ve bu flush-202listede ilk kez bile görünmedi. Bu tamamen işlevsel bir örnektir (verilerimin anlık görüntülerini de geri yükledim) - alınmasından bu yana 12 saat içinde kök biriminde herhangi bir değişiklik olmamıştı. Tüm testler, aynı işlemlerin her iki sunucuda da çalıştığını gösterdi. Bu, nedenin 'canlı' sunucunun işlediği bazı isteklere gelmesi gerektiğine inanmamı sağladı.

Sorunu gösteren sunucunun iotop çıktıları ile sorun olmayan görünüşte aynı sunucu arasındaki farklara bakıldığında, tek farklar flush-202ve idi php-fpm. Bu bana uzun bir atışta belki de PHP yapılandırmasıyla ilgili bir sorun olduğunu düşündürdü.

Şimdi, bu bölüm ideal değildi - ancak canlı sunucuda çalışan hizmetlerin hiçbiri birkaç dakika kesinti yaşamayacağı için gerçekten önemli değildi. Sorunu daraltmak için, canlı sunucudaki tüm büyük hizmetler (postfix, dovecot, imapproxy, nginx, php-fpm, vernik, mysqld, varnishncsa) durduruldu ve iotop testi yeniden çalıştırıldı - yükseltilmiş disk g / Ç yoktu . Hizmetler 3 parti halinde yeniden başlatıldı ve sonuna kadar php-fpm kaldı. Her yeniden başlatma işleminden sonra, iotop testi herhangi bir sorun olmadığını doğruladı. Php-fpm başlatıldığında sorun geri döndü. (Test sunucusunda birkaç PHP isteği simüle etmek kolay olurdu, ama bu noktada, aslında PHP olduğundan emin değildim).

Ne yazık ki, sunucu PHP olmadan oldukça anlamsız olurdu, bu yüzden bu ideal bir sonuç değildi. Ancak, flush-202bellekle ilgili bir şey önerdiğinden (bol miktarda boş hafızaya rağmen), APC'yi devre dışı bırakmaya karar verdim. İotop testinin tekrar yapılması disk i / o seviyelerinin normal olduğunu gösterdi. Konuya daha yakından bakmak mmap'in etkinleştirildiğini ve bunun (bu yükleme için varsayılan) apc.mmap_file_maskolarak ayarlandığını gösterdi /tmp/apc.XXXXXX. Bu yol APC'yi dosya destekli mmap kullanacak şekilde ayarlar. Sadece bu satırı yorumlamak (bu nedenle varsayılan - anonim belleği destekli) ve iotop testini yeniden çalıştırmak sorunun çözüldüğünü gösterdi.

Neden hala tanılama çalıştırmak hiçbiri php gelen ve / tmp dizinindeki apc dosyalarına gidiyor olarak yazma tanımlamak bilmiyorum. lsofBununla birlikte, / tmp dizininden bile bahseden tek test, listelediği dosyalar mevcut değildi.