ปัญหา: เมื่อเร็ว ๆ นี้ฉันได้ทำการปรับปรุงเซิร์ฟเวอร์ตัวใดตัวหนึ่งของฉันมันได้รับการทดสอบก่อนใช้งานและใช้งานได้ดีอย่างไรก็ตามเมื่อไม่กี่วันที่ผ่านมาฉันสังเกตเห็นว่ามีการเขียนจำนวนประมาณ 4 เท่าของปริมาณปกติ นี่ไม่ใช่ปัญหาด้านประสิทธิภาพ - เซิร์ฟเวอร์ทำงานได้ดี
การปรับปรุงใหม่ของฉันค่อนข้างกว้างขวาง (การสร้างใหม่เต็มรูปแบบ) ดังนั้นฉันจึงไม่ต้องทำอะไรมากมายในแง่ของสาเหตุ สั้น ๆ การเปลี่ยนแปลงของฉันรวมถึง:
- การอัพเกรด Linux ของ Amazon (จาก 2011.02 เป็น 2011.09) - ซึ่งส่งผลให้มีการเปลี่ยนแปลงจาก ext3 เป็น ext4 สำหรับปริมาณรูต
- ย้ายจาก php-fcgi เป็น php-fpm (ปัจจุบันใช้ tcp)
- การย้ายจากการตั้งค่า reverse-proxy (nginx -> apache) เป็น nginx เท่านั้น
- การแทนที่ vsftpd ด้วย pure-ftpd
- การแทนที่ dkim-proxy ด้วย opendkim
- แทนที่ webmin ด้วย ispconfig
- การเพิ่มสารเคลือบเงาเป็นเลเยอร์แคชสำหรับไฟล์ไดนามิก (มากเกินไปสำหรับปริมาณการเข้าชมที่ไซต์เหล่านี้ได้รับ แต่เป็นการทดลอง)
- การเพิ่มพาร์ทิชัน swap
การตั้งค่าพื้นฐาน:
- พื้นที่ swap ของฉันจะติดตั้งอยู่บนไดรฟ์ EBS ของตัวเอง - การเขียนปริมาณการแลกเปลี่ยนจะเล็กน้อย - ฉันได้ลดเป็นหลักนี้เป็นสาเหตุ (มีหน่วยความจำกว้างขวางฟรี - และทั้งสอง
freeและiostatแสดงการใช้งานแลกเปลี่ยนน้อยที่สุด) - ข้อมูลของฉัน (ฐานข้อมูล mysql, ไฟล์ผู้ใช้ (เว็บไซต์), บันทึกทั้งหมด (จาก / var / log), เมล, และไฟล์เคลือบเงาบนโวลุ่ม EBS ของตัวเอง (โดยใช้
mount --bind) วอลุ่ม EBS พื้นฐานติดตั้งที่/mnt/data - ไฟล์ที่เหลือของฉัน - ระบบปฏิบัติการและแอปพลิเคชันเซิร์ฟเวอร์หลัก (เช่น nginx, postfix, dovecot และอื่น ๆ ) - เป็นเพียงสิ่งเดียวในปริมาณรูท - รวม 1.2GB
การตั้งค่าใหม่รัน 'ราบรื่น' (เร็วกว่าหน่วยความจำน้อย ฯลฯ ) กว่าระบบเก่าและเสถียร 20 วัน (กลางเดือนตุลาคม) - เท่าที่ฉันสามารถบอกได้ว่าการเขียนที่ได้รับการยกระดับมีอยู่ตลอดเวลานี้ .
ตรงกันข้ามกับสิ่งที่ฉันคาดหวังฉันมีปริมาณการอ่านต่ำ (การอ่านของฉันมีประมาณ 1.5% ของการเขียนของฉันทั้งในแง่ของบล็อกและไบต์ในปริมาณรูทของฉัน) ฉันไม่ได้เปลี่ยนแปลงอะไรในปริมาณรูต (เช่นการติดตั้งใหม่ ฯลฯ ) ในสองสามวันที่ผ่านมา แต่ปริมาณการเขียนยังคงสูงกว่าที่คาดไว้มาก
วัตถุประสงค์:เพื่อตรวจสอบสาเหตุของการเพิ่มการเขียนไปที่ปริมาณรูท (โดยพื้นฐานแล้วให้คิดว่าเป็นกระบวนการ (และกระบวนการใด) ระบบไฟล์ (ext4) ที่แตกต่างกันหรือปัญหาอื่น (เช่นหน่วยความจำ)
ข้อมูลระบบ:
- แพลตฟอร์ม: EC2 ของ Amazon (t1.micro)
- O / S: Linux ของ Amazon 2011.09 (ได้รับ CentOS / RHEL)
- เคอร์เนล Linux: 2.6.35.14-97.44.amzn1.i686
- สถาปัตยกรรม: 32-bit / i686
- ดิสก์: 3 EBS วอลุ่ม:
- xvdap1, root, ระบบไฟล์ ext4 (ติดตั้งด้วยเวลากลางคืน)
- xvdf, data, ระบบไฟล์ xfs (ติดตั้งด้วยเวลากลางคืน, usrquota, grpquota)
- xvdg, swap
รูทและไดรฟ์ข้อมูลจะถูกถ่ายภาพวันละครั้ง - อย่างไรก็ตามนี่ควรเป็นการดำเนินการ 'อ่าน' ไม่ใช่การเขียน (นอกจากนี้ยังใช้วิธีปฏิบัติเดียวกันกับเซิร์ฟเวอร์ก่อนหน้า - และเซิร์ฟเวอร์ก่อนหน้านี้ก็เป็น t1.micro ด้วย)
ข้อมูลที่ทำให้ฉันมองเข้าไปใน I / O นั้นอยู่ในรายละเอียดของการเรียกเก็บเงิน AWS ครั้งล่าสุดของฉัน (ซึ่งสูงกว่า I / O ปกติ - ไม่คาดคิดเนื่องจากฉันตั้งค่าเซิร์ฟเวอร์นี้และติดตั้งสิ่งต่างๆมากมายในตอนเริ่มต้น ของเดือน) และต่อมาที่การวัด CloudWatch สำหรับปริมาณ EBS ที่แนบมา ฉันมาถึงตัวเลข '4 เท่าปกติ' โดยการคาดการณ์กิจกรรม i / o ตั้งแต่เดือนพฤศจิกายน (เมื่อฉันไม่ได้เปลี่ยนเซิร์ฟเวอร์) เพื่อประเมินมูลค่ารายเดือนและเปรียบเทียบกับ I / O จากเดือนที่ผ่านมาเมื่อฉันไม่ทำงาน บนเซิร์ฟเวอร์ก่อนหน้าของฉัน (ฉันไม่มีข้อมูล iostat ที่แน่นอนจากเซิร์ฟเวอร์ก่อนหน้าของฉัน) ปริมาณการเขียนที่เท่ากันยังคงมีอยู่จนถึงเดือนพฤศจิกายน 170-330MB / ชม.
ข้อมูลการวินิจฉัย (สถานะการออนไลน์สำหรับเอาต์พุตต่อไปนี้คือ 20.6 วัน):
ตัวชี้วัด Cloudwatch:
- ปริมาณรูต (เขียน): 5.5GB / วัน
- ปริมาณรูท (อ่าน): 60MB / วัน
- ปริมาณข้อมูล (เขียน): 400MB / วัน
- ปริมาณข้อมูล (อ่าน): 85MB / วัน
- ปริมาณการแลกเปลี่ยน (เขียน): 3MB / วัน
- ปริมาณการแลกเปลี่ยน (อ่าน): 2MB / วัน
ผลลัพธ์ของ: 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] wrote 26MB = 3.6GB / วัน
- php-fpm เขียน 17.5MB = 2.4GB / วัน
- MySQL เขียน 684KB = 96MB / วัน
- Varnish เขียน 580KB = 82MB / วัน
- [jbd2] เขียน 528KB = 74MB / วัน
- Nginx เขียน 120KB = 17MB / วัน
- IMAP Proxy เขียน 8KB = 1.1MB / วัน
น่าสนใจพอจะปรากฏว่าระหว่าง[flush-202]และphp-fpmเป็นไปได้ที่จะพิจารณาปริมาณการเขียนรายวัน
ใช้ftopฉันไม่สามารถที่จะติดตามอย่างใดอย่างหนึ่งflushหรือphp-fpmเขียน ftop -p php-fpm(เช่น
อย่างน้อยส่วนหนึ่งของปัญหาของฉันเกิดจากการระบุกระบวนการที่กำลังเขียนไปยังปริมาณรูต ของผู้ที่ระบุไว้ข้างต้นผมจะคาดหวังทั้งหมดที่จะเขียนถึงปริมาณข้อมูล (ตั้งแต่ไดเรกทอรีที่เกี่ยวข้องจะมี symlinked) (เช่นnginx, mysql, php-fpm, varnishไดเรกทอรีทุกจุดปริมาณ EBS ที่แตกต่างกัน)
ฉันเชื่อว่าJBD2เป็นอุปกรณ์บล็อกการบันทึกสำหรับ ext4 และflush-202เป็นพื้นหลังของหน้าสกปรก dirty_ratioคือ 20 และdirty_background_ratioเป็น 10 หน่วยความจำสกปรก (จาก/proc/meminfo) เป็นปกติระหว่าง 50-150kB) ขนาดหน้า ( getconf PAGESIZE) เป็นค่าเริ่มต้นของระบบ (4096)
ผลลัพธ์ของ: vmstat -s | grep paged
3248858 เพจที่เพจใน 1,04625313 เพจที่เพจหมด
ผลลัพธ์ของ: 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
บนโหนกที่การเขียน I / O อาจเกี่ยวข้องกับหน่วยความจำฉันปิดการใช้งานวานิชและรีสตาร์ทเซิร์ฟเวอร์ สิ่งนี้เปลี่ยนโปรไฟล์หน่วยความจำของฉันเป็น 10% ที่ใช้งาน, 2% ในบัฟเฟอร์และแคช 20%, ไม่ได้ใช้ 68% (เช่น 90% ฟรี) อย่างไรก็ตามในระยะเวลา 10 นาทีที่ผ่านมา iotop ให้ผลลัพธ์ที่คล้ายกันดังนี้:
- [flush-202] เขียน 19MB
- 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 และไม่ได้ติดตั้งสิ่งนี้) มีจำนวนถึง 4 ล็อกไฟล์ (cron, maillog, ftp, imapproxy) ที่อัพเดตในช่วง 10 นาที - และรายการที่เกี่ยวข้องสองสามรายการ (ซ็อกเก็ต postfix การเชื่อมต่อ pure-ftpd) รายการอื่น ๆ ที่มีการปรับเปลี่ยนเป็นหลักในช่วง ispconfig การปรับปรุงบัญชีระบบและความพยายามในการเข้าถึงเว็บที่ไม่ถูกต้อง (ไม่มีอยู่จริง server_name) (บันทึกไปยัง / var / log / nginx)
สรุปและคำถาม:
ให้ฉันเริ่มต้นด้วยการบอกว่าฉันค่อนข้างงุนงง - ฉันมักจะค่อนข้างละเอียด แต่ฉันรู้สึกว่าฉันขาดอะไรที่ชัดเจนในอันนี้ ชัดเจนflushและphp-fpmบัญชีสำหรับกลุ่มของการเขียน แต่ฉันไม่ทราบว่าทำไมถึงเป็นเช่นนั้น อย่างแรกลองใช้ php-fpm มันไม่ควรแม้แต่จะเขียนไปที่ปริมาตรรูท มันเป็นไดเรกทอรี (ทั้งไฟล์และบันทึก) เชื่อมโยงกับ EBS อีกเล่ม ประการที่สองสิ่งสำคัญที่ php-fpm ควรจะเขียนคือเซสชันและแคชของหน้า - ซึ่งทั้งเล็กและน้อย - ไม่แน่นอนอยู่ที่ 1MB / นาที (มากกว่า 1K / นาทีถ้าเช่นนั้น) ไซต์ส่วนใหญ่เป็นแบบอ่านอย่างเดียวโดยมีการปรับปรุงเป็นครั้งคราวเท่านั้น ขนาดรวมของไฟล์เว็บทั้งหมดที่แก้ไขในวันสุดท้ายคือ 2.6MB
ประการที่สองการพิจารณา flush - การเขียนที่สำคัญจากนั้นแนะนำให้ฉันว่าเพจสกปรกมักจะถูกฟลัชไปยังดิสก์ - แต่เนื่องจากโดยปกติฉันมีหน่วยความจำฟรี 65% และโวลุ่ม EBS แยกต่างหากสำหรับพื้นที่ swap ฉันไม่สามารถอธิบายได้ว่าทำไม ส่งผลกระทบต่อการเขียนในปริมาณรูตของฉันโดยเฉพาะอย่างยิ่งในขอบเขตที่เกิดขึ้น ฉันรู้ว่าบางกระบวนการจะเขียนหน้าสกปรกไปยังพื้นที่สว็อปของตัวเอง (แทนที่จะใช้พื้นที่สว็อปของระบบ) แต่แน่นอนทันทีหลังจากรีสตาร์ทโดยที่หน่วยความจำส่วนใหญ่ของฉันว่างฉันไม่ควรทำงานในจำนวนที่มาก หน้าสกปรก หากคุณเชื่อว่านี่เป็นสาเหตุโปรดแจ้งให้เราทราบว่าฉันอาจระบุกระบวนการที่กำลังเขียนไปยังพื้นที่สว็อปของตนเองได้อย่างไร
เป็นไปได้โดยสิ้นเชิงว่าความคิดหน้าสกปรกทั้งหมดเป็นเพียงปลาเฮอริ่งแดงและไม่เกี่ยวข้องกับปัญหาของฉันอย่างสมบูรณ์ (ฉันหวังว่ามันจะเป็นจริง) หากเป็นเช่นนั้นความคิดอื่นของฉันเท่านั้นที่มีบางสิ่งที่เกี่ยวข้องกับการบันทึกรายวัน ext4 ที่ไม่ได้แสดงใน ext3 นอกเหนือจากนั้นฉันยังไม่ได้คิด
Update (s):
6 พฤศจิกายน 2011:
ชุดdirty_ratio = 10และdirty_background_ratio = 5; อัปเดตด้วยsysctl -p(ยืนยันผ่าน / proc); รันการทดสอบไอโซโทป 10 นาทีด้วยผลลัพธ์ที่คล้ายกัน (ล้างเขียน 17MB, php-fpm เขียน 16MB, MySQL เขียน 1MB และ JBD2 เขียน 0.7MB)
ฉันเปลี่ยน symlink ทั้งหมดที่ฉันตั้งค่าให้ใช้mount --bindแทน วานิชวานิช, รีสตาร์ทเซิร์ฟเวอร์อีกครั้ง รันการทดสอบไอโซโทป 10 นาทีด้วยผลลัพธ์ที่คล้ายกัน (ล้างเขียน 12.5MB, php-fpm เขียน 11.5MB, วานิชเขียน 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 Swap: 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 และไอโซโทปไปพร้อม ๆ กันและรู้สึกประหลาดใจที่สังเกตว่ารายการที่ปรากฏในไอโซโทปไม่ปรากฏใน ftop รายการ ftop ถูกกรองเป็น php-fpm เนื่องจากฉันสามารถทริกเกอร์การเขียนของกระบวนการนั้นได้อย่างน่าเชื่อถือ ฉันได้เขียนเกี่ยวกับ 2MB ของการเขียนต่อการดูหน้าเว็บสำหรับ php-fpm - และฉันยังไม่ได้คิดว่ามันจะเขียนอะไรได้บ้าง - ความคิดใด ๆ เกี่ยวกับการยืนยันสิ่งที่กำลังเขียนอยู่
ฉันจะลองปิดการทำเจอร์นัลในอีกไม่กี่วันข้างหน้าและดูว่ามันช่วยให้ดีขึ้นหรือไม่ แม้ว่าในขณะนี้ฉันพบว่าตัวเองสงสัยว่าฉันมีปัญหา 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
ไม่มีอะไรที่คาดไม่ถึงน่าเสียดาย เมื่อมีโอกาสเกิดขึ้นเนื่องจากฮาร์ดแวร์พื้นฐานฉันได้กู้คืนสแน็ปช็อตของปริมาณรูทเมื่อวานนี้ (ไม่มีการเปลี่ยนแปลงใด ๆ ในวันสุดท้าย) และแทนที่โวลุ่มรากของอินสแตนซ์ด้วยอันใหม่ อย่างที่คาดไว้สิ่งนี้ไม่มีผลกระทบต่อปัญหา
ขั้นตอนต่อไปของฉันคือการลบการทำเจอร์นัลออก แต่ฉันได้เจอวิธีแก้ปัญหาก่อนที่จะทำเช่นนั้น
ปัญหาวางใน APC โดยใช้ mmap ที่ไฟล์สำรอง แก้ไขดิสก์ที่ถูกปล่อยนี้โดยประมาณ 35x - ถึง (โดยประมาณ) 150MB / วัน (แทน 5GB) ฉันอาจยังคงพิจารณาลบ journalling เนื่องจากนี่เป็นผู้สนับสนุนหลักที่เหลืออยู่ในค่านี้อย่างไรก็ตามจำนวนนี้ค่อนข้างยอมรับได้ในขณะนี้ ขั้นตอนดำเนินการเพื่อให้ได้ข้อสรุปของ APC นั้นจะมีคำตอบอยู่ด้านล่าง
watchและวิ่งผ่าน มีเพียงไม่กี่ไฟล์ (17) - ส่วนใหญ่เป็นไฟล์ PID หรือไฟล์ล็อคโดยมีไฟล์ temp (ไม่มีอยู่) บางไฟล์ watch -d -n 0.5 'lsof / | grep REG | awk '"'"'$4 ~ /.*[wu]/ { print $9}'"'"' | sort -u'