🥇ಇತ್ಯಾದಿಗಳಿಗಾಗಿ ಸಾಕಷ್ಟು ಕಾರ್ಯಕ್ಷಮತೆಗಾಗಿ fio ನೊಂದಿಗೆ ಡಿಸ್ಕ್‌ಗಳನ್ನು ಹೇಗೆ ಪರಿಶೀಲಿಸುವುದು

ಸೂಚನೆ. ಅನುವಾದ.: ಈ ಲೇಖನವು etcd ಡೇಟಾಬೇಸ್‌ನ ಕಾರ್ಯಾಚರಣೆಗೆ ಸಂಬಂಧಿಸಿದ ನೈಜ ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರದ ಹುಡುಕಾಟದಲ್ಲಿ IBM ಕ್ಲೌಡ್ ಎಂಜಿನಿಯರ್‌ಗಳು ನಡೆಸಿದ ಕಿರು-ಸಂಶೋಧನೆಯ ಫಲಿತಾಂಶವಾಗಿದೆ. ಇದೇ ರೀತಿಯ ಕಾರ್ಯವು ನಮಗೆ ಪ್ರಸ್ತುತವಾಗಿದೆ, ಆದಾಗ್ಯೂ, ಲೇಖಕರ ಪ್ರತಿಬಿಂಬಗಳು ಮತ್ತು ಕ್ರಿಯೆಗಳ ಕೋರ್ಸ್ ವಿಶಾಲವಾದ ಸಂದರ್ಭದಲ್ಲಿ ಆಸಕ್ತಿದಾಯಕವಾಗಿರಬಹುದು.

ಸಂಪೂರ್ಣ ಲೇಖನದ ಸಂಕ್ಷಿಪ್ತ ಸಾರಾಂಶ: fio ಮತ್ತು ಇತ್ಯಾದಿ

etcd ಕ್ಲಸ್ಟರ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯು ಆಧಾರವಾಗಿರುವ ಸಂಗ್ರಹಣೆಯ ವೇಗವನ್ನು ಹೆಚ್ಚು ಅವಲಂಬಿಸಿದೆ. etcd ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ವಿವಿಧ ಪ್ರಮೀತಿಯಸ್ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ರಫ್ತು ಮಾಡುತ್ತದೆ. ಅವುಗಳಲ್ಲಿ ಒಂದು wal_fsync_duration_seconds. ಇತ್ಯಾದಿಗಳ ದಾಖಲಾತಿಯಲ್ಲಿ ಅದು ಹೇಳುತ್ತದೆಈ ಮೆಟ್ರಿಕ್‌ನ 99 ನೇ ಶೇಕಡಾವು 10 ms ಅನ್ನು ಮೀರದಿದ್ದರೆ ಸಂಗ್ರಹಣೆಯನ್ನು ಸಾಕಷ್ಟು ವೇಗವಾಗಿ ಪರಿಗಣಿಸಬಹುದು…

ನೀವು Linux ಗಣಕಗಳಲ್ಲಿ etcd ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿಸಲು ಪರಿಗಣಿಸುತ್ತಿದ್ದರೆ ಮತ್ತು ಡ್ರೈವ್‌ಗಳು (SSD ಗಳಂತಹ) ಸಾಕಷ್ಟು ವೇಗವಾಗಿದೆಯೇ ಎಂದು ಪರೀಕ್ಷಿಸಲು ಬಯಸಿದರೆ, ಜನಪ್ರಿಯ I/O ಪರೀಕ್ಷಕವನ್ನು ಬಳಸಲು ನಾವು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ fio. ಕೆಳಗಿನ ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಲು ಸಾಕು (ಡೈರೆಕ್ಟರಿ test-data ಪರೀಕ್ಷಿತ ಡ್ರೈವ್‌ನ ಆರೋಹಿತವಾದ ವಿಭಾಗದಲ್ಲಿ ನೆಲೆಗೊಂಡಿರಬೇಕು):

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

ಇದು ಔಟ್ಪುಟ್ ಅನ್ನು ನೋಡಲು ಮತ್ತು 99 ನೇ ಶೇಕಡಾವಾರು ಸರಿಹೊಂದುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಲು ಮಾತ್ರ ಉಳಿದಿದೆ fdatasync 10 ms ನಲ್ಲಿ. ಹಾಗಿದ್ದಲ್ಲಿ, ನಿಮ್ಮ ಡ್ರೈವ್ ಸಾಕಷ್ಟು ವೇಗವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ. ಉದಾಹರಣೆ ಔಟ್‌ಪುಟ್ ಇಲ್ಲಿದೆ:

fsync/fdatasync/sync_file_range:
  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

ಕೆಲವು ಟಿಪ್ಪಣಿಗಳು:

ಮೇಲಿನ ಉದಾಹರಣೆಯಲ್ಲಿ, ನಾವು ನಿಯತಾಂಕಗಳನ್ನು ಸರಿಹೊಂದಿಸಿದ್ದೇವೆ --size и --bs ಒಂದು ನಿರ್ದಿಷ್ಟ ಪ್ರಕರಣಕ್ಕೆ. ಅರ್ಥಪೂರ್ಣ ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯಲು fio, ನಿಮ್ಮ ಬಳಕೆಯ ಸಂದರ್ಭಕ್ಕೆ ಸೂಕ್ತವಾದ ಮೌಲ್ಯಗಳನ್ನು ಸೂಚಿಸಿ. ಅವುಗಳನ್ನು ಹೇಗೆ ಆರಿಸುವುದು ಎಂಬುದನ್ನು ಕೆಳಗೆ ಚರ್ಚಿಸಲಾಗುವುದು.
ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಮಾತ್ರ fio ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ. ನಿಜ ಜೀವನದಲ್ಲಿ, ಇತರ ಪ್ರಕ್ರಿಯೆಗಳು ಡಿಸ್ಕ್‌ಗೆ ಬರೆಯುವ ಸಾಧ್ಯತೆಯಿದೆ (ಸಂಬಂಧಿತವಾದವುಗಳನ್ನು ಹೊರತುಪಡಿಸಿ wal_fsync_duration_seconds) ಈ ಹೆಚ್ಚುವರಿ ಹೊರೆ ಹೆಚ್ಚಾಗಬಹುದು wal_fsync_duration_seconds. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಪರೀಕ್ಷೆಯಿಂದ 99 ನೇ ಶೇಕಡಾವಾರು fio, 10 ms ಗಿಂತ ಸ್ವಲ್ಪ ಕಡಿಮೆ ಮಾತ್ರ, ಶೇಖರಣಾ ಕಾರ್ಯಕ್ಷಮತೆಯು ಸಾಕಾಗುವುದಿಲ್ಲ ಎಂಬ ಉತ್ತಮ ಅವಕಾಶವಿದೆ.
ಪರೀಕ್ಷೆಗಾಗಿ ನಿಮಗೆ ಆವೃತ್ತಿಯ ಅಗತ್ಯವಿದೆ fio 3.5 ಕ್ಕಿಂತ ಕಡಿಮೆಯಿಲ್ಲ, ಏಕೆಂದರೆ ಹಳೆಯ ಆವೃತ್ತಿಗಳು ಫಲಿತಾಂಶಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುವುದಿಲ್ಲ fdatasync ಶೇಕಡಾವಾರು ರೂಪದಲ್ಲಿ.
ಮೇಲಿನ ತೀರ್ಮಾನವು ಸಾಮಾನ್ಯ ತೀರ್ಮಾನದಿಂದ ಒಂದು ಸಣ್ಣ ಆಯ್ದ ಭಾಗವಾಗಿದೆ fio.

ಫಿಯೋ ಮತ್ತು ಇತ್ಯಾದಿಗಳ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು

WALs ಇತ್ಯಾದಿಗಳ ಬಗ್ಗೆ ಕೆಲವು ಪದಗಳು

ಸಾಮಾನ್ಯವಾಗಿ, ಡೇಟಾಬೇಸ್ ಬಳಕೆ ಪೂರ್ವಭಾವಿ ಲಾಗಿಂಗ್ (ಬರಹ-ಮುಂದೆ ಲಾಗಿಂಗ್, WAL). ಇತ್ಯಾದಿಗಳು ಸಹ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ. WAL ನ ಚರ್ಚೆಯು ಈ ಲೇಖನದ ವ್ಯಾಪ್ತಿಯನ್ನು ಮೀರಿದೆ, ಆದರೆ ನಮ್ಮ ಉದ್ದೇಶಗಳಿಗಾಗಿ, ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕಾದದ್ದು ಪ್ರತಿಯೊಬ್ಬ etcd ಕ್ಲಸ್ಟರ್ ಸದಸ್ಯರು ನಿರಂತರ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ WAL ಅನ್ನು ಸಂಗ್ರಹಿಸುತ್ತಾರೆ. ಇತ್ಯಾದಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೊದಲು WAL ಗೆ ಕೆಲವು ಕೀ-ಮೌಲ್ಯದ ಶೇಖರಣಾ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು (ನವೀಕರಣಗಳಂತಹವು) ಬರೆಯುತ್ತದೆ. ಒಂದು ನೋಡ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ ಮತ್ತು ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳ ನಡುವೆ ಮರುಪ್ರಾರಂಭಿಸಿದರೆ, WAL ನ ವಿಷಯಗಳ ಆಧಾರದ ಮೇಲೆ ಹಿಂದಿನ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ನಿಂದ ಇತ್ಯಾದಿ ವಹಿವಾಟುಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸಬಹುದು.

ಹೀಗಾಗಿ, ಪ್ರತಿ ಬಾರಿ ಕ್ಲೈಂಟ್ KV ಸ್ಟೋರ್‌ಗೆ ಕೀಲಿಯನ್ನು ಸೇರಿಸುತ್ತದೆ ಅಥವಾ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕೀಲಿಯ ಮೌಲ್ಯವನ್ನು ನವೀಕರಿಸುತ್ತದೆ, ಇತ್ಯಾದಿಗಳು ಕಾರ್ಯಾಚರಣೆಯ ವಿವರಣೆಯನ್ನು WAL ಗೆ ಸೇರಿಸುತ್ತದೆ, ಇದು ನಿರಂತರ ಅಂಗಡಿಯಲ್ಲಿ ಸಾಮಾನ್ಯ ಫೈಲ್ ಆಗಿದೆ. ಇತ್ಯಾದಿ ಮುಂದುವರಿಯುವ ಮೊದಲು WAL ನಮೂದನ್ನು ನಿಜವಾಗಿಯೂ ಉಳಿಸಲಾಗಿದೆ ಎಂದು 100% ಖಚಿತವಾಗಿರಬೇಕು. Linux ನಲ್ಲಿ ಇದನ್ನು ಸಾಧಿಸಲು, ಸಿಸ್ಟಮ್ ಕರೆಯನ್ನು ಬಳಸುವುದು ಸಾಕಾಗುವುದಿಲ್ಲ write, ಭೌತಿಕ ಮಾಧ್ಯಮಕ್ಕೆ ಬರೆಯುವ ಕಾರ್ಯಾಚರಣೆಯು ವಿಳಂಬವಾಗಬಹುದು. ಉದಾಹರಣೆಗೆ, Linux ಕೆಲವು ಸಮಯದವರೆಗೆ ಇನ್-ಮೆಮೊರಿ ಕರ್ನಲ್ ಸಂಗ್ರಹದಲ್ಲಿ (ಉದಾ, ಪುಟ ಸಂಗ್ರಹದಲ್ಲಿ) WAL ನಮೂದನ್ನು ಇರಿಸಬಹುದು. ಡೇಟಾವನ್ನು ಮಾಧ್ಯಮಕ್ಕೆ ಬರೆಯಲಾಗಿದೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ಬರೆದ ನಂತರ ಸಿಸ್ಟಮ್ ಕರೆಯನ್ನು ಆಹ್ವಾನಿಸಬೇಕು fdatasync - ಇದು ನಿಖರವಾಗಿ ಇತ್ಯಾದಿಗಳನ್ನು ಮಾಡುತ್ತದೆ (ನೀವು ಈ ಕೆಳಗಿನ ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ನೋಡಬಹುದು strace; ಇಲ್ಲಿ 8 - WAL ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".20210220361223255266632$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

ದುರದೃಷ್ಟವಶಾತ್, ನಿರಂತರ ಸಂಗ್ರಹಣೆಗೆ ಬರೆಯಲು ಸ್ವಲ್ಪ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. fdatasync ಕರೆಗಳ ದೀರ್ಘಾವಧಿಯ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯು ಇತ್ಯಾದಿಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಹುದು. ರೆಪೊಸಿಟರಿ ದಾಖಲಾತಿಯಲ್ಲಿ ಸೂಚಿಸಲಾಗಿದೆ, ಸಾಕಷ್ಟು ಕಾರ್ಯಕ್ಷಮತೆಗಾಗಿ ಎಲ್ಲಾ ಕರೆಗಳ ಅವಧಿಯ 99 ನೇ ಶೇಕಡಾವನ್ನು ಹೊಂದಿರುವುದು ಅವಶ್ಯಕ fdatasync WAL ಫೈಲ್‌ಗೆ ಬರೆಯುವಾಗ 10 ms ಗಿಂತ ಕಡಿಮೆಯಿತ್ತು. ಇತರ ಸಂಗ್ರಹಣೆ-ಸಂಬಂಧಿತ ಮೆಟ್ರಿಕ್‌ಗಳಿವೆ, ಆದರೆ ಈ ಲೇಖನವು ಅದರ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ.

fio ನೊಂದಿಗೆ ಸಂಗ್ರಹಣೆಯನ್ನು ಮೌಲ್ಯೀಕರಿಸಲಾಗುತ್ತಿದೆ

ಯುಟಿಲಿಟಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಇತ್ಯಾದಿಗಳೊಂದಿಗೆ ಬಳಸಲು ನಿರ್ದಿಷ್ಟ ಸಂಗ್ರಹಣೆಯು ಸೂಕ್ತವಾಗಿದೆಯೇ ಎಂದು ನೀವು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬಹುದು fio - ಜನಪ್ರಿಯ I/O ಪರೀಕ್ಷಕ. ಡಿಸ್ಕ್ I/O ವಿವಿಧ ರೀತಿಯಲ್ಲಿ ಸಂಭವಿಸಬಹುದು ಎಂಬುದನ್ನು ನೆನಪಿನಲ್ಲಿಡಿ: ಸಿಂಕ್/ಅಸಿಂಕ್, ಹಲವು ವಿಭಿನ್ನ ಸಿಸ್ಕಾಲ್ ತರಗತಿಗಳು, ಇತ್ಯಾದಿ. ನಾಣ್ಯದ ಇನ್ನೊಂದು ಬದಿ ಅದು fio ಬಳಸಲು ಅತ್ಯಂತ ಕಷ್ಟ. ಉಪಯುಕ್ತತೆಯು ಅನೇಕ ನಿಯತಾಂಕಗಳನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಅವುಗಳ ಮೌಲ್ಯಗಳ ವಿಭಿನ್ನ ಸಂಯೋಜನೆಗಳು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಫಲಿತಾಂಶಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತವೆ. etcd ಗಾಗಿ ಸಮಂಜಸವಾದ ಅಂದಾಜನ್ನು ಪಡೆಯಲು, fio ನಿಂದ ರಚಿಸಲಾದ ಬರೆಯುವ ಲೋಡ್ etcd ನ WAL ಫೈಲ್ ರೈಟ್ ಲೋಡ್‌ಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಹತ್ತಿರದಲ್ಲಿದೆ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು:

ಇದರರ್ಥ ಉತ್ಪತ್ತಿಯಾಗಿದೆ fio ಲೋಡ್ ಕನಿಷ್ಠ ಫೈಲ್‌ಗೆ ಸತತ ಬರಹಗಳ ಸರಣಿಯಾಗಿರಬೇಕು, ಅಲ್ಲಿ ಪ್ರತಿ ಬರಹವು ಸಿಸ್ಟಮ್ ಕರೆಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ writeಅನುಸರಿಸಿದರು fdatasync.
ಅನುಕ್ರಮ ಬರವಣಿಗೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು, ನೀವು ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು --rw=write.
ಎಂದು fio ಕರೆಗಳನ್ನು ಬಳಸಿ ಬರೆದರು write (ಇತರ ಸಿಸ್ಟಮ್ ಕರೆಗಳಿಗಿಂತ - ಉದಾಹರಣೆಗೆ, pwrite), ಧ್ವಜವನ್ನು ಬಳಸಿ --ioengine=sync.
ಅಂತಿಮವಾಗಿ, ಧ್ವಜ --fdatasync=1 ಪ್ರತಿ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ write ಇರಬೇಕು fdatasync.
ನಮ್ಮ ಉದಾಹರಣೆಯಲ್ಲಿ ಇತರ ಎರಡು ನಿಯತಾಂಕಗಳು: --size и --bs - ನಿರ್ದಿಷ್ಟ ಬಳಕೆಯ ಸಂದರ್ಭವನ್ನು ಅವಲಂಬಿಸಿ ಬದಲಾಗಬಹುದು. ಮುಂದಿನ ವಿಭಾಗವು ಅವುಗಳ ಸಂರಚನೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ.

ನಾವು ಫಿಯೊವನ್ನು ಏಕೆ ಆರಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ಹೊಂದಿಸುವುದು ಎಂದು ನಾವು ಕಲಿತಿದ್ದೇವೆ

ನಾವು ಎದುರಿಸಿದ ನೈಜ ಪ್ರಕರಣದಿಂದ ಈ ಟಿಪ್ಪಣಿ ಬಂದಿದೆ. ನಾವು Prometheus ಮೇಲೆ ಮೇಲ್ವಿಚಾರಣೆಯೊಂದಿಗೆ Kubernetes v1.13 ನಲ್ಲಿ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. etcd v3.2.24 ಗಾಗಿ SSD ಗಳನ್ನು ಶೇಖರಣೆಯಾಗಿ ಬಳಸಲಾಗಿದೆ. Etcd ಮೆಟ್ರಿಕ್‌ಗಳು ತುಂಬಾ ಹೆಚ್ಚಿನ ಲೇಟೆನ್ಸಿಗಳನ್ನು ತೋರಿಸಿವೆ fdatasync, ಕ್ಲಸ್ಟರ್ ನಿಷ್ಕ್ರಿಯವಾಗಿದ್ದಾಗಲೂ ಸಹ. ನಮಗೆ, ಈ ಮೆಟ್ರಿಕ್‌ಗಳು ತುಂಬಾ ಸಂಶಯಾಸ್ಪದವಾಗಿ ತೋರಿದವು ಮತ್ತು ಅವು ನಿಖರವಾಗಿ ಏನನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತವೆ ಎಂದು ನಮಗೆ ಖಚಿತವಾಗಿರಲಿಲ್ಲ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕ್ಲಸ್ಟರ್ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಒಳಗೊಂಡಿತ್ತು, ಆದ್ದರಿಂದ ವಿಳಂಬವು ವರ್ಚುವಲೈಸೇಶನ್ ಕಾರಣವೇ ಅಥವಾ SSD ಅನ್ನು ದೂಷಿಸುತ್ತಿದೆಯೇ ಎಂದು ಹೇಳಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.

ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು ಹಾರ್ಡ್‌ವೇರ್ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ವಿವಿಧ ಬದಲಾವಣೆಗಳನ್ನು ಪರಿಗಣಿಸಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ನಮಗೆ ಒಂದು ಮಾರ್ಗದ ಅಗತ್ಯವಿದೆ. ಸಹಜವಾಗಿ, ಪ್ರತಿ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಇತ್ಯಾದಿಗಳನ್ನು ಚಲಾಯಿಸಲು ಮತ್ತು ಅನುಗುಣವಾದ ಪ್ರಮೀತಿಯಸ್ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ನೋಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಆದರೆ ಅದಕ್ಕೆ ಗಮನಾರ್ಹ ಪ್ರಯತ್ನದ ಅಗತ್ಯವಿರುತ್ತದೆ. ನಮಗೆ ಬೇಕಾಗಿರುವುದು ನಿರ್ದಿಷ್ಟ ಸಂರಚನೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಸರಳವಾದ ಮಾರ್ಗವಾಗಿದೆ. ಇತ್ಯಾದಿಗಳಿಂದ ಬರುವ ಪ್ರಮೀತಿಯಸ್ ಮೆಟ್ರಿಕ್‌ಗಳ ಬಗ್ಗೆ ನಮ್ಮ ತಿಳುವಳಿಕೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ನಾವು ಬಯಸಿದ್ದೇವೆ.

ಇದಕ್ಕೆ ಎರಡು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವ ಅಗತ್ಯವಿದೆ:

ಮೊದಲಿಗೆ, WAL ಫೈಲ್‌ಗಳಿಗೆ ಬರೆಯುವಾಗ ಇತ್ಯಾದಿಗಳಿಂದ ಉತ್ಪತ್ತಿಯಾಗುವ I/O ಲೋಡ್ ಹೇಗಿರುತ್ತದೆ? ಯಾವ ಸಿಸ್ಟಮ್ ಕರೆಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ? ರೆಕಾರ್ಡ್ ಬ್ಲಾಕ್‌ಗಳ ಗಾತ್ರ ಎಷ್ಟು?
ಎರಡನೆಯದಾಗಿ, ಮೇಲಿನ ಪ್ರಶ್ನೆಗಳಿಗೆ ನಮ್ಮಲ್ಲಿ ಉತ್ತರಗಳಿವೆ ಎಂದು ಹೇಳೋಣ. ಅನುಗುಣವಾದ ಲೋಡ್ ಅನ್ನು ಹೇಗೆ ಪುನರುತ್ಪಾದಿಸುವುದು fio? ಎಲ್ಲಾ ನಂತರ fio - ಪ್ಯಾರಾಮೀಟರ್‌ಗಳ ಸಮೃದ್ಧಿಯೊಂದಿಗೆ ಅತ್ಯಂತ ಹೊಂದಿಕೊಳ್ಳುವ ಉಪಯುಕ್ತತೆ (ಇದು ಪರಿಶೀಲಿಸಲು ಸುಲಭ, ಉದಾಹರಣೆಗೆ, ಇಲ್ಲಿ - ಅಂದಾಜು ಅನುವಾದ.).

ಒಂದೇ ಕಮಾಂಡ್-ಆಧಾರಿತ ವಿಧಾನದೊಂದಿಗೆ ನಾವು ಎರಡೂ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಿದ್ದೇವೆ lsof и strace:

ಸಹಾಯದಿಂದ lsof ಪ್ರಕ್ರಿಯೆಯಿಂದ ಬಳಸಲಾದ ಎಲ್ಲಾ ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ಗಳನ್ನು ನೀವು ವೀಕ್ಷಿಸಬಹುದು, ಹಾಗೆಯೇ ಅವರು ಉಲ್ಲೇಖಿಸುವ ಫೈಲ್‌ಗಳನ್ನು ವೀಕ್ಷಿಸಬಹುದು.
ಸಹಾಯದಿಂದ strace ನೀವು ಈಗಾಗಲೇ ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿಶ್ಲೇಷಿಸಬಹುದು ಅಥವಾ ಪ್ರಕ್ರಿಯೆಯನ್ನು ರನ್ ಮಾಡಬಹುದು ಮತ್ತು ಅದನ್ನು ವೀಕ್ಷಿಸಬಹುದು. ಈ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಮಾಡಿದ ಎಲ್ಲಾ ಸಿಸ್ಟಮ್ ಕರೆಗಳನ್ನು ಆಜ್ಞೆಯು ಪ್ರದರ್ಶಿಸುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯವಿದ್ದರೆ, ಅದರ ವಂಶಸ್ಥರು. ಫೋರ್ಕಿಂಗ್ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ಎರಡನೆಯದು ಮುಖ್ಯವಾಗಿದೆ ಮತ್ತು ಇತ್ಯಾದಿಗಳು ಅಂತಹ ಒಂದು ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ.

ನಾವು ಮಾಡಿದ ಮೊದಲ ಕೆಲಸವೆಂದರೆ ಬಳಸುವುದು strace ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ etcd ಸರ್ವರ್ ನಿಷ್ಕ್ರಿಯವಾಗಿದ್ದಾಗ ಅದನ್ನು ಪರೀಕ್ಷಿಸಲು.

ಆದ್ದರಿಂದ WAL ರೆಕಾರ್ಡ್ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಬಹಳ ದಟ್ಟವಾಗಿ ಗುಂಪು ಮಾಡಲಾಗಿದೆ ಎಂದು ಕಂಡುಬಂದಿದೆ, ಬಹುಪಾಲು ಗಾತ್ರವು 2200-2400 ಬೈಟ್‌ಗಳ ವ್ಯಾಪ್ತಿಯಲ್ಲಿದೆ. ಅದಕ್ಕಾಗಿಯೇ ಈ ಲೇಖನದ ಆರಂಭದಲ್ಲಿ ಆಜ್ಞೆಯು ಧ್ವಜವನ್ನು ಬಳಸುತ್ತದೆ --bs=2300 (bs ಪ್ರತಿ ರೈಟ್ ಬ್ಲಾಕ್‌ನ ಬೈಟ್‌ಗಳಲ್ಲಿ ಗಾತ್ರವಾಗಿದೆ fio).

ಆವೃತ್ತಿ, ನಿಯೋಜನೆ, ಪ್ಯಾರಾಮೀಟರ್ ಮೌಲ್ಯಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ಅವಲಂಬಿಸಿ etcd ಬರೆಯುವ ಬ್ಲಾಕ್‌ಗಳ ಗಾತ್ರವು ಬದಲಾಗಬಹುದು ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ. - ಇದು ಅವಧಿಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ fdatasync. ನೀವು ಇದೇ ರೀತಿಯ ಬಳಕೆಯ ಪ್ರಕರಣವನ್ನು ಹೊಂದಿದ್ದರೆ, ಇದರೊಂದಿಗೆ ವಿಶ್ಲೇಷಿಸಿ strace ನವೀಕೃತ ಮೌಲ್ಯಗಳನ್ನು ಪಡೆಯಲು ನಿಮ್ಮ etcd ಪ್ರಕ್ರಿಯೆಗಳು.

ನಂತರ, ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ etcd ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಸ್ಪಷ್ಟ ಮತ್ತು ಸಮಗ್ರ ಕಲ್ಪನೆಯನ್ನು ಪಡೆಯಲು, ನಾವು ಅದನ್ನು ಕೆಳಗಿನಿಂದ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ strace ಧ್ವಜಗಳೊಂದಿಗೆ -ffttT. ಇದು ಮಕ್ಕಳ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸೆರೆಹಿಡಿಯಲು ಮತ್ತು ಪ್ರತಿಯೊಂದರ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಫೈಲ್‌ಗೆ ಬರೆಯಲು ಸಾಧ್ಯವಾಗಿಸಿತು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಪ್ರತಿ ಸಿಸ್ಟಮ್ ಕರೆಯ ಪ್ರಾರಂಭದ ಸಮಯ ಮತ್ತು ಅವಧಿಯ ಬಗ್ಗೆ ವಿವರವಾದ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಲಾಗಿದೆ.

ನಾವು ಆಜ್ಞೆಯನ್ನು ಸಹ ಬಳಸಿದ್ದೇವೆ lsofಔಟ್ಪುಟ್ ಬಗ್ಗೆ ನಿಮ್ಮ ತಿಳುವಳಿಕೆಯನ್ನು ಖಚಿತಪಡಿಸಲು strace ಯಾವ ಉದ್ದೇಶಕ್ಕಾಗಿ ಯಾವ ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಅನ್ನು ಬಳಸಲಾಗಿದೆ ಎಂಬುದರ ಪರಿಭಾಷೆಯಲ್ಲಿ. ನಾನು ತೀರ್ಮಾನವನ್ನು ಪಡೆದುಕೊಂಡೆ strace, ಮೇಲಿನದನ್ನು ಹೋಲುತ್ತದೆ. ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಸಮಯಗಳೊಂದಿಗೆ ಅಂಕಿಅಂಶಗಳ ಕುಶಲತೆಯು ಮೆಟ್ರಿಕ್ ಎಂದು ದೃಢಪಡಿಸಿದೆ wal_fsync_duration_seconds ಇತ್ಯಾದಿ ಪಂದ್ಯಗಳ ಕರೆಗಳಿಂದ fdatasync WAL ಫೈಲ್ ವಿವರಣೆಗಳೊಂದಿಗೆ.

ಜೊತೆ ಉತ್ಪಾದಿಸಲು fio ಇತ್ಯಾದಿಗಳಂತೆಯೇ ಕೆಲಸದ ಹೊರೆ, ಉಪಯುಕ್ತತೆಯ ದಾಖಲಾತಿಯನ್ನು ಅಧ್ಯಯನ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ನಮ್ಮ ಕಾರ್ಯಕ್ಕೆ ಸೂಕ್ತವಾದ ನಿಯತಾಂಕಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ. ಸರಿಯಾದ ಸಿಸ್ಟಂ ಕರೆಗಳು ಪ್ರಗತಿಯಲ್ಲಿವೆ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸಿದ್ದೇವೆ ಮತ್ತು ರನ್ ಮಾಡುವ ಮೂಲಕ ಅವುಗಳ ಅವಧಿಯನ್ನು ದೃಢೀಕರಿಸಿದ್ದೇವೆ fio ನಿಂದ strace (ಇತ್ಯಾದಿ ಸಂದರ್ಭದಲ್ಲಿ ಮಾಡಿದಂತೆ).

ನಿಯತಾಂಕದ ಮೌಲ್ಯವನ್ನು ನಿರ್ಧರಿಸಲು ನಿರ್ದಿಷ್ಟ ಗಮನವನ್ನು ನೀಡಲಾಗಿದೆ --size. ಇದು fio ಯುಟಿಲಿಟಿಯಿಂದ ಉತ್ಪತ್ತಿಯಾಗುವ ಒಟ್ಟು I/O ಲೋಡ್ ಅನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಮಾಧ್ಯಮಕ್ಕೆ ಬರೆದ ಬೈಟ್‌ಗಳ ಒಟ್ಟು ಸಂಖ್ಯೆಯಾಗಿದೆ. ಇದು ಕರೆಗಳ ಸಂಖ್ಯೆಗೆ ನೇರವಾಗಿ ಅನುಪಾತದಲ್ಲಿರುತ್ತದೆ write (ಮತ್ತು fdatasync) ನಿರ್ದಿಷ್ಟವಾಗಿ bs ಕರೆಗಳ ಸಂಖ್ಯೆ fdatasync ಸಮನಾಗಿರುತ್ತದೆ size / bs.

ನಾವು ಪರ್ಸೆಂಟೈಲ್‌ನಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿರುವುದರಿಂದ, ಸಂಖ್ಯಾಶಾಸ್ತ್ರೀಯವಾಗಿ ಮಹತ್ವದ್ದಾಗಿರಲು ಮಾದರಿಗಳ ಸಂಖ್ಯೆಯು ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿರಬೇಕು ಎಂದು ನಾವು ಬಯಸುತ್ತೇವೆ. ಮತ್ತು ಅದನ್ನು ನಿರ್ಧರಿಸಿದರು 10^4 (ಇದು 22 MB ಗಾತ್ರಕ್ಕೆ ಅನುರೂಪವಾಗಿದೆ) ಸಾಕಾಗುತ್ತದೆ. ಚಿಕ್ಕ ನಿಯತಾಂಕ ಮೌಲ್ಯಗಳು --size ಹೆಚ್ಚು ಸ್ಪಷ್ಟವಾದ ಶಬ್ದವನ್ನು ನೀಡಿತು (ಉದಾಹರಣೆಗೆ, ಕರೆಗಳು fdatasync, ಇದು ಸಾಮಾನ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು 99 ನೇ ಶೇಕಡಾವನ್ನು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ).

ಇದು ನಿಮಗೆ ಬಿಟ್ಟದ್ದು

ಹೇಗೆ ಬಳಸುವುದು ಎಂಬುದನ್ನು ಲೇಖನವು ತೋರಿಸುತ್ತದೆ fio ಇತ್ಯಾದಿಗಳೊಂದಿಗೆ ಬಳಸಲು ಉದ್ದೇಶಿಸಿರುವ ಮಾಧ್ಯಮವು ಸಾಕಷ್ಟು ವೇಗವಾಗಿದೆಯೇ ಎಂದು ಒಬ್ಬರು ನಿರ್ಣಯಿಸಬಹುದು. ಈಗ ಅದು ನಿಮಗೆ ಬಿಟ್ಟದ್ದು! ಸೇವೆಯಲ್ಲಿ SSD ಆಧಾರಿತ ಸಂಗ್ರಹಣೆಯೊಂದಿಗೆ ನೀವು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಅನ್ವೇಷಿಸಬಹುದು ಐಬಿಎಂ ಮೇಘ.

ಅನುವಾದಕರಿಂದ PS

ಸಿದ್ಧ ಬಳಕೆಯ ಪ್ರಕರಣಗಳೊಂದಿಗೆ fio ಇತರ ಕಾರ್ಯಗಳಿಗಾಗಿ, ನೋಡಿ ದಸ್ತಾವೇಜನ್ನು ಅಥವಾ ನೇರವಾಗಿ ಯೋಜನೆಯ ರೆಪೊಸಿಟರಿಗಳು (ದಸ್ತಾವೇಜನ್ನು ಉಲ್ಲೇಖಿಸಿರುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನವುಗಳಿವೆ).

ಅನುವಾದಕರಿಂದ PPS

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:

ಮೂಲ: www.habr.com

ಇತ್ಯಾದಿಗಳಿಗಾಗಿ ಸಾಕಷ್ಟು ಕಾರ್ಯಕ್ಷಮತೆಗಾಗಿ fio ನೊಂದಿಗೆ ಡಿಸ್ಕ್ಗಳನ್ನು ಹೇಗೆ ಪರಿಶೀಲಿಸುವುದು