समस्या: मैंने हाल ही में अपने एक सर्वर को फिर से बनाया है, इसका उपयोग करने से पहले परीक्षण किया गया था, और अच्छी तरह से कार्य करता है, हालांकि, कुछ दिनों पहले, मैंने मूल मात्रा में लगभग 4 गुना सामान्य मात्रा लिखी। यह कोई प्रदर्शन समस्या नहीं है - सर्वर ठीक चलता है।
मेरा पुनर्मिलन काफी व्यापक था (एक पूर्ण पुनर्निर्माण) इसलिए मेरे पास कारण के मामले में बहुत कुछ नहीं है। संक्षेप में, मेरे बदलावों में शामिल हैं:
- अमेज़ॅन के लिनक्स को अपग्रेड करना (2011.02 से 2011.09 तक) - जिसके परिणामस्वरूप रूट वॉल्यूम के लिए ext3 से ext4 तक का परिवर्तन हुआ
- Php-fcgi से php-fpm पर जाना (वर्तमान में tcp का उपयोग करके)
- रिवर्स-प्रॉक्सी (nginx -> अपाचे) सेटअप से चलकर, केवल nginx तक
- Vsftpd को शुद्ध-ftpd के साथ बदलना
- Dkim- प्रॉक्सी को opendkim से बदलना
- Ispconfig के साथ वेबमिन की जगह
- डायनामिक फ़ाइलों के लिए कैशिंग परत के रूप में वार्निश जोड़ना (इन साइटों को मिलने वाली हिट की मात्रा के लिए ओवरकिल, लेकिन इसका एक प्रयोग)
- एक स्वैप विभाजन जोड़ना
बुनियादी ढांचा:
- मेरा स्वैप स्थान अपने स्वयं के EBS वॉल्यूम पर आरोहित है - स्वैप वॉल्यूम के लिए लिखता नगण्य है - मैंने इसे अनिवार्य रूप से कारण के रूप में छूट दी है (पर्याप्त मुक्त मेमोरी है - और दोनों
freeऔरiostatन्यूनतम स्वैप उपयोग दिखाते हैं)। - मेरा डेटा (mysql डेटाबेस, उपयोगकर्ता फ़ाइलें (वेबसाइट), सभी लॉग्स (/ var / log), मेल और वार्निश फ़ाइलों को अपने स्वयं के EBS वॉल्यूम (उपयोग करने पर
mount --bind)। अंतर्निहित EBS वॉल्यूम माउंट किया गया है।/mnt/data - मेरी शेष फाइलें - ऑपरेटिंग सिस्टम और कोर सर्वर एप्लिकेशन (जैसे nginx, postfix, dovecot, आदि) - रूट वॉल्यूम पर केवल एक चीज हैं - कुल 1.2GB।
नया सेटअप पुरानी प्रणाली की तुलना में 'स्मूथ' (तेज, कम मेमोरी इत्यादि) चलाता है, और 20 दिनों (मध्य अक्टूबर) के लिए स्थिर रहा है - जहाँ तक मैं बता सकता हूँ, इस समय के लिए उन्नत लेखन मौजूद है ।
जो मैं उम्मीद करता हूं, उसके विपरीत, मेरे पास कम रीड वॉल्यूम है (मेरी रीड मेरे राइट्स के लगभग 1.5% हैं, दोनों मेरे रूट वॉल्यूम पर ब्लॉक और बाइट के संदर्भ में)। मैंने पिछले कुछ दिनों में रूट वॉल्यूम (उदाहरण के लिए नए इंस्टॉलेशन आदि) पर कुछ भी नहीं बदला है, फिर भी लिखने की मात्रा उम्मीद से बहुत अधिक है।
उद्देश्य: मूल मात्रा में वृद्धि को लिखने का कारण निर्धारित करना (अनिवार्य रूप से, यह पता लगाना कि क्या यह एक प्रक्रिया है (और क्या प्रक्रिया है), अलग (ext4) फ़ाइल सिस्टम, या एक अन्य मुद्दा (जैसे मेमोरी)।
प्रणाली की जानकारी:
- प्लेटफ़ॉर्म: अमेज़न का EC2 (t1.micro)
- O / S: अमेज़न का लिनक्स 2011.09 (CentOS / RHEL व्युत्पन्न)
- लिनक्स कर्नेल: 2.6.35.14-97.44.amzn1.i686
- आर्किटेक्चर: 32-बिट / i686
- डिस्क: 3 ईबीएस वॉल्यूम:
- xvdap1, root, ext4 फाइलसिस्टम (noatime के साथ आरोहित)
- xvdf, डेटा, xfs फाइल सिस्टम (noatime, usrquota, grpquota के साथ घुड़सवार)
- xvdg, स्वैप
रूट और डेटा वॉल्यूम को दिन में एक बार स्नैपशॉट किया जाता है - हालांकि, यह एक 'रीड' ऑपरेशन होना चाहिए, न कि राइट। (इसके अतिरिक्त, पिछले सर्वर पर समान अभ्यास का उपयोग किया गया था - और पिछला सर्वर भी t1.micro था।)
डेटा जिसने मुझे I / O में देखने का कारण बनाया, वह मेरे पिछले AWS बिल के विवरण में था (जो सामान्य I / O से ऊपर था - अप्रत्याशित नहीं, क्योंकि मैं इस सर्वर को स्थापित कर रहा था, और शुरुआत में बहुत सारी चीजें स्थापित कर रहा था। महीने), और बाद में संलग्न ईबीएस संस्करणों के लिए क्लाउडवेच मैट्रिक्स पर। मैं एक मासिक मूल्य का अनुमान लगाने के लिए नवंबर (जब मैंने सर्वर में बदलाव नहीं किया है) को मासिक मान का अनुमान लगाने के लिए '4 गुना सामान्य' आंकड़ा पर पहुंचता हूं और पिछले महीनों से आई / ओ के साथ तुलना कर रहा हूं जब मैं काम नहीं कर रहा था मेरे पिछले सर्वर पर। (मेरे पास मेरे पिछले सर्वर से सटीक आईओस्टेट डेटा नहीं है)। वही मात्रा नवंबर, 170-330MB / घंटा के माध्यम से बनी हुई है।
नैदानिक जानकारी (निम्न आउटपुट के लिए अपटाइम 20.6 दिन है):
क्लाउडवॉच मीट्रिक:
- रूट वॉल्यूम (लिखें): 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 मिनट की अवधि से अधिक लग रहा है:
- [फ्लश -२०२] ने २६ एमबी = ३.६ जीबी / दिन लिखा
- php-fpm ने 17.5MB = 2.4GB / दिन लिखा
- MySQL ने 684KB = 96MB / दिन लिखा
- वार्निश ने 580KB = 82MB / दिन लिखा
- [jbd2] ने 528KB = 74MB / दिन लिखा
- नेग्नेक्स ने 120KB = 17MB / दिन लिखा
- IMAP प्रॉक्सी ने 8KB = 1.1MB / दिन लिखा
दिलचस्प रूप से पर्याप्त है, ऐसा प्रतीत होता है कि बीच में [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_ratio(से 10 गंदा स्मृति है /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
उपरोक्त पृष्ठ की एक उच्च संख्या का सुझाव देने के लिए प्रकट होता है - हालाँकि, मैं उम्मीद करूंगा कि यदि आवश्यक हो तो मेरे स्वैप विभाजन पर पृष्ठों को लिखा जाएगा, मेरे रूट वॉल्यूम को नहीं। कुल मेमोरी में से, सिस्टम में आमतौर पर उपयोग में 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और so0 के मान
का आउटपुट: swapon -s
Filename Type Size Used Priority
/dev/xvdg partition 1048572 9252 -1
उस कूबड़ पर, जो I / O लिखता है, मेमोरी से संबंधित हो सकता है, मैंने वार्निश को अक्षम कर दिया है, और सर्वर को पुनरारंभ किया है। इसने मेरी मेमोरी प्रोफ़ाइल को उपयोग में 10%, बफ़र्स में 2%, और 20% कैश, 68% अप्रयुक्त (अर्थात 90% मुक्त) में बदल दिया। हालाँकि, 10 मिनट से अधिक चलने पर, iotop ने पहले जैसा ही परिणाम दिया:
- [फ्लश -२०२] १ ९ एमबी लिखा
- php-fpm ने 10MB लिखा
पुनः आरंभ होने के एक घंटे के भीतर, पहले से ही 330MB रूट के साथ रूट मात्रा लिखी गई है, जिसमें 370K पृष्ठ स्वैप किए गए हैं।
का आउटपुट 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 का उपयोग नहीं करता, और इसे स्थापित नहीं किया है)। इसमें 10 मिनट के दौरान अपडेट की गई 4 लॉग फाइल (क्रोन, मैलोडोग, एफ़टीपी, इम्प्रोक्सी) और कुछ संबंधित आइटम (पोस्टफ़िक्स सॉकेट, प्योर-फ़ेपड कनेक्शन) हैं। अन्य आइटम मुख्य रूप से संशोधित ispconfig सत्र, सिस्टम अकाउंटिंग अपडेट, और अमान्य (गैर-मौजूद सर्वर_नाम) वेब एक्सेस प्रयास (लॉग इन / var / log / nginx) हैं।
निष्कर्ष और प्रश्न:
मुझे यह कहने से शुरू करें कि मैं थोड़ा चिंतित हूं - मैं आमतौर पर काफी संपूर्ण हूं, लेकिन मुझे लगता है कि मुझे इस पर कुछ स्पष्ट याद आ रहा है। स्पष्ट रूप से, flushऔर php-fpmबहुत कुछ लिखता है, लेकिन मुझे नहीं पता कि ऐसा क्यों हो सकता है। सबसे पहले, हम php-fpm लेते हैं - यह रूट वॉल्यूम पर भी नहीं लिखा जाना चाहिए। यह निर्देशिका (दोनों फ़ाइलें और लॉग) एक और ईबीएस मात्रा के लिए सहानुभूति है। दूसरे, प्राथमिक चीजें जो php-fpm लिखी जानी चाहिए, वे सत्र और पृष्ठ-कैश हैं - जो कुछ और छोटे दोनों हैं - निश्चित रूप से 1MB / मिनट (1K / मिनट की तरह अधिक नहीं है, अगर वह)। अधिकांश साइटें केवल-पढ़ने के लिए होती हैं, जिनमें केवल सामयिक अद्यतन होते हैं। अंतिम दिन संशोधित सभी वेब फ़ाइलों का कुल आकार 2.6 एमबी है।
दूसरे, फ्लश पर विचार करते हुए - इससे महत्वपूर्ण लेखन मुझे यह सुझाव देता है कि गंदे पृष्ठों को अक्सर डिस्क में फ्लश किया जा रहा है - लेकिन यह देखते हुए कि मेरे पास आमतौर पर 65% मुफ्त मेमोरी और स्वैप स्पेस के लिए एक अलग ईबीएस वॉल्यूम है, मैं समझा नहीं सकता कि यह क्यों होगा मेरे रूट वॉल्यूम पर लिखने को प्रभावित करता है, विशेष रूप से उस सीमा तक जो घटित हो रहा है। मुझे एहसास है कि कुछ प्रक्रियाएं अपने स्वयं के स्वैप स्थान (सिस्टम स्वैप स्पेस का उपयोग करने के बजाय) के लिए गंदे पृष्ठ लिखेंगे, लेकिन निश्चित रूप से, मेरी स्मृति के विशाल बहुमत से मुक्त होने के तुरंत बाद, मैं किसी भी पर्याप्त मात्रा में नहीं चलना चाहिए। गंदे पृष्ठ। यदि आप इसका कारण मानते हैं, तो कृपया मुझे बताएं कि मैं कैसे पहचान सकता हूं कि कौन सी प्रक्रियाएं अपने स्वयं के स्वैप स्थान पर लिख रही हैं।
यह पूरी तरह से संभव है कि पूरे गंदे पन्नों का विचार केवल एक लाल हेरिंग है और मेरी समस्या से पूरी तरह से जुड़ा हुआ है (मुझे आशा है कि यह वास्तव में है)। अगर ऐसा है, तो मेरा एकमात्र विचार यह है कि ext4 जर्नलिंग से संबंधित कुछ है जो ext3 में मौजूद नहीं था। इससे परे, मैं वर्तमान में विचारों से बाहर हूं।
अद्यतन (ओं):
6 नवंबर, 2011:
सेट dirty_ratio = 10और dirty_background_ratio = 5; के साथ अद्यतन sysctl -p(के माध्यम से की पुष्टि की / खरीद); इसी तरह के परिणाम के साथ रेनान 10 मिनट के आईटोप टेस्ट (फ्लश ने 17MB लिखा, php-fpm ने 16MB लिखा, MySQL ने 1MB लिखा, और JBD2 ने 0.7MB लिखा)।
मैंने mount --bindइसके बजाय उपयोग करने के लिए सभी सिमलाइन को बदल दिया है । फिर से सक्षम वार्निश, पुनरारंभ सर्वर; इसी तरह के परिणामों के साथ रेनान 10 मिनट के iotop परीक्षण (फ्लश ने 12.5MB लिखा, php-fpm ने 11.5MB लिखा, वार्निश ने 0.5MB लिखा, JBD2 ने 0.5MB लिखा, और MySQL ने 0.3MB लिखा)।
जैसा कि ऊपर रन में, मेरी मेमोरी प्रोफाइल 20% उपयोग में थी, बफ़र्स में 2%, और 58% कैश्ड, 20% अप्रयुक्त (अर्थात 80% मुक्त) बस अगर इस संदर्भ में मुफ्त मेमोरी की मेरी व्याख्या त्रुटिपूर्ण है, यहाँ का उत्पादन है free -m(यह एक t1.micro है)। कुल इस्तेमाल किया मुफ्त साझा बफ़र्स कैशेड मेम: 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 पर फ़िल्टर किया गया था, क्योंकि मैं उस प्रक्रिया के लेखन को काफी मज़बूती से ट्रिगर कर सकता था। मैंने php-fpm के लिए प्रति पृष्ठ दृश्य के बारे में 2MB लिखने का उल्लेख किया है - और मुझे अभी तक यह पता लगाना है कि यह संभवतः क्या लिख सकता है - जो लिखा जा रहा है उसके बारे में कोई भी विचार की सराहना की जाएगी।
मैं अगले कुछ दिनों में जर्नलिंग को बंद करने की कोशिश करूंगा, और देखूंगा कि क्या इससे चीजें बेहतर होती हैं। हालांकि, मैं खुद को आश्चर्यचकित करता हूं कि अगर मेरे पास I / O समस्या है या स्मृति समस्या है (या दोनों) - लेकिन मुझे स्मृति की समस्या को देखते हुए एक कठिन समय आ रहा है, यदि कोई है।
13 नवंबर, 2011:
जैसा कि फ़ाइल सिस्टम extents का उपयोग करता है, इसे ext3 के रूप में माउंट करना संभव नहीं था, इसके अतिरिक्त, इसे केवल-पढ़ने के रूप में माउंट करने का प्रयास किया गया, जिसके परिणामस्वरूप इसे पढ़ने-लिखने के रूप में रिमाउंट किया गया।
फ़ाइल-सिस्टम में वास्तव में जर्नलिंग सक्षम (128MB जर्नल) है, जैसा कि निम्नलिखित से स्पष्ट है:
का आउटपुट: 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
निम्नलिखित के अनुसार, एक महीने के तहत बिट में इस मात्रा के बारे में 140GB लिखा गया है - बस लगभग 5GB / दिन।
का आउटपुट: 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
कुछ भी अप्रत्याशित नहीं, दुर्भाग्य से। ऑफ-मौका पर यह अंतर्निहित हार्डवेयर के कारण था, मैंने रूट वॉल्यूम के कल के स्नैपशॉट को पुनर्स्थापित किया (अंतिम दिन में कुछ भी नहीं बदला था), और उदाहरण के रूट वॉल्यूम को नए के साथ बदल दिया। जैसी कि उम्मीद थी, इस समस्या पर कोई प्रभाव नहीं पड़ा।
मेरा अगला कदम जर्नलिंग को दूर करना होगा, लेकिन इससे पहले कि मैं समाधान के पार पहुंच गया।
फ़ाइल-समर्थित mmap का उपयोग करके APC में समस्या है। लगभग 35x - (अनुमानित अनुमानित) 150 एमबी / दिन (5GB के बजाय) द्वारा इस डिस्क को i / o फिक्स करना। मैं अभी भी पत्रिकाओं को हटाने पर विचार कर सकता हूं क्योंकि यह इस मूल्य के लिए प्रमुख शेष योगदानकर्ता प्रतीत होता है, हालांकि, यह संख्या इस समय के लिए काफी स्वीकार्य है। एपीसी निष्कर्ष पर पहुंचने के लिए उठाए गए कदम नीचे एक जवाब में पोस्ट किए गए हैं।
watch। केवल कुछ फाइलें (17) थीं - ज्यादातर पीआईडी फाइलें या लॉक फाइलें, कुछ (गैर-मौजूद) अस्थायी फ़ाइलों के साथ। watch -d -n 0.5 'lsof / | grep REG | awk '"'"'$4 ~ /.*[wu]/ { print $9}'"'"' | sort -u'