আমি কার্বন এবং গ্রাফাইট চালিত মেশিনগুলির একটি ক্লাস্টার পেয়েছি যা আমাকে আরও স্টোরেজ করার জন্য স্কেল করতে হবে তবে আমি নিশ্চিত না যে আমার স্কেল বা আউট বাড়ানোর দরকার আছে কিনা তা নিশ্চিত।
ক্লাস্টারটি বর্তমানে গঠিত:
- 1 রিলে নোড: সমস্ত মেট্রিক্স এবং প্রাসঙ্গিক স্টোরেজ নোডে ফরোয়ার্ড দেয়
- 6 স্টোরেজ নোড: সমস্ত হুইস্পার ডিবি ফাইলগুলি বাড়ি
সমস্যাটি হ'ল মনে হয় ডিস্কগুলি যখন 80% ব্যবহারের আশেপাশে এসেছিল তখন পারফরম্যান্স একটি ক্লিফের বাইরে পড়ে। ক্লাস্টার রাইটিং আইওপিএস কাছাকাছি স্থির 13 কে থেকে আরও বিশৃঙ্খলা গড়ে প্রায় 7k এবং আইওয়েটের সময় গড় 54% নেমে আসে।
আমি আমাদের কনফিগার রেপো দেখেছি এবং এপ্রিলের শুরু থেকে কোনও পরিবর্তন হয়নি, সুতরাং এটি কোনও কনফিগার পরিবর্তনের ফলাফল নয়।
প্রশ্ন: ডিস্কের আকার বাড়ানো কি আইও পারফরম্যান্সকে আবার নিয়ন্ত্রণে আনবে, বা আমার আরও স্টোরেজ নোড যুক্ত করা দরকার?
দ্রষ্টব্য: এখানে কোনও এসএসডি নেই, কেবল প্রচুর স্পেন্ডল।
প্রাসঙ্গিক গ্রাফ:
পরিসংখ্যান এবং স্টাফ:
e2freefrag:
[root@graphite-storage-01 ~]# e2freefrag /dev/vda3
Device: /dev/vda3
Blocksize: 4096 bytes
Total blocks: 9961176
Free blocks: 4781849 (48.0%)
Min. free extent: 4 KB
Max. free extent: 81308 KB
Avg. free extent: 284 KB
Num. free extent: 19071
HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range : Free extents Free Blocks Percent
4K... 8K- : 4008 4008 0.08%
8K... 16K- : 1723 3992 0.08%
16K... 32K- : 703 3495 0.07%
32K... 64K- : 637 7400 0.15%
64K... 128K- : 1590 29273 0.61%
128K... 256K- : 4711 236839 4.95%
256K... 512K- : 2664 265691 5.56%
512K... 1024K- : 2359 434427 9.08%
1M... 2M- : 595 213173 4.46%
2M... 4M- : 75 49182 1.03%
64M... 128M- : 6 118890 2.49%
e4defrag:
[root@graphite-storage-01 ~]# e4defrag -c /dev/vda3
<Fragmented files> now/best size/ext
1. /opt/graphite/storage/graphite.db 17/1 4 KB
2. /var/log/cron 13/1 4 KB
3. /var/log/wtmp 16/1 4 KB
4. /root/.bash_history 4/1 4 KB
5. /var/lib/rpm/Sha1header 10/1 4 KB
Total/best extents 182256/159981
Average size per extent 183 KB
Fragmentation score 2
[0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
This device (/dev/vda3) does not need defragmentation.
Done.
iostat:
[root@graphite-storage-01 ~]# iostat -k -x 60 3
Linux 3.10.0-229.7.2.el7.x86_64 (graphite-storage-01) 07/05/2016 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
7.99 0.00 2.54 29.66 0.35 59.46
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 100.34 177.48 1808.94 2715.66 7659.19 10.45 0.26 0.13 0.65 0.08 0.23 46.14
avg-cpu: %user %nice %system %iowait %steal %idle
6.17 0.00 7.00 73.21 0.58 13.04
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 23.87 672.40 656.47 8729.87 2752.27 17.28 7.36 5.50 2.72 8.35 0.73 96.83
avg-cpu: %user %nice %system %iowait %steal %idle
7.06 0.00 7.31 73.03 0.59 12.01
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.00 42.68 677.67 614.88 8634.93 2647.53 17.46 6.66 5.15 2.72 7.83 0.74 96.08
df:
[root@graphite-storage-01 ~]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/vda3 39153856 33689468 3822852 90% /
devtmpfs 1933092 0 1933092 0% /dev
tmpfs 1941380 0 1941380 0% /dev/shm
tmpfs 1941380 188700 1752680 10% /run
tmpfs 1941380 0 1941380 0% /sys/fs/cgroup
/dev/vda2 999320 2584 980352 1% /tmp
[root@graphite-storage-01 ~]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/vda3 2490368 239389 2250979 10% /
devtmpfs 483273 304 482969 1% /dev
tmpfs 485345 1 485344 1% /dev/shm
tmpfs 485345 322 485023 1% /run
tmpfs 485345 13 485332 1% /sys/fs/cgroup
/dev/vda2 65536 22 65514 1% /tmp
সম্পাদনা: স্টোরেজ নোডগুলির মধ্যে একটিকে আমি আকার বদলেছি, তবে এর কোনও প্রভাব পড়ে নি। আমি cachestat[ https://github.com/brendangregg/perf-tools + ( পারফুল সরঞ্জামগুলির সংগ্রহ) এর মধ্যেও ইউটিলিটিটি পেয়েছি যা আমাকে ভিএফএস ক্যাশের অভ্যন্তরে দেখেছে । এই মুহুর্তে দেখে মনে হচ্ছে যে আমি আমার স্টোরেজ সরবরাহ করতে পারে এমন আইও থ্রুপুটটির সীমাতে পৌঁছেছি।
এই মুহুর্তে আমি মনে করি আমাকে হয় আরও ক্লাস্টার সদস্যদের কাছে স্কেল চালিয়ে যেতে হবে, বা আরও লেখার দক্ষ সময়-সিরিজের স্টোরেজ সমাধান সন্ধানের জন্য দেখুন।
উদাহরণ থেকে আউটপুট cachestat:
storage-01 [resized disk]
HITS MISSES DIRTIES RATIO BUFFERS_MB CACHE_MB
9691 14566 7821 40.0% 160 2628
36181 14689 7802 71.1% 160 2631
8649 13617 7003 38.8% 159 2628
15567 13399 6857 53.7% 160 2627
9045 14002 7049 39.2% 160 2627
7533 12503 6153 37.6% 159 2620
storage-02 [not resized]
HITS MISSES DIRTIES RATIO BUFFERS_MB CACHE_MB
5097 11629 4740 30.5% 143 2365
5977 11045 4843 35.1% 142 2344
4356 10479 4199 29.4% 143 2364
6611 11188 4946 37.1% 143 2348
33734 14511 5930 69.9% 143 2347
7885 16353 7090 32.5% 143 2358
সুপার লেট এডিট: এর পর থেকে আমরা অন্য প্ল্যাটফর্মে স্থানান্তরিত হয়েছি যেখানে এসএসডি পাওয়া যায় এবং কিছু সময়ের জন্য জিনিসগুলি ভাল থাকত, শেষ পর্যন্ত আমরা আরও বেশি পরিমাণে মেট্রিক যুক্ত করার সাথে সাথে পারফরম্যান্সে তীব্র হ্রাস দেখতে পেলাম। যদিও আমার কাছে কোনও নির্দিষ্ট প্রমাণ নেই তবে আমি বিশ্বাস করি যে এটি কার্বন / হুইপার স্টোরেজ কীভাবে কাজ করে এবং আমরা কী পরিমাণ মেট্রিক সঞ্চয় করি তার মধ্যে এটি একটি কোণার বিষয়।
মূলত, যতক্ষণ না সিস্টেমে আরাম করে হুইস্পার ফাইলগুলি ক্যাশ করার জন্য পর্যাপ্ত র্যাম থাকে আইও পড়ার জন্য প্রায় খাঁটি লেখা এবং সবকিছুই খুশি। যাইহোক, একবার FS ক্যাশে অনাহার সেট হয়ে যায় এবং হুইস্পার ফাইলগুলি আপনার আইও ব্যান্ডউইদথের মধ্যে খায় এবং সমস্ত কিছু পটে যেতে শুরু করে নিয়মিত অফ ডিস্কে পড়া উচিত read