etcd ਲਈ ਲੋੜੀਂਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਲਈ fio ਨਾਲ ਡਿਸਕਾਂ ਦੀ ਜਾਂਚ ਕਿਵੇਂ ਕਰੀਏ

ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: ਇਹ ਲੇਖ etcd ਡੇਟਾਬੇਸ ਦੇ ਸੰਚਾਲਨ ਨਾਲ ਸਬੰਧਤ ਇੱਕ ਅਸਲ ਸਮੱਸਿਆ ਦੇ ਹੱਲ ਦੀ ਭਾਲ ਵਿੱਚ IBM ਕਲਾਉਡ ਇੰਜੀਨੀਅਰਾਂ ਦੁਆਰਾ ਕੀਤੀ ਗਈ ਇੱਕ ਮਿੰਨੀ-ਖੋਜ ਦਾ ਨਤੀਜਾ ਹੈ। ਇੱਕ ਸਮਾਨ ਕੰਮ ਸਾਡੇ ਲਈ ਢੁਕਵਾਂ ਸੀ, ਹਾਲਾਂਕਿ, ਲੇਖਕਾਂ ਦੇ ਪ੍ਰਤੀਬਿੰਬ ਅਤੇ ਕਾਰਵਾਈਆਂ ਦਾ ਕੋਰਸ ਇੱਕ ਵਿਆਪਕ ਸੰਦਰਭ ਵਿੱਚ ਦਿਲਚਸਪ ਹੋ ਸਕਦਾ ਹੈ.

ਪੂਰੇ ਲੇਖ ਦਾ ਸੰਖੇਪ ਸਾਰ: fio ਅਤੇ etcd

ਇੱਕ etcd ਕਲੱਸਟਰ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਅੰਡਰਲਾਈੰਗ ਸਟੋਰੇਜ ਦੀ ਗਤੀ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। etcd ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ ਵੱਖ-ਵੱਖ ਪ੍ਰੋਮੀਥੀਅਸ ਮੈਟ੍ਰਿਕਸ ਨਿਰਯਾਤ ਕਰਦਾ ਹੈ। ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ wal_fsync_duration_seconds. ਆਦਿ ਲਈ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਇਹ ਕਹਿੰਦਾ ਹੈਉਸ ਸਟੋਰੇਜ ਨੂੰ ਕਾਫ਼ੀ ਤੇਜ਼ੀ ਨਾਲ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜੇਕਰ ਇਸ ਮੈਟ੍ਰਿਕ ਦਾ 99ਵਾਂ ਪ੍ਰਤੀਸ਼ਤ 10 ms ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੈ...

ਜੇਕਰ ਤੁਸੀਂ ਲੀਨਕਸ ਮਸ਼ੀਨਾਂ 'ਤੇ ਇੱਕ etcd ਕਲੱਸਟਰ ਸਥਾਪਤ ਕਰਨ ਬਾਰੇ ਵਿਚਾਰ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਜਾਂਚ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਕੀ ਡਰਾਈਵਾਂ (ਜਿਵੇਂ ਕਿ SSDs) ਕਾਫ਼ੀ ਤੇਜ਼ ਹਨ, ਤਾਂ ਅਸੀਂ ਪ੍ਰਸਿੱਧ I/O ਟੈਸਟਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਿਫ਼ਾਰਿਸ਼ ਕਰਦੇ ਹਾਂ। ਫਿਓ. ਇਹ ਹੇਠ ਦਿੱਤੀ ਕਮਾਂਡ ਨੂੰ ਚਲਾਉਣ ਲਈ ਕਾਫੀ ਹੈ (ਡਾਇਰੈਕਟਰੀ 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]

ਕੁਝ ਨੋਟ:

1. ਉਪਰੋਕਤ ਉਦਾਹਰਨ ਵਿੱਚ, ਅਸੀਂ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਐਡਜਸਟ ਕੀਤਾ ਹੈ --size и --bs ਇੱਕ ਖਾਸ ਕੇਸ ਲਈ. ਤੋਂ ਇੱਕ ਸਾਰਥਕ ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ fio, ਤੁਹਾਡੇ ਵਰਤੋਂ ਕੇਸ ਲਈ ਉਚਿਤ ਮੁੱਲ ਨਿਰਧਾਰਤ ਕਰੋ। ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਚੁਣਨਾ ਹੈ ਹੇਠਾਂ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ.
2. ਸਿਰਫ ਟੈਸਟਿੰਗ ਦੌਰਾਨ fio ਡਿਸਕ ਸਬ-ਸਿਸਟਮ ਨੂੰ ਲੋਡ ਕਰਦਾ ਹੈ। ਅਸਲ ਜੀਵਨ ਵਿੱਚ, ਇਹ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਹੋਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਡਿਸਕ 'ਤੇ ਲਿਖਣਗੀਆਂ (ਨਾਲ ਸਬੰਧਤ ਉਹਨਾਂ ਤੋਂ ਇਲਾਵਾ wal_fsync_duration_seconds). ਇਹ ਵਾਧੂ ਲੋਡ ਵਧ ਸਕਦਾ ਹੈ wal_fsync_duration_seconds. ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਜੇਕਰ ਟੈਸਟਿੰਗ ਤੋਂ 99ਵਾਂ ਪ੍ਰਤੀਸ਼ਤ fio, ਸਿਰਫ 10 ms ਤੋਂ ਥੋੜ੍ਹਾ ਘੱਟ, ਇਸ ਗੱਲ ਦੀ ਚੰਗੀ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਸਟੋਰੇਜ ਪ੍ਰਦਰਸ਼ਨ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ।
3. ਟੈਸਟ ਲਈ ਤੁਹਾਨੂੰ ਵਰਜਨ ਦੀ ਲੋੜ ਪਵੇਗੀ fio 3.5 ਤੋਂ ਘੱਟ ਨਹੀਂ, ਕਿਉਂਕਿ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਨਤੀਜੇ ਇਕੱਠੇ ਨਹੀਂ ਕਰਦੇ ਹਨ fdatasync ਪ੍ਰਤੀਸ਼ਤ ਦੇ ਰੂਪ ਵਿੱਚ.
4. ਉਪਰੋਕਤ ਸਿੱਟਾ ਆਮ ਸਿੱਟੇ ਤੋਂ ਸਿਰਫ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਅੰਸ਼ ਹੈ fio.

fio ਅਤੇ etcd ਬਾਰੇ ਹੋਰ

WALs ਆਦਿ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ

ਆਮ ਤੌਰ 'ਤੇ, ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਸਰਗਰਮ ਲਾਗਿੰਗ (ਰਾਈਟ-ਅੱਗੇ ਲਾਗਿੰਗ, WAL)। etcd ਵੀ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦਾ ਹੈ। WAL ਦੀ ਚਰਚਾ ਇਸ ਲੇਖ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹੈ, ਪਰ ਸਾਡੇ ਉਦੇਸ਼ਾਂ ਲਈ, ਤੁਹਾਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਹਰੇਕ etcd ਕਲੱਸਟਰ ਮੈਂਬਰ WAL ਨੂੰ ਨਿਰੰਤਰ ਸਟੋਰੇਜ ਵਿੱਚ ਸਟੋਰ ਕਰਦਾ ਹੈ। etcd ਕੁਝ ਕੁੰਜੀ-ਮੁੱਲ ਸਟੋਰੇਜ਼ ਓਪਰੇਸ਼ਨ (ਜਿਵੇਂ ਕਿ ਅੱਪਡੇਟ) ਨੂੰ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ WAL ਨੂੰ ਲਿਖਦਾ ਹੈ। ਜੇਕਰ ਇੱਕ ਨੋਡ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਨੈਪਸ਼ਾਟ ਦੇ ਵਿਚਕਾਰ ਮੁੜ ਚਾਲੂ ਹੁੰਦਾ ਹੈ, etcd WAL ਦੀ ਸਮੱਗਰੀ ਦੇ ਆਧਾਰ 'ਤੇ ਪਿਛਲੇ ਸਨੈਪਸ਼ਾਟ ਤੋਂ ਲੈਣ-ਦੇਣ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਹੋਵੇਗਾ।

ਇਸ ਤਰ੍ਹਾਂ, ਹਰ ਵਾਰ ਜਦੋਂ ਇੱਕ ਕਲਾਇੰਟ KV ਸਟੋਰ ਵਿੱਚ ਇੱਕ ਕੁੰਜੀ ਜੋੜਦਾ ਹੈ ਜਾਂ ਮੌਜੂਦਾ ਕੁੰਜੀ ਦੇ ਮੁੱਲ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ, etcd ਓਪਰੇਸ਼ਨ ਵਰਣਨ ਨੂੰ WAL ਵਿੱਚ ਜੋੜਦਾ ਹੈ, ਜੋ ਕਿ ਨਿਰੰਤਰ ਸਟੋਰ ਵਿੱਚ ਇੱਕ ਨਿਯਮਤ ਫਾਈਲ ਹੈ। etcd ਨੂੰ 100% ਯਕੀਨੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ WAL ਐਂਟਰੀ ਨੂੰ ਅਸਲ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਲੀਨਕਸ 'ਤੇ ਇਸ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਸਿਸਟਮ ਕਾਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ write, ਕਿਉਂਕਿ ਭੌਤਿਕ ਮੀਡੀਆ ਨੂੰ ਲਿਖਣ ਦੀ ਕਾਰਵਾਈ ਵਿੱਚ ਦੇਰੀ ਹੋ ਸਕਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਲੀਨਕਸ ਕੁਝ ਸਮੇਂ ਲਈ ਇੱਕ ਇਨ-ਮੈਮੋਰੀ ਕਰਨਲ ਕੈਸ਼ (ਉਦਾਹਰਨ ਲਈ, ਪੰਨਾ ਕੈਸ਼ ਵਿੱਚ) ਵਿੱਚ ਇੱਕ WAL ਐਂਟਰੀ ਰੱਖ ਸਕਦਾ ਹੈ। ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਡੇਟਾ ਮੀਡੀਆ ਨੂੰ ਲਿਖਿਆ ਗਿਆ ਹੈ, ਲਿਖਣ ਤੋਂ ਬਾਅਦ ਇੱਕ ਸਿਸਟਮ ਕਾਲ ਨੂੰ ਬੁਲਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ fdatasync - ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜੋ etcd ਕਰਦਾ ਹੈ (ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਆਉਟਪੁੱਟ ਵਿੱਚ ਦੇਖ ਸਕਦੇ ਹੋ 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 ਕਾਲਾਂ ਦੇ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਨਾਲ etcd ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦੀ ਹੈ। ਰਿਪੋਜ਼ਟਰੀ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਸੰਕੇਤ ਕੀਤਾ, ਕਿ ਕਾਫੀ ਕਾਰਗੁਜ਼ਾਰੀ ਲਈ ਇਹ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਸਾਰੀਆਂ ਕਾਲਾਂ ਦੀ ਮਿਆਦ ਦਾ 99ਵਾਂ ਪ੍ਰਤੀਸ਼ਤ ਹੋਵੇ fdatasync ਜਦੋਂ ਇੱਕ WAL ਫਾਈਲ ਨੂੰ ਲਿਖਣਾ 10 ms ਤੋਂ ਘੱਟ ਸੀ। ਹੋਰ ਸਟੋਰੇਜ-ਸਬੰਧਤ ਮੈਟ੍ਰਿਕਸ ਹਨ, ਪਰ ਇਹ ਲੇਖ ਉਸ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰੇਗਾ।

fio ਨਾਲ ਸਟੋਰੇਜ ਦੀ ਕਦਰ ਕਰੋ

ਤੁਸੀਂ ਇਹ ਮੁਲਾਂਕਣ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਕੋਈ ਖਾਸ ਸਟੋਰੇਜ ਸਹੂਲਤ ਦੀ ਵਰਤੋਂ ਕਰਕੇ etcd ਨਾਲ ਵਰਤਣ ਲਈ ਢੁਕਵੀਂ ਹੈ ਫਿਓ — ਇੱਕ ਪ੍ਰਸਿੱਧ 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 - ਖਾਸ ਵਰਤੋਂ ਦੇ ਕੇਸ ਦੇ ਆਧਾਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ। ਅਗਲਾ ਭਾਗ ਉਹਨਾਂ ਦੀ ਸੰਰਚਨਾ ਦਾ ਵਰਣਨ ਕਰੇਗਾ।

ਅਸੀਂ fio ਨੂੰ ਕਿਉਂ ਚੁਣਿਆ ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਸੈੱਟ ਕਰਨਾ ਸਿੱਖਿਆ

ਇਹ ਨੋਟ ਇੱਕ ਅਸਲ ਕੇਸ ਤੋਂ ਆਇਆ ਹੈ ਜਿਸਦਾ ਅਸੀਂ ਸਾਹਮਣਾ ਕੀਤਾ ਹੈ। ਸਾਡੇ ਕੋਲ ਪ੍ਰੋਮੀਥੀਅਸ 'ਤੇ ਨਿਗਰਾਨੀ ਦੇ ਨਾਲ ਕੁਬਰਨੇਟਸ v1.13 'ਤੇ ਇੱਕ ਕਲੱਸਟਰ ਸੀ। SSDs ਨੂੰ etcd v3.2.24 ਲਈ ਸਟੋਰੇਜ ਵਜੋਂ ਵਰਤਿਆ ਗਿਆ ਸੀ। Etcd ਮੈਟ੍ਰਿਕਸ ਨੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੇਟੈਂਸੀਆਂ ਦਿਖਾਈਆਂ fdatasync, ਉਦੋਂ ਵੀ ਜਦੋਂ ਕਲੱਸਟਰ ਵਿਹਲਾ ਸੀ। ਸਾਡੇ ਲਈ, ਇਹ ਮੈਟ੍ਰਿਕਸ ਬਹੁਤ ਸ਼ੱਕੀ ਲੱਗਦੇ ਸਨ, ਅਤੇ ਸਾਨੂੰ ਯਕੀਨ ਨਹੀਂ ਸੀ ਕਿ ਉਹ ਅਸਲ ਵਿੱਚ ਕੀ ਦਰਸਾਉਂਦੇ ਹਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕਲੱਸਟਰ ਵਿੱਚ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਸ਼ਾਮਲ ਸਨ, ਇਸ ਲਈ ਇਹ ਕਹਿਣਾ ਸੰਭਵ ਨਹੀਂ ਸੀ ਕਿ ਕੀ ਦੇਰੀ ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਦੇ ਕਾਰਨ ਸੀ ਜਾਂ SSD ਜ਼ਿੰਮੇਵਾਰ ਸੀ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਹਾਰਡਵੇਅਰ ਅਤੇ ਸੌਫਟਵੇਅਰ ਕੌਂਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਕਈ ਤਬਦੀਲੀਆਂ 'ਤੇ ਵਿਚਾਰ ਕੀਤਾ, ਇਸਲਈ ਸਾਨੂੰ ਉਹਨਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਇੱਕ ਤਰੀਕੇ ਦੀ ਲੋੜ ਸੀ। ਬੇਸ਼ੱਕ, ਹਰੇਕ ਸੰਰਚਨਾ ਵਿੱਚ etcd ਨੂੰ ਚਲਾਉਣਾ ਅਤੇ ਸੰਬੰਧਿਤ ਪ੍ਰੋਮੀਥੀਅਸ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਵੇਖਣਾ ਸੰਭਵ ਹੋਵੇਗਾ, ਪਰ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਸਾਨੂੰ ਇੱਕ ਖਾਸ ਸੰਰਚਨਾ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਦਾ ਇੱਕ ਸਧਾਰਨ ਤਰੀਕਾ ਸੀ. ਅਸੀਂ etcd ਤੋਂ ਆਉਣ ਵਾਲੇ ਪ੍ਰੋਮੀਥੀਅਸ ਮੈਟ੍ਰਿਕਸ ਦੀ ਸਾਡੀ ਸਮਝ ਦੀ ਜਾਂਚ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ।

ਇਸ ਲਈ ਦੋ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ:

• ਪਹਿਲਾਂ, WAL ਫਾਈਲਾਂ ਨੂੰ ਲਿਖਣ ਵੇਲੇ etcd ਦੁਆਰਾ ਤਿਆਰ ਕੀਤਾ ਗਿਆ I/O ਲੋਡ ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ? ਕਿਹੜੀਆਂ ਸਿਸਟਮ ਕਾਲਾਂ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ? ਰਿਕਾਰਡ ਬਲਾਕਾਂ ਦਾ ਆਕਾਰ ਕੀ ਹੈ?
• ਦੂਜਾ, ਮੰਨ ਲਓ ਕਿ ਸਾਡੇ ਕੋਲ ਉਪਰੋਕਤ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਹਨ। ਨਾਲ ਸੰਬੰਧਿਤ ਲੋਡ ਨੂੰ ਕਿਵੇਂ ਦੁਬਾਰਾ ਤਿਆਰ ਕਰਨਾ ਹੈ fio? ਇਸ ਸਭ ਤੋਂ ਬਾਦ fio - ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਬਹੁਤਾਤ ਦੇ ਨਾਲ ਬਹੁਤ ਹੀ ਲਚਕਦਾਰ ਉਪਯੋਗਤਾ (ਇਹ ਤਸਦੀਕ ਕਰਨਾ ਆਸਾਨ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਇੱਥੇ - ਲਗਭਗ. ਅਨੁਵਾਦ।).

ਅਸੀਂ ਇੱਕੋ ਕਮਾਂਡ-ਅਧਾਰਿਤ ਪਹੁੰਚ ਨਾਲ ਦੋਵਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕੀਤਾ lsof и strace:

• ਦੀ ਸਹਾਇਤਾ ਨਾਲ lsof ਤੁਸੀਂ ਪ੍ਰਕਿਰਿਆ ਦੁਆਰਾ ਵਰਤੇ ਗਏ ਸਾਰੇ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਉਹਨਾਂ ਫਾਈਲਾਂ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ ਜਿਨ੍ਹਾਂ ਦਾ ਉਹ ਹਵਾਲਾ ਦਿੰਦੇ ਹਨ।
• ਦੀ ਸਹਾਇਤਾ ਨਾਲ strace ਤੁਸੀਂ ਪਹਿਲਾਂ ਤੋਂ ਚੱਲ ਰਹੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਚਲਾ ਸਕਦੇ ਹੋ ਅਤੇ ਇਸਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ। ਕਮਾਂਡ ਇਸ ਪ੍ਰਕਿਰਿਆ ਦੁਆਰਾ ਕੀਤੀਆਂ ਸਾਰੀਆਂ ਸਿਸਟਮ ਕਾਲਾਂ ਅਤੇ, ਜੇਕਰ ਲੋੜ ਹੋਵੇ, ਇਸ ਦੇ ਉੱਤਰਾਧਿਕਾਰੀ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੀ ਹੈ। ਬਾਅਦ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਉਹਨਾਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜੋ ਫੋਰਕ ਕਰ ਰਹੀਆਂ ਹਨ, ਅਤੇ etcd ਇੱਕ ਅਜਿਹੀ ਪ੍ਰਕਿਰਿਆ ਹੈ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਅਸੀਂ ਕੀਤਾ ਉਹ ਸੀ ਵਰਤਣਾ strace ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਵਿੱਚ etcd ਸਰਵਰ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਜਦੋਂ ਇਹ ਨਿਸ਼ਕਿਰਿਆ ਸੀ।

ਇਸ ਲਈ ਇਹ ਪਾਇਆ ਗਿਆ ਕਿ WAL ਰਿਕਾਰਡ ਬਲਾਕ ਬਹੁਤ ਸੰਘਣੇ ਸਮੂਹ ਹਨ, ਬਹੁਮਤ ਦਾ ਆਕਾਰ 2200-2400 ਬਾਈਟ ਦੀ ਰੇਂਜ ਵਿੱਚ ਸੀ। ਇਸੇ ਲਈ ਇਸ ਲੇਖ ਦੇ ਸ਼ੁਰੂ ਵਿਚ ਹੁਕਮ ਫਲੈਗ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ --bs=2300 (bs ਵਿੱਚ ਹਰੇਕ ਰਾਈਟ ਬਲਾਕ ਦੇ ਬਾਈਟਾਂ ਦਾ ਆਕਾਰ ਹੈ fio).

ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ ਕਿ etcd ਲਿਖਣ ਵਾਲੇ ਬਲਾਕਾਂ ਦਾ ਆਕਾਰ ਸੰਸਕਰਣ, ਤੈਨਾਤੀ, ਪੈਰਾਮੀਟਰ ਮੁੱਲਾਂ, ਆਦਿ ਦੇ ਅਧਾਰ ਤੇ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦਾ ਹੈ। - ਇਹ ਮਿਆਦ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ fdatasync. ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਮਾਨ ਵਰਤੋਂ ਕੇਸ ਹੈ, ਤਾਂ ਨਾਲ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੋ strace ਅਪ-ਟੂ-ਡੇਟ ਮੁੱਲਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਤੁਹਾਡੀਆਂ etcd ਪ੍ਰਕਿਰਿਆਵਾਂ।

ਫਿਰ, ਫਾਈਲ ਸਿਸਟਮ ਨਾਲ etcd ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਇਸ ਬਾਰੇ ਸਪਸ਼ਟ ਅਤੇ ਵਿਆਪਕ ਵਿਚਾਰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਅਸੀਂ ਇਸਨੂੰ ਹੇਠਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕੀਤਾ strace ਝੰਡੇ ਦੇ ਨਾਲ -ffttT. ਇਸਨੇ ਬਾਲ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਕੈਪਚਰ ਕਰਨਾ ਅਤੇ ਹਰੇਕ ਦੇ ਆਉਟਪੁੱਟ ਨੂੰ ਇੱਕ ਵੱਖਰੀ ਫਾਈਲ ਵਿੱਚ ਲਿਖਣਾ ਸੰਭਵ ਬਣਾਇਆ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਹਰੇਕ ਸਿਸਟਮ ਕਾਲ ਦੇ ਸ਼ੁਰੂ ਹੋਣ ਦੇ ਸਮੇਂ ਅਤੇ ਮਿਆਦ ਬਾਰੇ ਵਿਸਤ੍ਰਿਤ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕੀਤੀ ਗਈ ਸੀ।

ਅਸੀਂ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਵੀ ਕੀਤੀ lsofਆਉਟਪੁੱਟ ਬਾਰੇ ਤੁਹਾਡੀ ਸਮਝ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ strace ਕਿਸ ਉਦੇਸ਼ ਲਈ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ। ਮੈਂ ਸਿੱਟਾ ਕੱਢ ਲਿਆ strace, ਉਪਰੋਕਤ ਦੇ ਸਮਾਨ। ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਸਮੇਂ ਦੇ ਨਾਲ ਅੰਕੜਾ ਹੇਰਾਫੇਰੀ ਨੇ ਪੁਸ਼ਟੀ ਕੀਤੀ ਕਿ ਮੈਟ੍ਰਿਕ wal_fsync_duration_seconds etcd ਮੈਚ ਕਾਲਾਂ ਤੋਂ fdatasync WAL ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰਾਂ ਨਾਲ।

ਨਾਲ ਪੈਦਾ ਕਰਨ ਲਈ fio etcd ਤੋਂ ਸਮਾਨ ਕੰਮ ਦਾ ਬੋਝ, ਉਪਯੋਗਤਾ ਦੇ ਦਸਤਾਵੇਜ਼ਾਂ ਦਾ ਅਧਿਐਨ ਕੀਤਾ ਗਿਆ ਅਤੇ ਸਾਡੇ ਕੰਮ ਲਈ ਢੁਕਵੇਂ ਮਾਪਦੰਡ ਚੁਣੇ ਗਏ। ਅਸੀਂ ਪੁਸ਼ਟੀ ਕੀਤੀ ਹੈ ਕਿ ਸਹੀ ਸਿਸਟਮ ਕਾਲਾਂ ਚੱਲ ਰਹੀਆਂ ਹਨ ਅਤੇ ਚੱਲ ਕੇ ਉਹਨਾਂ ਦੀ ਮਿਆਦ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਹੈ fio ਤੱਕ strace (ਜਿਵੇਂ ਕਿ ਇਹ etcd ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਕੀਤਾ ਗਿਆ ਸੀ).

ਪੈਰਾਮੀਟਰ ਦੇ ਮੁੱਲ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਵਿਸ਼ੇਸ਼ ਧਿਆਨ ਦਿੱਤਾ ਗਿਆ ਸੀ --size. ਇਹ fio ਉਪਯੋਗਤਾ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਕੁੱਲ I/O ਲੋਡ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਇਹ ਮੀਡੀਆ ਨੂੰ ਲਿਖੇ ਗਏ ਬਾਈਟਾਂ ਦੀ ਕੁੱਲ ਗਿਣਤੀ ਹੈ। ਇਹ ਕਾਲਾਂ ਦੀ ਸੰਖਿਆ ਦੇ ਸਿੱਧੇ ਅਨੁਪਾਤਕ ਹੈ write (ਅਤੇ fdatasync). ਇੱਕ ਖਾਸ ਲਈ bs ਕਾਲਾਂ ਦੀ ਗਿਣਤੀ fdatasync ਬਰਾਬਰ size / bs.

ਕਿਉਂਕਿ ਅਸੀਂ ਪ੍ਰਤੀਸ਼ਤ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਸੀ, ਸਾਡਾ ਉਦੇਸ਼ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਸੀ ਕਿ ਨਮੂਨਿਆਂ ਦੀ ਗਿਣਤੀ ਅੰਕੜਾਤਮਕ ਮਹੱਤਤਾ ਲਈ ਕਾਫ਼ੀ ਵੱਡੀ ਸੀ। ਅਤੇ ਇਹ ਫੈਸਲਾ ਕੀਤਾ 10^4 (ਜੋ ਕਿ 22 MB ਦੇ ਆਕਾਰ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ) ਕਾਫੀ ਹੋਵੇਗਾ। ਛੋਟੇ ਪੈਰਾਮੀਟਰ ਮੁੱਲ --size ਵਧੇਰੇ ਸਪੱਸ਼ਟ ਸ਼ੋਰ ਦਿੱਤਾ (ਉਦਾਹਰਨ ਲਈ, ਕਾਲਾਂ fdatasync, ਜੋ ਆਮ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੈਂਦੇ ਹਨ ਅਤੇ 99ਵੇਂ ਪ੍ਰਤੀਸ਼ਤ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ)।

ਇਹ ਤੁਹਾਡੇ ਤੇ ਹੈ

ਲੇਖ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਵਰਤਣਾ ਹੈ fio ਕੋਈ ਇਹ ਮੁਲਾਂਕਣ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਕੀ etcd ਨਾਲ ਵਰਤਣ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਮੀਡੀਆ ਕਾਫ਼ੀ ਤੇਜ਼ ਹੈ। ਹੁਣ ਇਹ ਤੁਹਾਡੇ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ! ਤੁਸੀਂ ਸੇਵਾ ਵਿੱਚ SSD- ਅਧਾਰਿਤ ਸਟੋਰੇਜ ਨਾਲ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਦੀ ਪੜਚੋਲ ਕਰ ਸਕਦੇ ਹੋ ਆਈਬੀਐਮ ਬੱਦਲ.

ਅਨੁਵਾਦਕ ਤੋਂ ਪੀ.ਐਸ

ਰੈਡੀਮੇਡ ਵਰਤੋਂ ਦੇ ਕੇਸਾਂ ਦੇ ਨਾਲ fio ਹੋਰ ਕੰਮਾਂ ਲਈ, ਵੇਖੋ ਦਸਤਾਵੇਜ਼ ਜਾਂ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਪ੍ਰੋਜੈਕਟ ਰਿਪੋਜ਼ਟਰੀਆਂ (ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਜ਼ਿਕਰ ਕੀਤੇ ਗਏ ਉਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਹੋਰ ਹਨ)।

ਅਨੁਵਾਦਕ ਤੋਂ ਪੀ.ਪੀ.ਐੱਸ

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «etcd 3.4.3: ਸਟੋਰੇਜ ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਅਧਿਐਨ";
• «etcd Kubernetes ਕਲੱਸਟਰ ਵਿੱਚ ਡੇਟਾ ਦੇ ਨਾਲ ਸਾਡਾ ਅਨੁਭਵ ਸਿੱਧਾ (K8s API ਤੋਂ ਬਿਨਾਂ)";
• «ਕੁਬਰਨੇਟਸ [ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਹੱਲ] ਦੇ ਸੰਚਾਲਨ ਵਿੱਚ 6 ਮਨੋਰੰਜਕ ਸਿਸਟਮ ਬੱਗ".

ਸਰੋਤ: www.habr.com