ฉันมีกลุ่มของเครื่องที่ใช้คาร์บอนและกราไฟต์ที่ฉันต้องปรับขนาดสำหรับการจัดเก็บข้อมูลเพิ่มเติม แต่ฉันไม่แน่ใจว่าฉันจำเป็นต้องเพิ่มหรือลดขนาด
คลัสเตอร์ปัจจุบันประกอบด้วย:
- 1 รีเลย์โหนด: รับเมตริกทั้งหมดและส่งต่อไปยังโหนดหน่วยเก็บข้อมูลที่เกี่ยวข้อง
- 6 โหนที่เก็บข้อมูล: เก็บไฟล์ Whisper DB ทั้งหมด
ปัญหาคือว่าดูเหมือนว่าเมื่อดิสก์ได้รับในการใช้งาน 80% ประสิทธิภาพการทำงานลดลงจากหน้าผา กลุ่มการเขียน IOPS ลดลงจาก 13k ใกล้คงเป็นค่าเฉลี่ยที่วุ่นวายมากขึ้นประมาณ 7k และ IOwait เวลาเฉลี่ย 54%
ฉันได้ดูผ่าน repo การตั้งค่าของเราและไม่มีการเปลี่ยนแปลงตั้งแต่ต้นเดือนเมษายนดังนั้นนี่ไม่ใช่ผลลัพธ์ของการเปลี่ยนแปลงการกำหนดค่า
คำถาม: การเพิ่มขนาดดิสก์จะทำให้ประสิทธิภาพของ IO กลับมาอยู่ภายใต้การควบคุมหรือฉันต้องเพิ่มโหนดหน่วยเก็บข้อมูลเพิ่มเติมหรือไม่
หมายเหตุ:ไม่มี SSD ที่นี่มีแกนหมุนเยอะมาก
กราฟที่เกี่ยวข้อง:
สถิติและสิ่งต่าง ๆ :
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 เหมือน (ชุดเครื่องมือ perf) ที่ให้ฉันดูในแคช VFS ณ จุดนี้ดูเหมือนว่าฉันได้ถึงขีด จำกัด ในปริมาณงาน IO ที่เก็บข้อมูลของฉันสามารถให้
ณ จุดนี้ฉันคิดว่าฉันจะต้องขยายขนาดต่อไปยังสมาชิกคลัสเตอร์เพิ่มเติมหรือดูเกี่ยวกับการค้นหาโซลูชันหน่วยเก็บข้อมูลอนุกรมเวลาแบบประหยัดยิ่งขึ้น
ตัวอย่างผลลัพธ์จาก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
การแก้ไขปลายสุด:ตั้งแต่เราย้ายไปยังแพลตฟอร์มอื่นที่มี SSD และในขณะที่สิ่งต่าง ๆ ดีในบางครั้งในที่สุดเราก็เห็นประสิทธิภาพการทำงานลดลงอย่างรวดเร็วในขณะที่เราเพิ่มการวัดมากขึ้น ในขณะที่ฉันไม่มีหลักฐานแน่ชัดฉันเชื่อว่านี่เป็นกรณีมุมระหว่างการเก็บข้อมูล Carbon / Whisper และจำนวนเมทริกที่เราจัดเก็บ
โดยทั่วไปตราบใดที่ระบบมีหน่วยความจำเพียงพอที่จะแคชไฟล์ Whisper สำหรับการอ่าน IO ได้อย่างบริสุทธิ์และเกือบทุกอย่างจะมีความสุข อย่างไรก็ตามเมื่อความอดอยากแคช FS ถูกตั้งค่าไว้และไฟล์ Whisper จำเป็นต้องอ่านอย่างต่อเนื่องในดิสก์ที่กินเข้าไปในแบนด์วิดท์ IO ของคุณและทุกอย่างจะเริ่มกระหึ่ม