ਬਹੁਤ ਸਾਰੀ ਮੁਫਤ RAM, NVMe Intel P4500 ਅਤੇ ਸਭ ਕੁਝ ਬਹੁਤ ਹੌਲੀ ਹੈ - ਇੱਕ ਸਵੈਪ ਭਾਗ ਦੇ ਅਸਫਲ ਜੋੜ ਦੀ ਕਹਾਣੀ

ਇਸ ਲੇਖ ਵਿੱਚ, ਮੈਂ ਇੱਕ ਅਜਿਹੀ ਸਥਿਤੀ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ ਜੋ ਹਾਲ ਹੀ ਵਿੱਚ ਸਾਡੇ VPS ਕਲਾਉਡ ਵਿੱਚ ਇੱਕ ਸਰਵਰ ਨਾਲ ਵਾਪਰੀ ਸੀ, ਜਿਸ ਨੇ ਮੈਨੂੰ ਕਈ ਘੰਟਿਆਂ ਲਈ ਸਟੰਪ ਕੀਤਾ ਸੀ. ਮੈਂ ਲਗਭਗ 15 ਸਾਲਾਂ ਤੋਂ ਲੀਨਕਸ ਸਰਵਰਾਂ ਦੀ ਸੰਰਚਨਾ ਅਤੇ ਸਮੱਸਿਆ ਦਾ ਨਿਪਟਾਰਾ ਕਰ ਰਿਹਾ ਹਾਂ, ਪਰ ਇਹ ਕੇਸ ਮੇਰੇ ਅਭਿਆਸ ਵਿੱਚ ਬਿਲਕੁਲ ਵੀ ਫਿੱਟ ਨਹੀਂ ਬੈਠਦਾ - ਮੈਂ ਕਈ ਗਲਤ ਧਾਰਨਾਵਾਂ ਬਣਾਈਆਂ ਅਤੇ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਮੈਂ ਸਮੱਸਿਆ ਦੇ ਕਾਰਨ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਨਿਰਧਾਰਤ ਕਰਨ ਅਤੇ ਇਸਨੂੰ ਹੱਲ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਥੋੜਾ ਨਿਰਾਸ਼ ਹੋ ਗਿਆ. .

ਪ੍ਰਸਤਾਵਨਾ

ਅਸੀਂ ਇੱਕ ਮੱਧਮ ਆਕਾਰ ਦੇ ਕਲਾਉਡ ਦਾ ਸੰਚਾਲਨ ਕਰਦੇ ਹਾਂ, ਜਿਸ ਨੂੰ ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੀ ਸੰਰਚਨਾ ਦੇ ਨਾਲ ਮਿਆਰੀ ਸਰਵਰਾਂ 'ਤੇ ਬਣਾਉਂਦੇ ਹਾਂ - 32 ਕੋਰ, 256 GB RAM ਅਤੇ ਇੱਕ 4500TB PCI-E Intel P4 NVMe ਡਰਾਈਵ। ਸਾਨੂੰ ਅਸਲ ਵਿੱਚ ਇਹ ਸੰਰਚਨਾ ਪਸੰਦ ਹੈ ਕਿਉਂਕਿ ਇਹ VM ਉਦਾਹਰਣ ਕਿਸਮ ਦੇ ਪੱਧਰ 'ਤੇ ਸਹੀ ਪਾਬੰਦੀ ਪ੍ਰਦਾਨ ਕਰਕੇ IO ਓਵਰਹੈੱਡ ਬਾਰੇ ਚਿੰਤਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ। ਕਿਉਂਕਿ NVMe Intel P4500 ਦੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਕਾਰਗੁਜ਼ਾਰੀ ਹੈ, ਅਸੀਂ ਇੱਕੋ ਸਮੇਂ ਜ਼ੀਰੋ IOWAIT ਵਾਲੇ ਬੈਕਅੱਪ ਸਰਵਰ ਨੂੰ ਮਸ਼ੀਨਾਂ ਨੂੰ ਪੂਰੀ IOPS ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ ਅਤੇ ਬੈਕਅੱਪ ਸਟੋਰੇਜ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੇ ਹਾਂ।

ਅਸੀਂ ਉਹਨਾਂ ਪੁਰਾਣੇ ਵਿਸ਼ਵਾਸੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹਾਂ ਜੋ VM ਵਾਲੀਅਮਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਹਾਈਪਰਕਨਵਰਜਡ SDN ਅਤੇ ਹੋਰ ਸਟਾਈਲਿਸ਼, ਫੈਸ਼ਨੇਬਲ, ਜਵਾਨ ਚੀਜ਼ਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ, ਇਹ ਮੰਨਦੇ ਹੋਏ ਕਿ ਸਿਸਟਮ ਜਿੰਨਾ ਸਰਲ ਹੈ, "ਮੁੱਖ ਗੁਰੂ ਚਲਾ ਗਿਆ ਹੈ" ਦੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਇਸਦਾ ਨਿਪਟਾਰਾ ਕਰਨਾ ਓਨਾ ਹੀ ਆਸਾਨ ਹੈ। ਪਹਾੜਾਂ ਨੂੰ।" ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ VM ਵਾਲੀਅਮ ਨੂੰ QCOW2 ਫਾਰਮੈਟ ਵਿੱਚ XFS ਜਾਂ EXT4 ਵਿੱਚ ਸਟੋਰ ਕਰਦੇ ਹਾਂ, ਜੋ ਕਿ LVM2 ਦੇ ਸਿਖਰ 'ਤੇ ਤਾਇਨਾਤ ਹੈ।

ਸਾਨੂੰ ਉਸ ਉਤਪਾਦ ਦੁਆਰਾ QCOW2 ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਵੀ ਮਜ਼ਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਅਸੀਂ ਆਰਕੇਸਟ੍ਰੇਸ਼ਨ ਲਈ ਵਰਤਦੇ ਹਾਂ - Apache CloudStack.

ਇੱਕ ਬੈਕਅੱਪ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ LVM2 ਸਨੈਪਸ਼ਾਟ ਦੇ ਰੂਪ ਵਿੱਚ ਵਾਲੀਅਮ ਦਾ ਪੂਰਾ ਚਿੱਤਰ ਲੈਂਦੇ ਹਾਂ (ਹਾਂ, ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ LVM2 ਸਨੈਪਸ਼ਾਟ ਹੌਲੀ ਹਨ, ਪਰ Intel P4500 ਇੱਥੇ ਵੀ ਸਾਡੀ ਮਦਦ ਕਰਦਾ ਹੈ)। ਅਸੀਂ ਕਰਦੇ ਹਾਂ lvmcreate -s .. ਅਤੇ ਮਦਦ ਨਾਲ dd ਅਸੀਂ ZFS ਸਟੋਰੇਜ ਵਾਲੇ ਰਿਮੋਟ ਸਰਵਰ ਨੂੰ ਬੈਕਅੱਪ ਕਾਪੀ ਭੇਜਦੇ ਹਾਂ। ਇੱਥੇ ਅਸੀਂ ਅਜੇ ਵੀ ਥੋੜੇ ਪ੍ਰਗਤੀਸ਼ੀਲ ਹਾਂ - ਆਖ਼ਰਕਾਰ, ZFS ਸੰਕੁਚਿਤ ਰੂਪ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਸਟੋਰ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਵਰਤ ਕੇ ਤੇਜ਼ੀ ਨਾਲ ਰੀਸਟੋਰ ਕਰ ਸਕਦੇ ਹਾਂ DD ਜਾਂ ਵਰਤਦੇ ਹੋਏ ਵਿਅਕਤੀਗਤ VM ਵਾਲੀਅਮ ਪ੍ਰਾਪਤ ਕਰੋ mount -o loop ....

ਤੁਸੀਂ, ਬੇਸ਼ੱਕ, LVM2 ਵਾਲੀਅਮ ਦਾ ਪੂਰਾ ਚਿੱਤਰ ਨਹੀਂ ਹਟਾ ਸਕਦੇ ਹੋ, ਪਰ ਫਾਈਲ ਸਿਸਟਮ ਨੂੰ ਮਾਊਂਟ ਕਰ ਸਕਦੇ ਹੋ RO ਅਤੇ QCOW2 ਚਿੱਤਰਾਂ ਦੀ ਖੁਦ ਨਕਲ ਕਰੋ, ਹਾਲਾਂਕਿ, ਸਾਨੂੰ ਇਸ ਤੱਥ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਕਿ XFS ਇਸ ਤੋਂ ਖਰਾਬ ਹੋ ਗਿਆ, ਅਤੇ ਤੁਰੰਤ ਨਹੀਂ, ਪਰ ਇੱਕ ਅਣਪਛਾਤੇ ਤਰੀਕੇ ਨਾਲ। ਸਾਨੂੰ ਸੱਚਮੁੱਚ ਇਹ ਪਸੰਦ ਨਹੀਂ ਹੈ ਜਦੋਂ ਹਾਈਪਰਵਾਈਜ਼ਰ ਵੀਕਐਂਡ 'ਤੇ, ਰਾਤ ​​ਨੂੰ ਜਾਂ ਛੁੱਟੀਆਂ 'ਤੇ ਅਚਾਨਕ "ਸਟਿੱਕ" ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਉਹ ਕਦੋਂ ਹੋਣਗੀਆਂ। ਇਸਲਈ, XFS ਲਈ ਅਸੀਂ ਸਨੈਪਸ਼ਾਟ ਮਾਊਂਟਿੰਗ ਇਨ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ ਹਾਂ RO ਵਾਲੀਅਮ ਨੂੰ ਐਕਸਟਰੈਕਟ ਕਰਨ ਲਈ, ਅਸੀਂ ਸਿਰਫ਼ LVM2 ਵਾਲੀਅਮ ਨੂੰ ਕਾਪੀ ਕਰਦੇ ਹਾਂ।

ਬੈਕਅੱਪ ਸਰਵਰ ਤੇ ਬੈਕਅੱਪ ਦੀ ਗਤੀ ਸਾਡੇ ਕੇਸ ਵਿੱਚ ਬੈਕਅੱਪ ਸਰਵਰ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਕਿ ਸੰਕੁਚਿਤ ਡੇਟਾ ਲਈ ਲਗਭਗ 600-800 MB/s ਹੈ; ਇੱਕ ਹੋਰ ਸੀਮਾ 10Gbit/s ਚੈਨਲ ਹੈ ਜਿਸ ਨਾਲ ਬੈਕਅੱਪ ਸਰਵਰ ਜੁੜਿਆ ਹੋਇਆ ਹੈ। ਕਲੱਸਟਰ ਨੂੰ.

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, 8 ਹਾਈਪਰਵਾਈਜ਼ਰ ਸਰਵਰਾਂ ਦੀਆਂ ਬੈਕਅੱਪ ਕਾਪੀਆਂ ਇੱਕੋ ਸਮੇਂ ਇੱਕ ਬੈਕਅੱਪ ਸਰਵਰ 'ਤੇ ਅੱਪਲੋਡ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਇਸ ਤਰ੍ਹਾਂ, ਬੈਕਅੱਪ ਸਰਵਰ ਦੀ ਡਿਸਕ ਅਤੇ ਨੈੱਟਵਰਕ ਸਬ-ਸਿਸਟਮ, ਹੌਲੀ ਹੋਣ ਕਰਕੇ, ਹਾਈਪਰਵਾਈਜ਼ਰ ਹੋਸਟਾਂ ਦੇ ਡਿਸਕ ਸਬ-ਸਿਸਟਮ ਨੂੰ ਓਵਰਲੋਡ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੇ ਹਨ, ਕਿਉਂਕਿ ਉਹ ਸਿਰਫ਼ 8 GB/sec, ਜੋ ਕਿ ਹਾਈਪਰਵਾਈਜ਼ਰ ਹੋਸਟ ਆਸਾਨੀ ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹਨ। ਉਤਪਾਦਨ.

ਉਪਰੋਕਤ ਕਾਪੀ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਅਗਲੀ ਕਹਾਣੀ ਲਈ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਵੇਰਵੇ ਸਮੇਤ - ਇੱਕ ਤੇਜ਼ Intel P4500 ਡਰਾਈਵ ਦੀ ਵਰਤੋਂ ਕਰਕੇ, NFS ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਤੇ, ਸੰਭਵ ਤੌਰ 'ਤੇ, ZFS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ।

ਬੈਕਅੱਪ ਕਹਾਣੀ

ਹਰੇਕ ਹਾਈਪਰਵਾਈਜ਼ਰ ਨੋਡ 'ਤੇ ਸਾਡੇ ਕੋਲ 8 GB ਆਕਾਰ ਦਾ ਇੱਕ ਛੋਟਾ SWAP ਭਾਗ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਹਾਈਪਰਵਾਈਜ਼ਰ ਨੋਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਖੁਦ "ਰੋਲ ਆਊਟ" ਕਰਦੇ ਹਾਂ। DD ਸੰਦਰਭ ਚਿੱਤਰ ਤੋਂ. ਸਰਵਰਾਂ 'ਤੇ ਸਿਸਟਮ ਵਾਲੀਅਮ ਲਈ, ਅਸੀਂ LSI ਜਾਂ HP ਹਾਰਡਵੇਅਰ ਕੰਟਰੋਲਰ 'ਤੇ 2xSATA SSD RAID1 ਜਾਂ 2xSAS HDD RAID1 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਆਮ ਤੌਰ 'ਤੇ, ਸਾਨੂੰ ਇਸ ਗੱਲ ਦੀ ਕੋਈ ਪਰਵਾਹ ਨਹੀਂ ਹੈ ਕਿ ਅੰਦਰ ਕੀ ਹੈ, ਕਿਉਂਕਿ ਸਾਡਾ ਸਿਸਟਮ ਵਾਲੀਅਮ SWAP ਨੂੰ ਛੱਡ ਕੇ, "ਲਗਭਗ ਸਿਰਫ਼ ਪੜ੍ਹਨ ਲਈ" ਮੋਡ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ। ਅਤੇ ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਸਰਵਰ 'ਤੇ ਬਹੁਤ ਸਾਰੀ RAM ਹੈ ਅਤੇ ਇਹ 30-40% ਮੁਫਤ ਹੈ, ਅਸੀਂ ਸਵੈਪ ਬਾਰੇ ਨਹੀਂ ਸੋਚਦੇ ਹਾਂ।

ਬੈਕਅੱਪ ਪ੍ਰਕਿਰਿਆ. ਇਹ ਕੰਮ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ:

#!/bin/bash

mkdir -p /mnt/backups/volumes

DIR=/mnt/images-snap
VOL=images/volume
DATE=$(date "+%d")
HOSTNAME=$(hostname)

lvcreate -s -n $VOL-snap -l100%FREE $VOL
ionice -c3 dd iflag=direct if=/dev/$VOL-snap bs=1M of=/mnt/backups/volumes/$HOSTNAME-$DATE.raw
lvremove -f $VOL-snap

ਨੂੰ ਧਿਆਨ ਦੇਣਾ ionice -c3, ਅਸਲ ਵਿੱਚ, ਇਹ ਚੀਜ਼ NVMe ਡਿਵਾਈਸਾਂ ਲਈ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੇਕਾਰ ਹੈ, ਕਿਉਂਕਿ ਉਹਨਾਂ ਲਈ IO ਸ਼ਡਿਊਲਰ ਇਸ ਤਰ੍ਹਾਂ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ:

cat /sys/block/nvme0n1/queue/scheduler
[none] 

ਹਾਲਾਂਕਿ, ਸਾਡੇ ਕੋਲ ਰਵਾਇਤੀ SSD RAIDs ਦੇ ਨਾਲ ਬਹੁਤ ਸਾਰੇ ਵਿਰਾਸਤੀ ਨੋਡ ਹਨ, ਉਹਨਾਂ ਲਈ ਇਹ ਢੁਕਵਾਂ ਹੈ, ਇਸਲਈ ਉਹ ਅੱਗੇ ਵਧ ਰਹੇ ਹਨ AS IS. ਕੁੱਲ ਮਿਲਾ ਕੇ, ਇਹ ਕੋਡ ਦਾ ਸਿਰਫ ਇੱਕ ਦਿਲਚਸਪ ਟੁਕੜਾ ਹੈ ਜੋ ਵਿਅਰਥਤਾ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ ionice ਅਜਿਹੀ ਸੰਰਚਨਾ ਦੇ ਮਾਮਲੇ ਵਿੱਚ.

ਝੰਡੇ ਵੱਲ ਧਿਆਨ ਦਿਓ iflag=direct ਨੂੰ DD. ਅਸੀਂ ਪੜ੍ਹਨ ਵੇਲੇ IO ਬਫਰਾਂ ਦੀ ਬੇਲੋੜੀ ਤਬਦੀਲੀ ਤੋਂ ਬਚਣ ਲਈ ਬਫਰ ਕੈਸ਼ ਨੂੰ ਬਾਈਪਾਸ ਕਰਦੇ ਹੋਏ ਸਿੱਧੇ IO ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਹਾਲਾਂਕਿ, oflag=direct ਅਸੀਂ ਇਸ ਲਈ ਨਹੀਂ ਕਿਉਂਕਿ ਇਸਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਸਾਨੂੰ ZFS ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਹੈ।

ਅਸੀਂ ਇਸ ਸਕੀਮ ਨੂੰ ਕਈ ਸਾਲਾਂ ਤੋਂ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਸਫਲਤਾਪੂਰਵਕ ਵਰਤ ਰਹੇ ਹਾਂ।

ਅਤੇ ਫਿਰ ਇਹ ਸ਼ੁਰੂ ਹੋਇਆ... ਅਸੀਂ ਖੋਜਿਆ ਕਿ ਨੋਡਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦਾ ਹੁਣ ਬੈਕਅੱਪ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਪਿਛਲਾ ਇੱਕ 50% ਦੇ ਇੱਕ ਭਿਆਨਕ IOWAIT ਨਾਲ ਚੱਲ ਰਿਹਾ ਸੀ। ਜਦੋਂ ਇਹ ਸਮਝਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਨਕਲ ਕਿਉਂ ਨਹੀਂ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਸਾਨੂੰ ਹੇਠ ਲਿਖੀਆਂ ਘਟਨਾਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ:

Volume group "images" not found

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

vgcfgrestore images

ਅਸੀਂ ਇੱਕ ਬੈਕਅੱਪ ਲਾਂਚ ਕੀਤਾ ਅਤੇ ਇਸ ਤੇਲ ਪੇਂਟਿੰਗ ਨੂੰ ਦੇਖਿਆ:

ਦੁਬਾਰਾ ਅਸੀਂ ਬਹੁਤ ਉਦਾਸ ਸੀ - ਇਹ ਸਪੱਸ਼ਟ ਸੀ ਕਿ ਅਸੀਂ ਇਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਰਹਿ ਸਕਦੇ, ਕਿਉਂਕਿ ਸਾਰੇ VPS ਨੂੰ ਦੁੱਖ ਹੋਵੇਗਾ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਵੀ ਦੁੱਖ ਝੱਲਾਂਗੇ। ਕੀ ਹੋਇਆ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸਪਸ਼ਟ ਹੈ - iostat ਨੇ ਤਰਸਯੋਗ IOPS ਅਤੇ ਸਭ ਤੋਂ ਉੱਚੇ IOWAIT ਦਿਖਾਇਆ। "ਆਓ NVMe ਨੂੰ ਬਦਲੀਏ" ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਕੋਈ ਵਿਚਾਰ ਨਹੀਂ ਸਨ, ਪਰ ਸਮੇਂ ਦੇ ਨਾਲ ਹੀ ਇੱਕ ਸਮਝ ਆਈ.

ਕਦਮ ਦਰ ਕਦਮ ਸਥਿਤੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ

ਇਤਿਹਾਸਕ ਮੈਗਜ਼ੀਨ. ਕੁਝ ਦਿਨ ਪਹਿਲਾਂ, ਇਸ ਸਰਵਰ 'ਤੇ 128 ਜੀਬੀ ਰੈਮ ਦੇ ਨਾਲ ਇੱਕ ਵੱਡਾ ਵੀਪੀਐਸ ਬਣਾਉਣਾ ਜ਼ਰੂਰੀ ਸੀ। ਕਾਫ਼ੀ ਮੈਮੋਰੀ ਜਾਪਦੀ ਸੀ, ਪਰ ਸੁਰੱਖਿਅਤ ਪਾਸੇ ਹੋਣ ਲਈ, ਅਸੀਂ ਸਵੈਪ ਭਾਗ ਲਈ ਇੱਕ ਹੋਰ 32 GB ਨਿਰਧਾਰਤ ਕੀਤਾ ਹੈ। VPS ਬਣਾਇਆ ਗਿਆ ਸੀ, ਸਫਲਤਾਪੂਰਵਕ ਆਪਣਾ ਕੰਮ ਪੂਰਾ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਘਟਨਾ ਨੂੰ ਭੁੱਲ ਗਿਆ ਸੀ, ਪਰ SWAP ਭਾਗ ਰਿਹਾ।

ਸੰਰਚਨਾ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ. ਸਾਰੇ ਕਲਾਉਡ ਸਰਵਰਾਂ ਲਈ ਪੈਰਾਮੀਟਰ vm.swappiness ਡਿਫੌਲਟ ਲਈ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਸੀ 60. ਅਤੇ SWAP SAS HDD RAID1 'ਤੇ ਬਣਾਇਆ ਗਿਆ ਸੀ।

ਕੀ ਹੋਇਆ (ਸੰਪਾਦਕਾਂ ਦੇ ਅਨੁਸਾਰ). ਬੈਕਅੱਪ ਕਰਨ ਵੇਲੇ DD ਬਹੁਤ ਸਾਰਾ ਰਾਈਟ ਡਾਟਾ ਤਿਆਰ ਕੀਤਾ, ਜੋ ਕਿ NFS ਨੂੰ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ RAM ਬਫਰਾਂ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ ਸੀ। ਸਿਸਟਮ ਕੋਰ, ਨੀਤੀ ਦੁਆਰਾ ਸੇਧਿਤ swappiness, VPS ਮੈਮੋਰੀ ਦੇ ਬਹੁਤ ਸਾਰੇ ਪੰਨਿਆਂ ਨੂੰ ਸਵੈਪ ਖੇਤਰ ਵਿੱਚ ਲਿਜਾ ਰਿਹਾ ਸੀ, ਜੋ ਕਿ ਇੱਕ ਹੌਲੀ HDD RAID1 ਵਾਲੀਅਮ 'ਤੇ ਸਥਿਤ ਸੀ। ਇਸ ਨਾਲ IOWAIT ਬਹੁਤ ਮਜ਼ਬੂਤੀ ਨਾਲ ਵਧਿਆ, ਪਰ IO NVMe ਦੇ ਕਾਰਨ ਨਹੀਂ, ਪਰ IO HDD RAID1 ਦੇ ਕਾਰਨ।

ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕਿਵੇਂ ਹੋਇਆ. 32GB ਸਵੈਪ ਭਾਗ ਅਯੋਗ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਸ ਵਿੱਚ 16 ਘੰਟੇ ਲੱਗੇ; ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਕਿ SWAP ਇੰਨੀ ਹੌਲੀ-ਹੌਲੀ ਕਿਵੇਂ ਅਤੇ ਕਿਉਂ ਬੰਦ ਹੁੰਦਾ ਹੈ। ਸੈਟਿੰਗਾਂ ਬਦਲ ਦਿੱਤੀਆਂ ਗਈਆਂ ਹਨ swappiness ਦੇ ਬਰਾਬਰ ਮੁੱਲ ਲਈ 5 ਸਾਰੇ ਬੱਦਲ ਉੱਤੇ.

ਇਹ ਕਿਵੇਂ ਨਹੀਂ ਹੋ ਸਕਦਾ ਸੀ?. ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਜੇਕਰ SWAP ਇੱਕ SSD RAID ਜਾਂ NVMe ਡਿਵਾਈਸ ਤੇ ਸੀ, ਅਤੇ ਦੂਜਾ, ਜੇਕਰ ਕੋਈ NVMe ਡਿਵਾਈਸ ਨਹੀਂ ਸੀ, ਪਰ ਇੱਕ ਹੌਲੀ ਡਿਵਾਈਸ ਜੋ ਡੇਟਾ ਦੀ ਇੰਨੀ ਮਾਤਰਾ ਪੈਦਾ ਨਹੀਂ ਕਰੇਗੀ - ਵਿਅੰਗਾਤਮਕ ਤੌਰ 'ਤੇ, ਸਮੱਸਿਆ ਇਸ ਲਈ ਹੋਈ ਕਿਉਂਕਿ NVMe ਬਹੁਤ ਤੇਜ਼ ਹੈ।

ਉਸ ਤੋਂ ਬਾਅਦ, ਸਭ ਕੁਝ ਪਹਿਲਾਂ ਵਾਂਗ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ - ਜ਼ੀਰੋ IOWAIT ਨਾਲ.

ਸਰੋਤ: www.habr.com