ಇತ್ಯಾದಿಗಳಿಗೆ ಸೂಕ್ತವಾದ ಶೇಖರಣಾ ವೇಗ? ಫಿಯೋ ಕೇಳೋಣ

ಫಿಯೋ ಮತ್ತು ಇತ್ಯಾದಿಗಳ ಬಗ್ಗೆ ಒಂದು ಸಣ್ಣ ಕಥೆ

ಕ್ಲಸ್ಟರ್ ಕಾರ್ಯಕ್ಷಮತೆ ಇತ್ಯಾದಿ ಹೆಚ್ಚಾಗಿ ಅದರ ಸಂಗ್ರಹಣೆಯ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಇತ್ಯಾದಿ ಕೆಲವು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ರಫ್ತು ಮಾಡುತ್ತದೆ ಪ್ರಮೀತಿಯಸ್ಅಪೇಕ್ಷಿತ ಶೇಖರಣಾ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸಲು. ಉದಾಹರಣೆಗೆ, wal_fsync_duration_seconds ಮೆಟ್ರಿಕ್. ಇತ್ಯಾದಿಗಳಿಗೆ ದಸ್ತಾವೇಜನ್ನು ಹೇಳುತ್ತದೆ: ಸಂಗ್ರಹಣೆಯನ್ನು ಸಾಕಷ್ಟು ವೇಗವಾಗಿ ಪರಿಗಣಿಸಲು, ಈ ಮೆಟ್ರಿಕ್‌ನ 99 ನೇ ಶೇಕಡಾವಾರು 10ms ಗಿಂತ ಕಡಿಮೆಯಿರಬೇಕು. ನೀವು ಲಿನಕ್ಸ್ ಯಂತ್ರಗಳಲ್ಲಿ ಇತ್ಯಾದಿ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಚಲಾಯಿಸಲು ಯೋಜಿಸುತ್ತಿದ್ದರೆ ಮತ್ತು ನಿಮ್ಮ ಸಂಗ್ರಹಣೆಯು ಸಾಕಷ್ಟು ವೇಗವಾಗಿದೆಯೇ ಎಂದು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಬಯಸಿದರೆ (ಉದಾ. SSD), ನೀವು ಬಳಸಬಹುದು fio I/O ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಜನಪ್ರಿಯ ಸಾಧನವಾಗಿದೆ. ಕೆಳಗಿನ ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಿ, ಅಲ್ಲಿ ಟೆಸ್ಟ್-ಡೇಟಾವು ಶೇಖರಣಾ ಮೌಂಟ್ ಪಾಯಿಂಟ್ ಅಡಿಯಲ್ಲಿ ಡೈರೆಕ್ಟರಿಯಾಗಿದೆ:

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

ನೀವು ಫಲಿತಾಂಶಗಳನ್ನು ನೋಡಬೇಕು ಮತ್ತು ಅವಧಿಯ 99 ನೇ ಶೇಕಡಾವನ್ನು ಪರಿಶೀಲಿಸಬೇಕು fdatasync 10 ms ಗಿಂತ ಕಡಿಮೆ ಹಾಗಿದ್ದಲ್ಲಿ, ನೀವು ಸಮಂಜಸವಾದ ವೇಗದ ಸಂಗ್ರಹಣೆಯನ್ನು ಹೊಂದಿರುವಿರಿ. ಫಲಿತಾಂಶಗಳ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ:

  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]

ಟಿಪ್ಪಣಿಗಳು

• ನಮ್ಮ ನಿರ್ದಿಷ್ಟ ಸನ್ನಿವೇಶಕ್ಕಾಗಿ --ಗಾತ್ರ ಮತ್ತು --bs ಆಯ್ಕೆಗಳನ್ನು ನಾವು ಕಸ್ಟಮೈಸ್ ಮಾಡಿದ್ದೇವೆ. fio ನಿಂದ ಉಪಯುಕ್ತ ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯಲು, ನಿಮ್ಮ ಸ್ವಂತ ಮೌಲ್ಯಗಳನ್ನು ಒದಗಿಸಿ. ಅವುಗಳನ್ನು ಎಲ್ಲಿ ಪಡೆಯುವುದು? ಓದು ನಾವು fio ಅನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಕಲಿತಿದ್ದೇವೆ.
• ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ, ಎಲ್ಲಾ I/O ಲೋಡ್ fio ನಿಂದ ಬರುತ್ತದೆ. ನೈಜ-ಜೀವನದ ಸನ್ನಿವೇಶದಲ್ಲಿ, wal_fsync_duration_seconds ಗೆ ಸಂಬಂಧಿಸಿದವುಗಳ ಹೊರತಾಗಿ ಇತರ ಬರಹ ವಿನಂತಿಗಳು ಸಂಗ್ರಹಣೆಗೆ ಬರಬಹುದು. ಹೆಚ್ಚುವರಿ ಲೋಡ್ wal_fsync_duration_seconds ಮೌಲ್ಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಹಾಗಾಗಿ 99ನೇ ಪರ್ಸೆಂಟೈಲ್ 10ms ಗೆ ಹತ್ತಿರವಾಗಿದ್ದರೆ, ನಿಮ್ಮ ಸಂಗ್ರಹಣೆಯ ವೇಗವು ಖಾಲಿಯಾಗುತ್ತದೆ.
• ಆವೃತ್ತಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ fio 3.5 ಕ್ಕಿಂತ ಕಡಿಮೆಯಿಲ್ಲ (ಹಿಂದಿನವು fdatasync ಅವಧಿಯ ಶೇಕಡಾವಾರುಗಳನ್ನು ತೋರಿಸುವುದಿಲ್ಲ).
• ಮೇಲಿನವು ಫಿಯೋ ಫಲಿತಾಂಶಗಳ ತುಣುಕಾಗಿದೆ.

ಫಿಯೋ ಮತ್ತು ಇತ್ಯಾದಿಗಳ ಬಗ್ಗೆ ದೀರ್ಘ ಕಥೆ

ಇತ್ಯಾದಿಗಳಲ್ಲಿ WAL ಎಂದರೇನು

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

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

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

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

fio ಜೊತೆಗೆ ಅಂದಾಜು ಸಂಗ್ರಹಣೆ

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

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

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

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

ಆದರೆ ಇದಕ್ಕಾಗಿ ಎರಡು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಬೇಕಾಗಿತ್ತು. ಮೊದಲಿಗೆ, WAL ಗೆ ಬರೆಯುವಾಗ etcd ರಚಿಸುವ I/O ಲೋಡ್ ಹೇಗಿರುತ್ತದೆ? ಯಾವ ಸಿಸ್ಟಮ್ ಕರೆಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ? ದಾಖಲೆಗಳ ಗಾತ್ರ ಎಷ್ಟು? ಎರಡನೆಯದಾಗಿ, ನಾವು ಈ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಿದರೆ, fio ನೊಂದಿಗೆ ನಾವು ಇದೇ ರೀತಿಯ ಕೆಲಸದ ಹೊರೆಯನ್ನು ಹೇಗೆ ಪುನರುತ್ಪಾದಿಸಬಹುದು? ಫಿಯೋ ಹಲವು ಆಯ್ಕೆಗಳನ್ನು ಹೊಂದಿರುವ ಅತ್ಯಂತ ಹೊಂದಿಕೊಳ್ಳುವ ಸಾಧನವಾಗಿದೆ ಎಂಬುದನ್ನು ಮರೆಯಬೇಡಿ. ನಾವು ಎರಡೂ ಸಮಸ್ಯೆಗಳನ್ನು ಒಂದೇ ವಿಧಾನದಿಂದ ಪರಿಹರಿಸಿದ್ದೇವೆ - ಆಜ್ಞೆಗಳನ್ನು ಬಳಸಿ lsof и ಸ್ಟ್ರೇಸ್. lsof ಪ್ರಕ್ರಿಯೆಯಿಂದ ಬಳಸುವ ಎಲ್ಲಾ ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ಗಳು ಮತ್ತು ಅವುಗಳ ಸಂಬಂಧಿತ ಫೈಲ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. ಮತ್ತು ಸ್ಟ್ರೇಸ್ನೊಂದಿಗೆ, ನೀವು ಈಗಾಗಲೇ ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪರಿಶೀಲಿಸಬಹುದು, ಅಥವಾ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಅದನ್ನು ಪರಿಶೀಲಿಸಬಹುದು. strace ಎಲ್ಲಾ ಸಿಸ್ಟಮ್ ಕರೆಗಳನ್ನು ಪರೀಕ್ಷಿಸುವ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಮುದ್ರಿಸುತ್ತದೆ (ಮತ್ತು ಅದರ ಮಗುವಿನ ಪ್ರಕ್ರಿಯೆಗಳು). ಎರಡನೆಯದು ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ etcd ಕೇವಲ ಇದೇ ವಿಧಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಿದೆ.

ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಯಾವುದೇ ಲೋಡ್ ಇಲ್ಲದಿದ್ದಾಗ ಕುಬರ್ನೆಟ್ಸ್‌ಗಾಗಿ ಇತ್ಯಾದಿ ಸರ್ವರ್ ಅನ್ನು ಅನ್ವೇಷಿಸಲು ನಾವು ಮೊದಲು ಸ್ಟ್ರೇಸ್ ಅನ್ನು ಬಳಸಿದ್ದೇವೆ. ಬಹುತೇಕ ಎಲ್ಲಾ WAL ದಾಖಲೆಗಳು ಒಂದೇ ಗಾತ್ರದಲ್ಲಿವೆ ಎಂದು ನಾವು ನೋಡಿದ್ದೇವೆ: 2200–2400 ಬೈಟ್‌ಗಳು. ಆದ್ದರಿಂದ, ಪೋಸ್ಟ್‌ನ ಆರಂಭದಲ್ಲಿ ಆಜ್ಞೆಯಲ್ಲಿ, ನಾವು ಪ್ಯಾರಾಮೀಟರ್ -bs=2300 ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ್ದೇವೆ (ಬಿಎಸ್ ಎಂದರೆ ಪ್ರತಿ ಫಿಯೋ ಪ್ರವೇಶಕ್ಕೆ ಬೈಟ್‌ಗಳಲ್ಲಿ ಗಾತ್ರ). etcd ನಮೂನೆಯ ಗಾತ್ರವು etcd ಆವೃತ್ತಿ, ವಿತರಣೆ, ನಿಯತಾಂಕ ಮೌಲ್ಯಗಳು ಇತ್ಯಾದಿಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ ಮತ್ತು fdatasync ಅವಧಿಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ನೀವು ಇದೇ ರೀತಿಯ ಸನ್ನಿವೇಶವನ್ನು ಹೊಂದಿದ್ದರೆ, ನಿಖರವಾದ ಸಂಖ್ಯೆಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಿಮ್ಮ ಇತ್ಯಾದಿ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸ್ಟ್ರೇಸ್‌ನೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ.

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

ನಾವು fio ಗಾಗಿ ದಾಖಲಾತಿಗಳ ಮೂಲಕ ಹೋದೆವು ಮತ್ತು ನಮ್ಮ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಾಗಿ ಆಯ್ಕೆಗಳನ್ನು ಆರಿಸಿಕೊಂಡೆವು ಇದರಿಂದ fio ಇತ್ಯಾದಿಗಳಂತೆಯೇ ಲೋಡ್ ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ನಾವು ಇತ್ಯಾದಿಗಳಂತೆಯೇ strace ನಿಂದ fio ಅನ್ನು ರನ್ ಮಾಡುವ ಮೂಲಕ ಸಿಸ್ಟಂ ಕರೆಗಳು ಮತ್ತು ಅವುಗಳ ಅವಧಿಯನ್ನು ಪರಿಶೀಲಿಸಿದ್ದೇವೆ.

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

ನೀವೇ ಪ್ರಯತ್ನಿಸಿ

fio ಅನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಮತ್ತು etcd ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಸಂಗ್ರಹಣೆಯು ಸಾಕಷ್ಟು ವೇಗವಾಗಿದೆಯೇ ಎಂದು ನಾವು ನಿಮಗೆ ತೋರಿಸಿದ್ದೇವೆ. ಈಗ ನೀವು ಅದನ್ನು ಬಳಸಿಕೊಂಡು ನಿಮಗಾಗಿ ಪ್ರಯತ್ನಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, SSD ಸಂಗ್ರಹಣೆಯೊಂದಿಗೆ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು ಐಬಿಎಂ ಮೇಘ.

ಮೂಲ: www.habr.com