ਮੇਰਾ NVMe ਇੱਕ SSD ਨਾਲੋਂ ਹੌਲੀ ਕਿਉਂ ਹੈ?

ਇਸ ਲੇਖ ਵਿਚ, ਅਸੀਂ I/O ਸਬ-ਸਿਸਟਮ ਦੀਆਂ ਕੁਝ ਸੂਖਮਤਾਵਾਂ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਉਨ੍ਹਾਂ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਦੇਖਾਂਗੇ।

ਕੁਝ ਹਫ਼ਤੇ ਪਹਿਲਾਂ ਮੈਂ ਇੱਕ ਪ੍ਰਸ਼ਨ ਵਿੱਚ ਭੱਜਿਆ ਸੀ ਕਿ ਇੱਕ ਸਰਵਰ ਤੇ NVMe ਦੂਜੇ ਸਰਵਰ ਤੇ SATA ਨਾਲੋਂ ਹੌਲੀ ਕਿਉਂ ਹੈ. ਮੈਂ ਸਰਵਰਾਂ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਦੇਖਿਆ ਅਤੇ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਇਹ ਇੱਕ ਚਾਲ ਸਵਾਲ ਸੀ: NVMe ਉਪਭੋਗਤਾ ਹਿੱਸੇ ਤੋਂ ਸੀ, ਅਤੇ SSD ਸਰਵਰ ਹਿੱਸੇ ਤੋਂ ਸੀ.

ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਵੱਖ-ਵੱਖ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਤੋਂ ਉਤਪਾਦਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨਾ ਸਹੀ ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਸੰਪੂਰਨ ਤਕਨੀਕੀ ਜਵਾਬ ਨਹੀਂ ਹੈ। ਅਸੀਂ ਮੂਲ ਗੱਲਾਂ ਦਾ ਅਧਿਐਨ ਕਰਾਂਗੇ, ਪ੍ਰਯੋਗ ਕਰਾਂਗੇ ਅਤੇ ਪੁੱਛੇ ਗਏ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਵਾਂਗੇ।

fsync ਕੀ ਹੈ ਅਤੇ ਇਹ ਕਿੱਥੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ

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

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

ਆਉ ਇੱਕ ਛੋਟੇ C ਪ੍ਰੋਗਰਾਮ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਨਕਲੀ ਉਦਾਹਰਣ ਦੇ ਨਾਲ ਬਫਰਾਂ ਦੇ ਪ੍ਰਭਾਵ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਕਰੀਏ।

#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>

int main(void) {
    /* Открываем файл answer.txt на запись, если его нет -- создаём */
    int fd = open("answer.txt", O_WRONLY | O_CREAT);
    /* Записываем первый набор данных */
    write(fd, "Answer to the Ultimate Question of Life, The Universe, and Everything: ", 71);
    /* Делаем вид, что проводим вычисления в течение 10 секунд */
    sleep(10);
    /* Записываем результат вычислений */
    write(fd, "42n", 3); 

    return 0;
}

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

ਡੇਟਾਬੇਸ ਇੱਕ ਗੁੰਝਲਦਾਰ ਪ੍ਰੋਗਰਾਮ ਹੁੰਦੇ ਹਨ ਜੋ ਇੱਕੋ ਸਮੇਂ ਬਹੁਤ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ, ਇਸਲਈ ਉਹ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਉਹਨਾਂ ਦੁਆਰਾ ਲਿਖੇ ਡੇਟਾ ਨੂੰ ਡਰਾਈਵ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਵੇਗਾ, ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਵਿੱਚ ਡੇਟਾ ਦੀ ਇਕਸਾਰਤਾ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਡੇਟਾਬੇਸ ਸਾਰੇ ਮੁਕੰਮਲ ਲੈਣ-ਦੇਣ ਨੂੰ ਰਿਕਾਰਡ ਕਰਨ ਅਤੇ ਕਿਸੇ ਵੀ ਸਮੇਂ ਪਾਵਰ ਆਊਟੇਜ ਲਈ ਤਿਆਰ ਰਹਿਣ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ। ਇਹ ਵਿਵਹਾਰ ਤੁਹਾਨੂੰ ਲਗਾਤਾਰ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ fsync ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ।

fsync ਦੀ ਲਗਾਤਾਰ ਵਰਤੋਂ ਨੂੰ ਕੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ

ਆਮ I/O ਦੇ ਨਾਲ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਡਿਸਕ ਸੰਚਾਰ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਬਾਹਰੀ ਡਰਾਈਵਾਂ ਮੈਮੋਰੀ ਲੜੀ ਵਿੱਚ ਸਭ ਤੋਂ ਹੌਲੀ ਹੁੰਦੀਆਂ ਹਨ। ਇਸ ਲਈ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਡਰਾਈਵ ਦੀ ਇੱਕ ਪਹੁੰਚ ਵਿੱਚ ਵੱਧ ਤੋਂ ਵੱਧ ਡਾਟਾ ਲਿਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।

ਆਉ ਇੱਕ ਖਾਸ ਉਦਾਹਰਣ ਦੇ ਨਾਲ fsync ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰੀਏ। ਸਾਡੇ ਕੋਲ ਟੈਸਟ ਦੇ ਵਿਸ਼ਿਆਂ ਵਜੋਂ ਹੇਠਾਂ ਦਿੱਤੇ SSDs ਹਨ:

• Intel® DC SSD S4500 480 GB, SATA 3.2, 6 Gb/s ਦੁਆਰਾ ਜੁੜਿਆ;
• Samsung 970 EVO Plus 500GB, PCIe 3.0 x4, ~31 Gbps ਰਾਹੀਂ ਕਨੈਕਟ ਕੀਤਾ ਗਿਆ।

ਟੈਸਟ Ubuntu 2255 'ਤੇ ਚੱਲ ਰਹੇ Intel® Xeon® W-20.04 'ਤੇ ਕਰਵਾਏ ਜਾਂਦੇ ਹਨ। ਡਿਸਕਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ, sysbench 1.0.18 ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਡਿਸਕਾਂ ਦਾ ਇੱਕ ਸਿੰਗਲ ਭਾਗ ext4 ਦੇ ਰੂਪ ਵਿੱਚ ਫਾਰਮੈਟ ਕੀਤਾ ਗਿਆ ਹੈ। ਟੈਸਟ ਦੀ ਤਿਆਰੀ 100 GB ਫਾਈਲਾਂ ਬਣਾਉਣਾ ਹੈ:

sysbench --test=fileio --file-total-size=100G prepare

ਚੱਲ ਰਹੇ ਟੈਸਟ:

# Без fsync
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=0 run

# С fsync после каждой записи
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=1 run

ਟੈਸਟ ਦੇ ਨਤੀਜੇ ਸਾਰਣੀ ਵਿੱਚ ਪੇਸ਼ ਕੀਤੇ ਗਏ ਹਨ.

ਟੈਸਟ
Intel® S4500
Samsung 970 EVO+

fsync, MiB/s ਤੋਂ ਬਿਨਾਂ ਪੜ੍ਹੋ
5734.89
9028.86

fsync, MiB/s ਤੋਂ ਬਿਨਾਂ ਲਿਖੋ
3823.26
6019.24

fsync, MiB/s ਨਾਲ ਪੜ੍ਹਨਾ
37.76
3.27

fsync, MiB/s ਨਾਲ ਰਿਕਾਰਡਿੰਗ
25.17
2.18

ਇਹ ਦੇਖਣਾ ਆਸਾਨ ਹੈ ਕਿ ਕਲਾਇੰਟ ਖੰਡ ਤੋਂ NVMe ਭਰੋਸੇ ਨਾਲ ਅਗਵਾਈ ਕਰਦਾ ਹੈ ਜਦੋਂ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਖੁਦ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਡਿਸਕਾਂ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ, ਅਤੇ ਜਦੋਂ fsync ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਹਾਰ ਜਾਂਦੀ ਹੈ। ਇਹ ਦੋ ਸਵਾਲ ਪੈਦਾ ਕਰਦਾ ਹੈ:

1. fsync ਦੇ ਬਿਨਾਂ ਟੈਸਟ ਵਿੱਚ ਪੜ੍ਹਨ ਦੀ ਗਤੀ ਲਿੰਕ ਦੀ ਭੌਤਿਕ ਬੈਂਡਵਿਡਥ ਤੋਂ ਵੱਧ ਕਿਉਂ ਹੈ?
2. ਇੱਕ ਸਰਵਰ ਖੰਡ SSD ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ fsync ਬੇਨਤੀਆਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਬਿਹਤਰ ਕਿਉਂ ਹੈ?

ਪਹਿਲੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਸਧਾਰਨ ਹੈ: sysbench ਜ਼ੀਰੋ-ਭਰੀਆਂ ਫਾਈਲਾਂ ਤਿਆਰ ਕਰਦਾ ਹੈ. ਇਸ ਤਰ੍ਹਾਂ, ਟੈਸਟ 100 ਗੀਗਾਬਾਈਟ ਜ਼ੀਰੋ ਤੋਂ ਵੱਧ ਕੀਤਾ ਗਿਆ ਸੀ। ਕਿਉਂਕਿ ਡੇਟਾ ਬਹੁਤ ਇਕਸਾਰ ਅਤੇ ਅਨੁਮਾਨਯੋਗ ਹੈ, ਇਸ ਲਈ ਵੱਖ-ਵੱਖ OS ਅਨੁਕੂਲਤਾਵਾਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਉਹ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਕਰਦੇ ਹਨ।

ਜੇਕਰ ਤੁਸੀਂ sysbench ਦੇ ਸਾਰੇ ਨਤੀਜਿਆਂ 'ਤੇ ਸਵਾਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ fio ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ.

# Без fsync
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=0 --filename=/dev/sdb

# С fsync после каждой записи
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=1 --filename=/dev/sdb

ਟੈਸਟ
Intel® S4500
Samsung 970 EVO+

fsync, MiB/s ਤੋਂ ਬਿਨਾਂ ਪੜ੍ਹੋ
45.5
178

fsync, MiB/s ਤੋਂ ਬਿਨਾਂ ਲਿਖੋ
30.4
119

fsync, MiB/s ਨਾਲ ਪੜ੍ਹਨਾ
32.6
20.9

fsync, MiB/s ਨਾਲ ਰਿਕਾਰਡਿੰਗ
21.7
13.9

Fsync ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ NVMe ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਗਿਰਾਵਟ ਦਾ ਰੁਝਾਨ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਦੂਜੇ ਸਵਾਲ 'ਤੇ ਜਾ ਸਕਦੇ ਹੋ।

ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਜਾਂ ਬਲਫ

ਪਹਿਲਾਂ ਅਸੀਂ ਕਿਹਾ ਸੀ ਕਿ ਡੇਟਾ ਇੱਕ ਬਫਰ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਇਹ ਨਹੀਂ ਦੱਸਿਆ ਕਿ ਕਿਸ ਵਿੱਚ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਸੀ। ਹੁਣ ਵੀ ਅਸੀਂ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਦੀਆਂ ਪੇਚੀਦਗੀਆਂ ਬਾਰੇ ਨਹੀਂ ਸੋਚਾਂਗੇ ਅਤੇ ਦੋ ਆਮ ਕਿਸਮਾਂ ਦੇ ਬਫਰਾਂ ਨੂੰ ਇੱਕਲੇ ਨਹੀਂ ਕਰਾਂਗੇ:

• ਪ੍ਰੋਗਰਾਮ;
• ਹਾਰਡਵੇਅਰ।

ਸਾਫਟਵੇਅਰ ਬਫਰ ਉਹਨਾਂ ਬਫਰਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਵਿੱਚ ਹਨ, ਅਤੇ ਹਾਰਡਵੇਅਰ ਬਫਰ ਡਿਸਕ ਕੰਟਰੋਲਰ ਦੀ ਅਸਥਿਰ ਮੈਮੋਰੀ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। fsync ਸਿਸਟਮ ਕਾਲ ਇਸਦੇ ਬਫਰ ਤੋਂ ਮੁੱਖ ਸਟੋਰੇਜ਼ ਵਿੱਚ ਡਾਟਾ ਲਿਖਣ ਲਈ ਡਰਾਈਵ ਨੂੰ ਇੱਕ ਕਮਾਂਡ ਭੇਜਦੀ ਹੈ, ਪਰ ਇਸ ਕੋਲ ਕਮਾਂਡ ਦੇ ਸਹੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ।

ਕਿਉਂਕਿ SSD ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦਾ ਹੈ, ਦੋ ਧਾਰਨਾਵਾਂ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ:

• ਡਿਸਕ ਨੂੰ ਇੱਕ ਸਮਾਨ ਯੋਜਨਾ ਦੇ ਲੋਡ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ;
• ਡਿਸਕ "bluffs" ਅਤੇ ਕਮਾਂਡ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੀ ਹੈ।

ਡਰਾਈਵ ਦੇ ਬੇਈਮਾਨ ਵਿਵਹਾਰ ਨੂੰ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਪਾਵਰ ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਨਾਲ ਇੱਕ ਟੈਸਟ ਕਰਦੇ ਹੋ. ਤੁਸੀਂ ਇਸ ਨੂੰ ਸਕ੍ਰਿਪਟ ਨਾਲ ਚੈੱਕ ਕਰ ਸਕਦੇ ਹੋ। diskchecker.pl, ਜੋ ਕਿ ਸੀ ਦੀ ਸਥਾਪਨਾ 2005 ਸਾਲ ਵਿਚ

ਇਸ ਸਕ੍ਰਿਪਟ ਲਈ ਦੋ ਭੌਤਿਕ ਮਸ਼ੀਨਾਂ ਦੀ ਲੋੜ ਹੈ - "ਸਰਵਰ" ਅਤੇ "ਕਲਾਇੰਟ"। ਕਲਾਇੰਟ ਟੈਸਟ ਦੇ ਅਧੀਨ ਡਰਾਈਵ 'ਤੇ ਥੋੜਾ ਜਿਹਾ ਡੇਟਾ ਲਿਖਦਾ ਹੈ, fsync ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਨੂੰ ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਭੇਜਦਾ ਹੈ ਕਿ ਕੀ ਲਿਖਿਆ ਗਿਆ ਸੀ।

# Запускается на сервере
./diskchecker.pl -l [port]

# Запускается на клиенте
./diskchecker.pl -s <server[:port]> create <file> <size_in_MB>

ਸਕ੍ਰਿਪਟ ਨੂੰ ਚਲਾਉਣ ਤੋਂ ਬਾਅਦ, "ਕਲਾਇੰਟ" ਨੂੰ ਡੀ-ਐਨਰਜੀਜ਼ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ ਅਤੇ ਕਈ ਮਿੰਟਾਂ ਲਈ ਪਾਵਰ ਵਾਪਸ ਨਾ ਕਰੋ। ਟੈਸਟ ਦੇ ਵਿਸ਼ੇ ਨੂੰ ਬਿਜਲੀ ਤੋਂ ਡਿਸਕਨੈਕਟ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਸਖ਼ਤ ਬੰਦ ਕਰਨਾ। ਕੁਝ ਸਮੇਂ ਬਾਅਦ, ਸਰਵਰ ਨੂੰ ਕਨੈਕਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ OS ਵਿੱਚ ਲੋਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। OS ਨੂੰ ਬੂਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ diskchecker.pl, ਪਰ ਇੱਕ ਦਲੀਲ ਨਾਲ ਜਾਂਚ ਕਰੋ.

./diskchecker.pl -s <server[:port]> verify <file>

ਜਾਂਚ ਦੇ ਅੰਤ ਵਿੱਚ, ਤੁਸੀਂ ਗਲਤੀਆਂ ਦੀ ਸੰਖਿਆ ਵੇਖੋਗੇ। ਜੇਕਰ ਉਹ 0 ਹਨ, ਤਾਂ ਡਿਸਕ ਨੇ ਟੈਸਟ ਪਾਸ ਕੀਤਾ ਹੈ। ਡਿਸਕ ਲਈ ਸਫਲ ਹੋਣ ਵਾਲੇ ਹਾਲਾਤਾਂ ਦੇ ਸੁਮੇਲ ਨੂੰ ਬਾਹਰ ਕੱਢਣ ਲਈ, ਪ੍ਰਯੋਗ ਨੂੰ ਕਈ ਵਾਰ ਦੁਹਰਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।

ਸਾਡੇ S4500 ਨੇ ਬਿਜਲੀ ਦੇ ਨੁਕਸਾਨ ਦੀਆਂ ਕੋਈ ਤਰੁੱਟੀਆਂ ਨਹੀਂ ਦਿਖਾਈਆਂ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਬਹੁਤ ਸਾਰੀਆਂ fsync ਕਾਲਾਂ ਨਾਲ ਲੋਡ ਕਰਨ ਲਈ ਤਿਆਰ ਹੈ।

ਸਿੱਟਾ

ਡਿਸਕਾਂ ਜਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤਿਆਰ ਕੀਤੀਆਂ ਸੰਰਚਨਾਵਾਂ ਦੀ ਚੋਣ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਕਾਰਜਾਂ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ, ਇਹ ਸਪੱਸ਼ਟ ਜਾਪਦਾ ਹੈ ਕਿ NVMe, ਯਾਨੀ ਇੱਕ PCIe ਇੰਟਰਫੇਸ ਵਾਲਾ ਇੱਕ SSD, ਇੱਕ "ਕਲਾਸਿਕ" SATA SSD ਨਾਲੋਂ ਤੇਜ਼ ਹੈ। ਹਾਲਾਂਕਿ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਅੱਜ ਸਮਝ ਚੁੱਕੇ ਹਾਂ, ਖਾਸ ਸਥਿਤੀਆਂ ਵਿੱਚ ਅਤੇ ਕੁਝ ਖਾਸ ਕੰਮਾਂ ਵਿੱਚ ਅਜਿਹਾ ਨਹੀਂ ਹੋ ਸਕਦਾ।

ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ IaaS ਪ੍ਰਦਾਤਾ ਤੋਂ ਕਿਰਾਏ 'ਤੇ ਲੈਂਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਸਰਵਰ ਭਾਗਾਂ ਦੀ ਜਾਂਚ ਕਿਵੇਂ ਕਰਦੇ ਹੋ?
ਅਸੀਂ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਤੁਹਾਡੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹਾਂ।

ਸਰੋਤ: www.habr.com