ಬಹಳಷ್ಟು ಉಚಿತ RAM, NVMe Intel P4500 ಮತ್ತು ಎಲ್ಲವೂ ತುಂಬಾ ನಿಧಾನ - ಸ್ವಾಪ್ ವಿಭಾಗದ ವಿಫಲ ಸೇರ್ಪಡೆಯ ಕಥೆ

ಈ ಲೇಖನದಲ್ಲಿ, ನಮ್ಮ VPS ಕ್ಲೌಡ್‌ನಲ್ಲಿನ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಇತ್ತೀಚೆಗೆ ಸಂಭವಿಸಿದ ಪರಿಸ್ಥಿತಿಯ ಬಗ್ಗೆ ನಾನು ಮಾತನಾಡುತ್ತೇನೆ, ಅದು ನನ್ನನ್ನು ಹಲವಾರು ಗಂಟೆಗಳ ಕಾಲ ಸ್ಟಂಪ್ ಮಾಡಿತು. ನಾನು ಸುಮಾರು 15 ವರ್ಷಗಳಿಂದ ಲಿನಕ್ಸ್ ಸರ್ವರ್‌ಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತಿದ್ದೇನೆ ಮತ್ತು ದೋಷನಿವಾರಣೆ ಮಾಡುತ್ತಿದ್ದೇನೆ, ಆದರೆ ಈ ಪ್ರಕರಣವು ನನ್ನ ಅಭ್ಯಾಸಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ - ನಾನು ಹಲವಾರು ತಪ್ಪು ಊಹೆಗಳನ್ನು ಮಾಡಿದ್ದೇನೆ ಮತ್ತು ಸಮಸ್ಯೆಯ ಕಾರಣವನ್ನು ಸರಿಯಾಗಿ ನಿರ್ಧರಿಸಲು ಮತ್ತು ಅದನ್ನು ಪರಿಹರಿಸುವ ಮೊದಲು ನಾನು ಸ್ವಲ್ಪ ಹತಾಶನಾಗಿದ್ದೇನೆ. .

ಮುನ್ನುಡಿ

ನಾವು ಮಧ್ಯಮ ಗಾತ್ರದ ಕ್ಲೌಡ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತೇವೆ, ಇದನ್ನು ನಾವು ಈ ಕೆಳಗಿನ ಕಾನ್ಫಿಗರೇಶನ್‌ನೊಂದಿಗೆ ಪ್ರಮಾಣಿತ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ನಿರ್ಮಿಸುತ್ತೇವೆ - 32 ಕೋರ್‌ಗಳು, 256 GB RAM ಮತ್ತು 4500TB PCI-E Intel P4 NVMe ಡ್ರೈವ್. ನಾವು ಈ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನಿಜವಾಗಿಯೂ ಇಷ್ಟಪಡುತ್ತೇವೆ ಏಕೆಂದರೆ ಇದು VM ನಿದರ್ಶನ ಪ್ರಕಾರದ ಮಟ್ಟದಲ್ಲಿ ಸರಿಯಾದ ನಿರ್ಬಂಧವನ್ನು ಒದಗಿಸುವ ಮೂಲಕ IO ಓವರ್ಹೆಡ್ ಬಗ್ಗೆ ಚಿಂತಿಸುವ ಅಗತ್ಯವನ್ನು ನಿವಾರಿಸುತ್ತದೆ. ಏಕೆಂದರೆ NVMe ಇಂಟೆಲ್ P4500 ಪ್ರಭಾವಶಾಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೊಂದಿದೆ, ನಾವು ಏಕಕಾಲದಲ್ಲಿ ಪೂರ್ಣ IOPS ಒದಗಿಸುವಿಕೆಯನ್ನು ಯಂತ್ರಗಳಿಗೆ ಮತ್ತು ಬ್ಯಾಕಪ್ ಸಂಗ್ರಹಣೆಯನ್ನು ಶೂನ್ಯ IOWAIT ಯೊಂದಿಗೆ ಬ್ಯಾಕಪ್ ಸರ್ವರ್‌ಗೆ ಒದಗಿಸಬಹುದು.

VM ಸಂಪುಟಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಹೈಪರ್‌ಕನ್ವರ್ಜ್ಡ್ ಎಸ್‌ಡಿಎನ್ ಮತ್ತು ಇತರ ಸೊಗಸಾದ, ಫ್ಯಾಶನ್, ಯುವ ವಸ್ತುಗಳನ್ನು ಬಳಸದ ಹಳೆಯ ನಂಬಿಕೆಯುಳ್ಳವರಲ್ಲಿ ನಾವು ಒಬ್ಬರಾಗಿದ್ದೇವೆ, ಸರಳವಾದ ಸಿಸ್ಟಮ್, “ಮುಖ್ಯ ಗುರುಗಳು ಹೋಗಿದ್ದಾರೆ” ಎಂಬ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಅದನ್ನು ನಿವಾರಿಸುವುದು ಸುಲಭ ಎಂದು ನಂಬುತ್ತಾರೆ. ಪರ್ವತಗಳಿಗೆ." ಪರಿಣಾಮವಾಗಿ, ನಾವು 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 ಜಿಬಿ/ಸೆಕೆಂಡ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಅವು ಸರಳವಾಗಿ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಉತ್ಪಾದಿಸು.

ಮೇಲಿನ ನಕಲು ಪ್ರಕ್ರಿಯೆಯು ವಿವರಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಮುಂದಿನ ಕಥೆಗೆ ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ - ವೇಗದ Intel P4500 ಡ್ರೈವ್ ಅನ್ನು ಬಳಸುವುದು, NFS ಅನ್ನು ಬಳಸುವುದು ಮತ್ತು ಬಹುಶಃ ZFS ಅನ್ನು ಬಳಸುವುದು.

ಬ್ಯಾಕಪ್ ಕಥೆ

ಪ್ರತಿ ಹೈಪರ್ವೈಸರ್ ನೋಡ್ನಲ್ಲಿ ನಾವು 8 GB ಗಾತ್ರದ ಸಣ್ಣ SWAP ವಿಭಾಗವನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಹೈಪರ್ವೈಸರ್ ನೋಡ್ ಅನ್ನು ಸ್ವತಃ "ರೋಲ್ ಔಟ್" ಮಾಡುತ್ತೇವೆ DD ಉಲ್ಲೇಖ ಚಿತ್ರದಿಂದ. ಸರ್ವರ್‌ಗಳಲ್ಲಿನ ಸಿಸ್ಟಮ್ ವಾಲ್ಯೂಮ್‌ಗಾಗಿ, ನಾವು LSI ಅಥವಾ HP ಹಾರ್ಡ್‌ವೇರ್ ನಿಯಂತ್ರಕದಲ್ಲಿ 2xSATA SSD RAID1 ಅಥವಾ 2xSAS HDD RAID1 ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಸಾಮಾನ್ಯವಾಗಿ, SWAP ಹೊರತುಪಡಿಸಿ, ನಮ್ಮ ಸಿಸ್ಟಂ ಪರಿಮಾಣವು "ಬಹುತೇಕ ಓದಲು ಮಾತ್ರ" ಮೋಡ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದರಿಂದ ನಾವು ಒಳಗಿರುವ ಎಲ್ಲದರ ಬಗ್ಗೆ ಕಾಳಜಿ ವಹಿಸುವುದಿಲ್ಲ. ಮತ್ತು ನಾವು ಸರ್ವರ್‌ನಲ್ಲಿ ಸಾಕಷ್ಟು RAM ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಅದು 30-40% ಉಚಿತವಾಗಿದೆ, ನಾವು SWAP ಬಗ್ಗೆ ಯೋಚಿಸುವುದಿಲ್ಲ.

ಬ್ಯಾಕಪ್ ಪ್ರಕ್ರಿಯೆ. ಈ ಕಾರ್ಯವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

#!/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 RAIDಗಳೊಂದಿಗೆ ಹಲವಾರು ಲೆಗಸಿ ನೋಡ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅವರಿಗೆ ಇದು ಪ್ರಸ್ತುತವಾಗಿದೆ, ಆದ್ದರಿಂದ ಅವು ಚಲಿಸುತ್ತಿವೆ ಹೇಗಿದೆಯೋ ಹಾಗೆ. ಒಟ್ಟಾರೆಯಾಗಿ, ಇದು ನಿರರ್ಥಕತೆಯನ್ನು ವಿವರಿಸುವ ಒಂದು ಆಸಕ್ತಿದಾಯಕ ಕೋಡ್ ಆಗಿದೆ ionice ಅಂತಹ ಸಂರಚನೆಯ ಸಂದರ್ಭದಲ್ಲಿ.

ಧ್ವಜಕ್ಕೆ ಗಮನ ಕೊಡಿ iflag=direct ಗೆ DD. ಓದುವಾಗ IO ಬಫರ್‌ಗಳನ್ನು ಅನಗತ್ಯವಾಗಿ ಬದಲಾಯಿಸುವುದನ್ನು ತಪ್ಪಿಸಲು ನಾವು ಬಫರ್ ಸಂಗ್ರಹವನ್ನು ಬೈಪಾಸ್ ಮಾಡುವ ನೇರ IO ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಆದಾಗ್ಯೂ, oflag=direct ZFS ಅನ್ನು ಬಳಸುವಾಗ ನಾವು ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಿದ ಕಾರಣ ನಾವು ಹಾಗೆ ಮಾಡುವುದಿಲ್ಲ.

ನಾವು ಈ ಯೋಜನೆಯನ್ನು ಹಲವಾರು ವರ್ಷಗಳಿಂದ ಯಾವುದೇ ತೊಂದರೆಗಳಿಲ್ಲದೆ ಯಶಸ್ವಿಯಾಗಿ ಬಳಸುತ್ತಿದ್ದೇವೆ.

ತದನಂತರ ಅದು ಪ್ರಾರಂಭವಾಯಿತು... ನೋಡ್‌ಗಳಲ್ಲಿ ಒಂದನ್ನು ಇನ್ನು ಮುಂದೆ ಬ್ಯಾಕಪ್ ಮಾಡಲಾಗಿಲ್ಲ ಮತ್ತು ಹಿಂದಿನದು 50% ನಷ್ಟು ದೈತ್ಯಾಕಾರದ IOWAIT ನೊಂದಿಗೆ ಚಾಲನೆಯಲ್ಲಿದೆ ಎಂದು ನಾವು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ. ನಕಲು ಏಕೆ ಸಂಭವಿಸುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುವಾಗ, ನಾವು ಈ ಕೆಳಗಿನ ವಿದ್ಯಮಾನವನ್ನು ಎದುರಿಸಿದ್ದೇವೆ:

Volume group "images" not found

"Intel P4500 ಗೆ ಅಂತ್ಯ ಬಂದಿದೆ" ಎಂದು ನಾವು ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಆದಾಗ್ಯೂ, ಡ್ರೈವ್ ಅನ್ನು ಬದಲಿಸಲು ಸರ್ವರ್ ಅನ್ನು ಆಫ್ ಮಾಡುವ ಮೊದಲು, ಬ್ಯಾಕ್ಅಪ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದು ಇನ್ನೂ ಅಗತ್ಯವಾಗಿತ್ತು. LVM2 ಬ್ಯಾಕಪ್‌ನಿಂದ ಮೆಟಾಡೇಟಾವನ್ನು ಮರುಸ್ಥಾಪಿಸುವ ಮೂಲಕ ನಾವು LVM2 ಅನ್ನು ಸರಿಪಡಿಸಿದ್ದೇವೆ:

vgcfgrestore images

ನಾವು ಬ್ಯಾಕಪ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಮತ್ತು ಈ ತೈಲ ವರ್ಣಚಿತ್ರವನ್ನು ನೋಡಿದ್ದೇವೆ:

ಮತ್ತೆ ನಾವು ತುಂಬಾ ದುಃಖಿತರಾಗಿದ್ದೇವೆ - ನಾವು ಈ ರೀತಿ ಬದುಕಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಯಿತು, ಏಕೆಂದರೆ ಎಲ್ಲಾ ವಿಪಿಎಸ್‌ಗಳು ಬಳಲುತ್ತಿದ್ದಾರೆ, ಅಂದರೆ ನಾವು ಸಹ ಬಳಲುತ್ತೇವೆ. ಏನಾಯಿತು ಎಂಬುದು ಸಂಪೂರ್ಣವಾಗಿ ಅಸ್ಪಷ್ಟವಾಗಿದೆ - iostat ಕರುಣಾಜನಕ IOPS ಮತ್ತು ಅತ್ಯಧಿಕ IOWAIT ತೋರಿಸಿದೆ. "NVMe ಅನ್ನು ಬದಲಾಯಿಸೋಣ" ಹೊರತುಪಡಿಸಿ ಯಾವುದೇ ಆಲೋಚನೆಗಳಿಲ್ಲ, ಆದರೆ ಒಳನೋಟವು ಸಮಯಕ್ಕೆ ಸಂಭವಿಸಿದೆ.

ಹಂತ ಹಂತವಾಗಿ ಪರಿಸ್ಥಿತಿಯ ವಿಶ್ಲೇಷಣೆ

ಐತಿಹಾಸಿಕ ಪತ್ರಿಕೆ. ಕೆಲವು ದಿನಗಳ ಹಿಂದೆ, ಈ ಸರ್ವರ್‌ನಲ್ಲಿ 128 GB RAM ನೊಂದಿಗೆ ದೊಡ್ಡ VPS ಅನ್ನು ರಚಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು. ಸಾಕಷ್ಟು ಮೆಮೊರಿ ಇದೆ ಎಂದು ತೋರುತ್ತಿದೆ, ಆದರೆ ಸುರಕ್ಷಿತ ಬದಿಯಲ್ಲಿರಲು, ನಾವು ಸ್ವಾಪ್ ವಿಭಾಗಕ್ಕಾಗಿ ಮತ್ತೊಂದು 32 GB ಅನ್ನು ನಿಯೋಜಿಸಿದ್ದೇವೆ. VPS ಅನ್ನು ರಚಿಸಲಾಯಿತು, ಅದರ ಕಾರ್ಯವನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಳಿಸಲಾಯಿತು ಮತ್ತು ಘಟನೆಯನ್ನು ಮರೆತುಬಿಡಲಾಯಿತು, ಆದರೆ SWAP ವಿಭಜನೆಯು ಉಳಿಯಿತು.

ಕಾನ್ಫಿಗರೇಶನ್ ವೈಶಿಷ್ಟ್ಯಗಳು. ಎಲ್ಲಾ ಕ್ಲೌಡ್ ಸರ್ವರ್‌ಗಳಿಗೆ ಪ್ಯಾರಾಮೀಟರ್ vm.swappiness ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಹೊಂದಿಸಲಾಗಿದೆ 60. ಮತ್ತು SWAP ಅನ್ನು SAS HDD RAID1 ನಲ್ಲಿ ರಚಿಸಲಾಗಿದೆ.

ಏನಾಯಿತು (ಸಂಪಾದಕರ ಪ್ರಕಾರ). ಬ್ಯಾಕ್ಅಪ್ ಮಾಡುವಾಗ DD NFS ಗೆ ಬರೆಯುವ ಮೊದಲು RAM ಬಫರ್‌ಗಳಲ್ಲಿ ಇರಿಸಲಾದ ಬಹಳಷ್ಟು ಬರೆಯುವ ಡೇಟಾವನ್ನು ಉತ್ಪಾದಿಸಿತು. ಸಿಸ್ಟಮ್ ಕೋರ್, ನೀತಿಯಿಂದ ಮಾರ್ಗದರ್ಶನ swappiness, ನಿಧಾನಗತಿಯ HDD RAID1 ವಾಲ್ಯೂಮ್‌ನಲ್ಲಿರುವ ಸ್ವಾಪ್ ಪ್ರದೇಶಕ್ಕೆ VPS ಮೆಮೊರಿಯ ಹಲವು ಪುಟಗಳನ್ನು ಸರಿಸುತ್ತಿದೆ. ಇದು IOWAIT ಬಲವಾಗಿ ಬೆಳೆಯಲು ಕಾರಣವಾಯಿತು, ಆದರೆ IO NVMe ನಿಂದಾಗಿ ಅಲ್ಲ, ಆದರೆ IO HDD RAID1 ಕಾರಣ.

ಸಮಸ್ಯೆಯನ್ನು ಹೇಗೆ ಪರಿಹರಿಸಲಾಯಿತು. 32GB ಸ್ವಾಪ್ ವಿಭಾಗವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ. ಇದು 16 ಗಂಟೆಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು; SWAP ಹೇಗೆ ಮತ್ತು ಏಕೆ ನಿಧಾನವಾಗಿ ಆಫ್ ಆಗುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ನೀವು ಪ್ರತ್ಯೇಕವಾಗಿ ಓದಬಹುದು. ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಲಾಗಿದೆ swappiness ಸಮಾನವಾದ ಮೌಲ್ಯಕ್ಕೆ 5 ಮೋಡದಾದ್ಯಂತ.

ಇದು ಹೇಗೆ ಸಂಭವಿಸುವುದಿಲ್ಲ?. ಮೊದಲನೆಯದಾಗಿ, SWAP ಒಂದು SSD RAID ಅಥವಾ NVMe ಸಾಧನದಲ್ಲಿದ್ದರೆ ಮತ್ತು ಎರಡನೆಯದಾಗಿ, NVMe ಸಾಧನವಿಲ್ಲದಿದ್ದರೆ, ಆದರೆ ಅಂತಹ ಡೇಟಾವನ್ನು ಉತ್ಪಾದಿಸದ ನಿಧಾನವಾದ ಸಾಧನ - ವ್ಯಂಗ್ಯವಾಗಿ, ಸಮಸ್ಯೆ ಸಂಭವಿಸಿದೆ ಏಕೆಂದರೆ ಅದು NVMe ತುಂಬಾ ವೇಗವಾಗಿರುತ್ತದೆ.

ಅದರ ನಂತರ, ಎಲ್ಲವೂ ಮೊದಲಿನಂತೆಯೇ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿತು - ಶೂನ್ಯ IOWAIT ಯೊಂದಿಗೆ.

ಮೂಲ: www.habr.com