সমস্যা: আমি সম্প্রতি আমার একটি সার্ভারকে নতুন করে সংশোধন করেছি, এটি ব্যবহারের আগে এটি পরীক্ষা করা হয়েছিল, এবং ভাল ফাংশনগুলি, তবে, কয়েক দিন আগে, আমি লক্ষ্য করেছি যে রুট ভলিউমে লেখার স্বাভাবিক পরিমাণের প্রায় 4 গুণ। এটি কোনও পারফরম্যান্সের সমস্যা নয় - সার্ভারটি ভাল চলছে।
আমার পুনর্নির্মাণটি মোটামুটি বিস্তৃত ছিল (একটি সম্পূর্ণ পুনর্নির্মাণ) সুতরাং আমার পক্ষে কারণ হিসাবে খুব বেশি কিছু করার দরকার নেই। সংক্ষেপে, আমার পরিবর্তনগুলি অন্তর্ভুক্ত:
- অ্যামাজনের লিনাক্স (২০১১.০২ থেকে ২০১০.০৯-এ আপগ্রেড করা) - এর ফলে মূল ভলিউমের জন্য ext3 থেকে ext4 এ পরিবর্তন হয়েছে
- পিএইচপি-এফসিগি থেকে পিএইচপি-এফপিএম এ স্থানান্তরিত হচ্ছে (বর্তমানে টিসিপি ব্যবহার করছে)
- বিপরীত প্রক্সি (এনগিনেক্স -> অ্যাপাচি) সেটআপ থেকে কেবল এনগিনেক্সে চলেছে
- শুদ্ধ- ftpd সঙ্গে vsftpd প্রতিস্থাপন
- ওপেনডিম দিয়ে ডিকিম-প্রক্সি প্রতিস্থাপন করা হচ্ছে
- আইপমিনফিগ দিয়ে ওয়েবমিন প্রতিস্থাপন করা হচ্ছে
- গতিশীল ফাইলগুলির জন্য ক্যাচিং স্তর হিসাবে বার্নিশ যুক্ত করা (এই সাইটগুলি হিটগুলির পরিমাণের জন্য ওভারকিল, তবে এটি একটি পরীক্ষা)
- একটি সোয়াপ পার্টিশন যুক্ত করা হচ্ছে
বেসিক সেটআপ:
- Swap 'র ভলিউম লিখেছেন তুচ্ছ হয় - - আমার swap' র স্থান নিজস্ব EBS ভলিউমে মাউন্ট করা আমি মূলত কারণ হিসাবে এই ছাড় করেছে (সেখানে প্রশস্ত বিনামূল্যে মেমরির - এবং উভয়
freeএবংiostatন্যূনতম swap 'র ব্যবহার দেন)। - আমার ডেটা (mysql ডাটাবেস, ব্যবহারকারী ফাইল (ওয়েবসাইট), সমস্ত লগ (/ var / লগ থেকে), মেল এবং বার্নিশ ফাইলগুলি তাদের নিজস্ব EBS ভলিউমে (ব্যবহার করে
mount --bind)। অন্তর্নিহিত EBS ভলিউমে মাউন্ট করা হয়েছে/mnt/data - আমার বাকী ফাইলগুলি - অপারেটিং সিস্টেম এবং কোর সার্ভার অ্যাপ্লিকেশনগুলি (যেমন এনগিনেক্স, পোস্টফিক্স, ডোভকোট ইত্যাদি) - রুট ভলিউমের একমাত্র জিনিস - মোট 1.2 জিবি।
নতুন সেটআপটি পুরানো সিস্টেমের তুলনায় 'স্মুথ' (দ্রুত, কম স্মৃতি ইত্যাদি) চালায় এবং 20 দিনের জন্য (অক্টোবরের মাঝামাঝি) স্থিতিশীল ছিল - যতদূর আমি বলতে পারি, উন্নত লেখাগুলি এই সময়ের জন্য বিদ্যমান ছিল ।
আমি যা প্রত্যাশা করব তার বিপরীতে, আমার কম পঠিত পরিমাণ রয়েছে (আমার পাঠাগুলি আমার লেখার প্রায় 1.5%, আমার মূল ভলিউমের ব্লক এবং বাইট উভয় ক্ষেত্রে)। আমি গত কয়েক দিনে মূল ভলিউমের (উদাঃ নতুন ইনস্টলেশন ইত্যাদি) তেমন কিছু পরিবর্তন করিনি, তবুও লেখার পরিমাণটি প্রত্যাশার চেয়ে অনেক বেশি বাড়তে থাকে।
উদ্দেশ্য: বর্ধিত কারণের মূল নির্ধারণ করতে মূল ভলিউমকে লিখুন (মূলত, এটি কোনও প্রক্রিয়া (এবং কী প্রক্রিয়া), ভিন্ন (এক্সট 4) ফাইল সিস্টেম, বা অন্য কোনও সমস্যা (যেমন মেমরি)) লিখুন।
পদ্ধতিগত তথ্য:
- প্ল্যাটফর্ম: অ্যামাজনের ইসি 2 (t1.micro)
- ও / এস: অ্যামাজনের লিনাক্স 2011.09 (সেন্টোস / আরএইচইএল উত্পন্ন)
- লিনাক্স কার্নেল: 2.6.35.14-97.44.amzn1.i686
- আর্কিটেকচার: 32-বিট / i686
- ডিস্ক: 3 ইবিএস ভলিউম:
- xvdap1, মূল, ext4 ফাইল সিস্টেম (noatime দিয়ে মাউন্ট করা)
- xvdf, ডেটা, এক্সএফএস ফাইল সিস্টেম (noatime, usrquota, grpquota দিয়ে মাউন্ট করা)
- xvdg, অদলবদল
রুট এবং ডেটা ভলিউমগুলি দিনে একবার স্ন্যাপশট করা হয় - তবে এটি একটি 'পড়ুন' অপারেশন হওয়া উচিত, লেখার মতো নয়। (অতিরিক্তভাবে, পূর্ববর্তী সার্ভারে একই অনুশীলন ব্যবহৃত হয়েছিল - এবং পূর্ববর্তী সার্ভারটিও একটি টি 1 মাইক্রো ছিল))
আমি যে তথ্যটি আই / ও-তে সন্ধান করিয়েছি তা আমার শেষ এডাব্লুএস বিলের বিবরণে ছিল (যা স্বাভাবিক আই / ও এর চেয়ে বেশি ছিল - অপ্রত্যাশিত নয়, যেহেতু আমি এই সার্ভারটি স্থাপন করছিলাম এবং শুরুতে প্রচুর জিনিস ইনস্টল করছিলাম) মাসের) এবং পরে সংযুক্ত ইবিএস ভলিউমের জন্য ক্লাউডওয়াচ মেট্রিকগুলিতে। আমি মাসিক মান অনুমান করার জন্য নভেম্বর থেকে (যখন আমি সার্ভারটি পরিবর্তন করি না) আই / ও ক্রিয়াকলাপকে এক্সট্রাপোল্ট করে '4 গুণ স্বাভাবিক' চিত্রটিতে পৌঁছে যাই এবং আমি যখন কাজ না করি তখন গত মাসের থেকে I / O এর সাথে তুলনা করে আমার আগের সার্ভারে (আমার আগের সার্ভার থেকে সঠিক আইওস্ট্যাট ডেটা নেই)। একই পরিমাণ লেখাগুলি নভেম্বর, 170-330MB / ঘন্টা অবধি স্থায়ী ছিল।
ডায়াগনস্টিক তথ্য (নিম্নলিখিত আউটপুটগুলির জন্য আপটাইম 20.6 দিন):
ক্লাউডওয়াচ মেট্রিক্স:
- মূল ভলিউম (লিখুন): 5.5 জিবি / দিন
- মূল ভলিউম (পড়ুন): 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 মিনিটের সময়কালের মতো দেখে মনে হচ্ছে:
- [ফ্লাশ -202] 26 এমবি = 3.6 জিবি / দিন লিখেছিল
- পিএইচপি-এফপিএম লিখেছেন 17.5MB = 2.4GB / দিন
- মাইএসকিউএল 684KB = 96MB / দিন লিখেছিল
- বার্নিশ 580KB = 82MB / দিন লিখেছেন
- [জেবিডি 2] 528KB = 74 এমবি / দিন লিখেছিল
- এনগিনেক্স 120KB = 17MB / দিন লিখেছিল
- IMAP প্রক্সি 8KB = 1.1MB / দিন লিখেছিল
আকর্ষণীয়ভাবে যথেষ্ট, এটি প্রদর্শিত হবে যে এর মধ্যে [flush-202]এবং php-fpmএটি দৈনিক দৈনিক খণ্ডের জন্য অ্যাকাউন্ট করা সম্ভব।
ব্যবহার করে ftop, আমি উভয়ই flushবা php-fpmলেখাগুলি সন্ধান করতে অক্ষম (উদা ftop -p php-fpm।
আমার সমস্যার অন্তত অংশটি কোন প্রক্রিয়াগুলি মূল ভলিউমে লিখছে তা সনাক্তকরণ থেকে শুরু করে। সেই উপরে তালিকাভুক্ত, আমি আশা সব ডাটা ভলিউম লিখিতভাবে করা (যেহেতু প্রাসঙ্গিক ডিরেক্টরি সেখানে সিমলিঙ্ক) (যেমন nginx, mysql, php-fpm, varnishডিরেক্টরি একটি ভিন্ন EBS ভলিউম সব পয়েন্ট)
আমি বিশ্বাস করি JBD2ext4 এর জন্য জার্নালিং ব্লক ডিভাইস এবং 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
আই / ও লিখেছেন যে হানচে স্মৃতি সম্পর্কিত হতে পারে, আমি বার্নিশ অক্ষম করেছি এবং সার্ভার পুনরায় চালু করেছি। এটি আমার মেমরির প্রোফাইলটি ব্যবহারে 10%, বাফারে 2% এবং 20% ক্যাশেড, 68% অব্যবহৃত (অর্থাৎ 90% ফ্রি) করে দিয়েছে। তবে, 10 মিনিটের বেশি রান করার পরে, আইওটপ পূর্বের মতো একই ফলাফল দিয়েছে:
- [ফ্লাশ -202] 19 এমবি লিখেছিল
- পিএইচপি-এফপিএম লিখেছেন 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সিপ্যানেলে, তবে আমি সিপ্যানেল ব্যবহার করি না, এবং এটি ইনস্টল করা হয়নি)। এটি 10 মিনিটের সময় আপডেট হওয়া 4 লগ ফাইলের (ক্রোন, মাইলগ, এফটিপি, ইমপ্প্রোক্সি) এবং কয়েকটি সম্পর্কিত আইটেম (পোস্টফিক্স সকেট, খাঁটি-এফটিপিডি সংযোগ) এর পরিমাণ। অন্যান্য আইটেমগুলি প্রাথমিকভাবে সংশোধিত ispconfig সেশন, সিস্টেম অ্যাকাউন্টিং আপডেট এবং অবৈধ (অস্তিত্ব নেই সার্ভার_নাম) ওয়েব অ্যাক্সেস প্রচেষ্টা (লগ ইন / var / লগ / এনগিনেক্স)।
সিদ্ধান্ত এবং প্রশ্ন:
আমি কিছুটা বিচলিত এই বলে আমাকে শুরু করতে দাও - আমি সাধারণত মোটামুটি পুরোপুরি থাকি, তবে আমি অনুভব করি যে আমি এর থেকে সুস্পষ্ট কিছু মিস করছি। স্পষ্টতই, flushএবং php-fpmলেখকদের বেশিরভাগের জন্য অ্যাকাউন্ট করুন, তবে কেন আমি জানি না কেন এটি হতে পারে। প্রথমত, আসুন পিএইচপি-এফপিএম - এটি এমনকি মূল ভলিউমে লেখা উচিত নয়। এটি ডিরেক্টরিগুলি (উভয় ফাইল এবং লগ) অন্য ইবিএস ভলিউমের সাথে সিমিলিংযুক্ত। দ্বিতীয়ত, পিএইচপি-এফএমপি যে প্রাথমিক জিনিসগুলি লিখতে হবে সেগুলি হ'ল সেশন এবং পৃষ্ঠা-ক্যাশ - যা উভয়ই কম এবং ছোট - অবশ্যই 1 এমবি / মিনিটের আদেশে নয় (আরও 1K / মিনিটের মতো, যদি তা থাকে)। বেশিরভাগ সাইটগুলি কেবলমাত্র উপলভ্য আপডেট সহ কেবল পঠনযোগ্য। শেষ দিনে সংশোধিত সমস্ত ওয়েব ফাইলের মোট আকার ২.6 এমবি।
দ্বিতীয়ত, ফ্লাশ বিবেচনা করে - তা থেকে উল্লেখযোগ্য লেখাগুলি আমার কাছে পরামর্শ দেয় যে নোংরা পৃষ্ঠাগুলি প্রায়শই ডিস্কে ফেলা হয় - তবে আমার সাধারণত 65৫% ফ্রি মেমরি এবং অদলবদলের জন্য পৃথক ইবিএস ভলিউম থাকায় আমি ব্যাখ্যা করতে পারি না কেন এটি হবে আমার রুট ভলিউমের লেখাগুলিকে প্রভাবিত করুন, বিশেষত যে পরিমাণটি ঘটছে। আমি বুঝতে পারি যে কিছু প্রক্রিয়াগুলি তাদের নিজস্ব অদলবদল জায়গায় (সিস্টেমের অদলবদল স্পেস ব্যবহার করার পরিবর্তে) নোংরা পৃষ্ঠাগুলি লিখবে, তবে অবশ্যই, আমার মেমরির বিশাল অংশটি মুক্ত থাকার সাথে সাথে পুনরায় চালু করার পরে, আমার কোনও পরিমাণে যথেষ্ট পরিমাণে চলতে হবে না নোংরা পাতা। যদি আপনি এটির কারণ হিসাবে বিশ্বাস করেন তবে দয়া করে আমাকে জানান যে আমি কীভাবে সনাক্ত করতে পারি যা কোন নিজস্ব প্রক্রিয়াগুলি তাদের অদলবদলে লিখছে।
এটি সম্পূর্ণরূপে সম্ভব যে পুরো নোংরা পৃষ্ঠাগুলি ধারণাটি কেবল একটি লাল রঙের হারিং এবং আমার সমস্যার সাথে সম্পূর্ণ সম্পর্কিত নয় (আমি আশা করি এটি বাস্তবেই আছে)। যদি এটি হয় তবে আমার একমাত্র অন্য ধারণা যে ext4 জার্নালিংয়ের সাথে সম্পর্কিত এমন কিছু আছে যা ext3 তে উপস্থিত ছিল না। এর বাইরেও আমি বর্তমানে ধারণার বাইরে রয়েছি।
আপডেট (গুলি):
নভেম্বর 6, 2011:
সেট dirty_ratio = 10এবং dirty_background_ratio = 5; আপডেট হয়েছে sysctl -p(মাধ্যমে / proc মাধ্যমে নিশ্চিত); অনুরূপ ফলাফলের সাথে 10 মিনিটের আইওটপ পরীক্ষার পুনরায় পুনঃস্থাপন করুন (ফ্লাশটি 17MB লিখেছিল, পিএইচপি-এফপিএম 16MB লিখেছিল, মাইএসকিউএল 1MB লিখেছিল, এবং জেবিডি 2 লিখেছেন 0.7MB)।
mount --bindপরিবর্তে আমি সেটআপ করার জন্য যে সমস্ত সিমলিংকগুলি সেটআপ করেছি তার পরিবর্তে আমি ব্যবহার করেছি । পুনরায় সক্ষম বার্নিশ, সার্ভার পুনরায় চালু; অনুরূপ ফলাফলের সাথে 10 মিনিটের আইওটপ পরীক্ষার পুনরায় পুনঃস্থাপন করুন (ফ্লাশ 12.5MB লিখেছিল, পিএইচপি-এফপিএম 11.5MB লিখেছিল, বার্নিশ 0.5MB লিখেছিল, জেবিডি 2 0.5MB লিখেছিল, এবং মাইএসকিউএল 0.3MB লিখেছিল)।
উপরের রান হিসাবে, আমার মেমরি প্রোফাইলটি ব্যবহারে 20%, বাফারে 2%, এবং 58% ক্যাশেড, 20% অব্যবহৃত (অর্থাত্ 80% ফ্রি) কেবলমাত্র যদি এই প্রসঙ্গে আমার মুক্ত স্মৃতি সম্পর্কে ব্যাখ্যা ত্রুটিযুক্ত হয়, এখানে আউটপুট free -m(এটি একটি টি 1 মাইক্রো)। মোট ব্যবহৃত নিখরচায় ভাগ করা বাফার ক্যাশেড মেম: 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)
আমি একই সাথে ফটপ এবং আইওটপ চালিয়েছিলাম, এবং অবাক হয়ে লক্ষ্য করেছিলাম যে আইটপটিতে প্রদর্শিত এন্ট্রিগুলি ফটপে প্রদর্শিত হয়নি। ফটোগুলি তালিকাটি পিএইচপি-এফপিএম-এ ফিল্টার করা হয়েছিল, যেহেতু আমি সেই প্রক্রিয়াটি মোটামুটি নির্ভরযোগ্যতার সাথে লেখার ট্রিগার করতে পারি। আমি পিএইচপি-এফপিএম-এর জন্য প্রতি পৃষ্ঠাগুলির ভিউ সম্পর্কে 2MB রচনা লিখেছি - এবং সম্ভবত এটি কী লিখতে পারে তা নির্ধারণ করতে পেরেছি - যা লেখা হচ্ছে তা নির্ধারণের জন্য যে কোনও ধারণা প্রশংসিত হবে।
আমি আগামী কয়েকদিনে জার্নালিং বন্ধ করার চেষ্টা করব, এবং এটি কী উন্নত করে তা দেখুন। এই মুহুর্তের জন্য, আমি নিজেকে ভাবছি যে আমার / ও সমস্যা আছে বা মেমরির সমস্যা আছে (বা উভয়ই) - তবে স্মৃতি সমস্যা থাকলে আমার যদি খুব সমস্যা হয় তবে খুব সমস্যা হচ্ছে।
নভেম্বর 13, 2011:
ফাইল সিস্টেম যেমন এক্সটেন্টস ব্যবহার করে, এটি ext3 হিসাবে মাউন্ট করা সম্ভব ছিল না, অতিরিক্ত হিসাবে এটি কেবল পঠনযোগ্য হিসাবে মাউন্ট করার চেষ্টা করে, ফলস্বরূপ এটি রিড-রাইট হিসাবে পুনঃসমাপন্ন হয়ে যায়।
নিম্নলিখিতটি থেকে স্পষ্টতই ফাইল-সিস্টেমটিতে জার্নালিং সক্ষম (128 এমবি জার্নাল) রয়েছে have
এর আউটপুট: 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 গিগাবাইট এই ভলিউমে এক মাসের মধ্যে কিছুটা লিখে লেখা হয়েছে - মাত্র 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
দুর্ভাগ্যক্রমে অপ্রত্যাশিত কিছুই নয়। অন্তর্নিহিত হার্ডওয়ারের কারণে এটি অফ অফ চান্সে, আমি গতকালের রুট ভলিউমের স্ন্যাপশট পুনরুদ্ধার করেছি (শেষ দিনটিতে কোনও কিছুই পরিবর্তন হয়নি), এবং উদাহরণটির রুট ভলিউমটিকে নতুনটির সাথে প্রতিস্থাপন করেছি। যেমনটি প্রত্যাশা করা হয়েছিল, সমস্যাটিতে এর কোনও প্রভাব ছিল না।
আমার পরবর্তী পদক্ষেপটি জার্নালিং সরিয়ে ফেলতে হবে, তবে আমি সমাধানে পৌঁছার আগেই হোঁচট খেয়েছি।
ফাইল-ব্যাকড এমএমএপ ব্যবহার করে এপিসিতে সমস্যাটি রয়েছে। এই বাদ পড়া ডিস্কটিকে i / o প্রায় 35x - থেকে (আনুমানিক) 150MB / দিন (5 গিগাবাইটের পরিবর্তে) দ্বারা স্থির করা হচ্ছে আমি এখনও জার্নালিং অপসারণ বিবেচনা করতে পারি কারণ এটি এই মানটির প্রধান অবশিষ্ট অবদানকারী হিসাবে উপস্থিত বলে মনে হয়, তবে এই সংখ্যাটি আপাতত বেশ গ্রহণযোগ্য। এপিসি উপসংহারে পৌঁছানোর জন্য গৃহীত পদক্ষেপগুলি নীচে একটি উত্তরে পোস্ট করা হয়েছে।
watch। কেবলমাত্র কয়েকটি ফাইল (17) ছিল - বেশিরভাগ পিআইডি ফাইল বা লক ফাইল, কয়েকটি (অস্তিত্বহীন) টেম্প ফাইলের সাথে। watch -d -n 0.5 'lsof / | grep REG | awk '"'"'$4 ~ /.*[wu]/ { print $9}'"'"' | sort -u'