ಕೋರ್ಸ್ ಪ್ರಾರಂಭದ ಮುನ್ನಾದಿನದಂದು ಲೇಖನದ ಅನುವಾದವನ್ನು ಸಿದ್ಧಪಡಿಸಲಾಗಿದೆ .
ನಿಯತಕಾಲಿಕವಾಗಿ, ಇಲ್ಲಿ ಮತ್ತು ಅಲ್ಲಿ, ಕರ್ನಲ್ ಟ್ಯೂನಿಂಗ್‌ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಗ್ಲಸ್ಟರ್‌ನ ಶಿಫಾರಸುಗಳ ಬಗ್ಗೆ ಮತ್ತು ಇದರ ಅಗತ್ಯವಿದೆಯೇ ಎಂಬ ಪ್ರಶ್ನೆಗಳು ಉದ್ಭವಿಸುತ್ತವೆ.
ಅಂತಹ ಅಗತ್ಯವು ವಿರಳವಾಗಿ ಉದ್ಭವಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ ಕೆಲಸದ ಹೊರೆಗಳಲ್ಲಿ, ಕರ್ನಲ್ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಒಂದು ತೊಂದರೆ ಇದ್ದರೂ. ಐತಿಹಾಸಿಕವಾಗಿ, Linux ಕರ್ನಲ್ ಅವಕಾಶವನ್ನು ನೀಡಿದರೆ, ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುವ ಮುಖ್ಯ ಮಾರ್ಗವಾಗಿ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದನ್ನು ಒಳಗೊಂಡಂತೆ ಸಾಕಷ್ಟು ಮೆಮೊರಿಯನ್ನು ಸೇವಿಸಲು ಸಿದ್ಧವಾಗಿದೆ.
ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಇದು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಭಾರವಾದ ಹೊರೆಯಲ್ಲಿ ಇದು ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.
CAD, EDA ಮತ್ತು ಮುಂತಾದ ಮೆಮೊರಿ ಇಂಟೆನ್ಸಿವ್ ಸಿಸ್ಟಮ್‌ಗಳೊಂದಿಗೆ ನಮಗೆ ಸಾಕಷ್ಟು ಅನುಭವವಿದೆ, ಅದು ಭಾರೀ ಹೊರೆಯಲ್ಲಿ ನಿಧಾನವಾಗಲು ಪ್ರಾರಂಭಿಸಿತು. ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ನಾವು ಗ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿಗೆ ಸಿಲುಕಿದ್ದೇವೆ. ಹಲವು ದಿನಗಳವರೆಗೆ ಮೆಮೊರಿ ಬಳಕೆ ಮತ್ತು ಡಿಸ್ಕ್ ಲೇಟೆನ್ಸಿಯನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಗಮನಿಸಿದ ನಂತರ, ನಾವು ಅವುಗಳ ಓವರ್‌ಲೋಡ್, ಬೃಹತ್ ಐಯೋವೈಟ್, ಕರ್ನಲ್ ದೋಷಗಳು (ಕರ್ನಲ್ ಓಪ್ಸ್), ಫ್ರೀಜ್‌ಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ.
ಈ ಲೇಖನವು ವಿವಿಧ ಸಂದರ್ಭಗಳಲ್ಲಿ ನಡೆಸಿದ ಅನೇಕ ಶ್ರುತಿ ಪ್ರಯೋಗಗಳ ಫಲಿತಾಂಶವಾಗಿದೆ. ಈ ನಿಯತಾಂಕಗಳಿಗೆ ಧನ್ಯವಾದಗಳು, ಒಟ್ಟಾರೆ ಪ್ರತಿಕ್ರಿಯೆಯು ಸುಧಾರಿಸಿದೆ, ಆದರೆ ಕ್ಲಸ್ಟರ್ ಗಮನಾರ್ಹವಾಗಿ ಸ್ಥಿರವಾಗಿದೆ.
ಮೆಮೊರಿ ಟ್ಯೂನಿಂಗ್ ವಿಷಯಕ್ಕೆ ಬಂದಾಗ, ಮೊದಲನೆಯದು ವರ್ಚುವಲ್ ಮೆಮೊರಿ ಸಬ್‌ಸಿಸ್ಟಮ್ (VM, ವರ್ಚುವಲ್ ಮೆಮೊರಿ), ಇದು ನಿಮ್ಮನ್ನು ಗೊಂದಲಕ್ಕೀಡುಮಾಡುವ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಆಯ್ಕೆಗಳನ್ನು ಹೊಂದಿದೆ.
vm.swappiness
ನಿಯತಾಂಕ vm.swappiness RAM ಗೆ ಹೋಲಿಸಿದರೆ ಕರ್ನಲ್ ಸ್ವಾಪ್ (ಸ್ವಾಪ್, ಪೇಜಿಂಗ್) ಅನ್ನು ಎಷ್ಟು ಬಳಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಇದನ್ನು ಮೂಲ ಕೋಡ್‌ನಲ್ಲಿ "ಮ್ಯಾಪ್ ಮಾಡಲಾದ ಮೆಮೊರಿಯನ್ನು ಕದಿಯುವ ಪ್ರವೃತ್ತಿ" ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ. ಹೆಚ್ಚಿನ ಸ್ವಾಪ್ಪಿನೆಸ್ ಎಂದರೆ ಕರ್ನಲ್ ಮ್ಯಾಪ್ ಮಾಡಿದ ಪುಟಗಳನ್ನು ಸ್ವಾಪ್ ಮಾಡಲು ಹೆಚ್ಚು ಒಲವು ತೋರುತ್ತದೆ. ಕಡಿಮೆ ಸ್ವಾಪ್ಪಿನೆಸ್ ಮೌಲ್ಯವು ವಿರುದ್ಧವಾಗಿರುತ್ತದೆ: ಕರ್ನಲ್ ಮೆಮೊರಿಯಿಂದ ಪುಟವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಹೆಚ್ಚಿನ ಮೌಲ್ಯ vm.swappiness, ಹೆಚ್ಚು ಸಿಸ್ಟಮ್ ಸ್ವಾಪ್ ಅನ್ನು ಬಳಸುತ್ತದೆ.
ದೊಡ್ಡ ಪ್ರಮಾಣದ ದತ್ತಾಂಶಗಳನ್ನು RAM ಗೆ ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಇಳಿಸುವುದರಿಂದ ವಿನಿಮಯದ ದೊಡ್ಡ ಬಳಕೆಯು ಅನಪೇಕ್ಷಿತವಾಗಿದೆ. ಸ್ವಾಪಿನೆಸ್ ಮೌಲ್ಯವು ದೊಡ್ಡದಾಗಿರಬೇಕು ಎಂದು ಅನೇಕ ಜನರು ವಾದಿಸುತ್ತಾರೆ, ಆದರೆ ನನ್ನ ಅನುಭವದಲ್ಲಿ, ಅದನ್ನು "0" ಗೆ ಹೊಂದಿಸುವುದು ಉತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ನೀವು ಇಲ್ಲಿ ಇನ್ನಷ್ಟು ಓದಬಹುದು -
ಆದರೆ, ಮತ್ತೊಮ್ಮೆ, ಈ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಅನ್ವಯಿಸಬೇಕು ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿದ ನಂತರ ಮಾತ್ರ. ಹೆಚ್ಚು ಲೋಡ್ ಮಾಡಲಾದ ಸ್ಟ್ರೀಮಿಂಗ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ, ಈ ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು "0" ಗೆ ಹೊಂದಿಸಬೇಕು. "0" ಗೆ ಬದಲಾಯಿಸಿದಾಗ, ಸಿಸ್ಟಮ್ ರೆಸ್ಪಾನ್ಸಿವ್ನೆಸ್ ಸುಧಾರಿಸುತ್ತದೆ.
vm.vfs_cache_pressure
ಈ ಸೆಟ್ಟಿಂಗ್ ಕ್ಯಾಶಿಂಗ್ ಡೈರೆಕ್ಟರಿ ಮತ್ತು ಐನೋಡ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಗೆ (ಡೆಂಟ್ರಿ ಮತ್ತು ಐನೋಡ್) ಕರ್ನಲ್ ಸೇವಿಸುವ ಮೆಮೊರಿಯನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ.
100 ರ ಪೂರ್ವನಿಯೋಜಿತ ಮೌಲ್ಯದೊಂದಿಗೆ, ಕರ್ನಲ್ ಡೆಂಟ್ರಿ ಮತ್ತು ಐನೋಡ್ ಸಂಗ್ರಹಗಳನ್ನು "ನ್ಯಾಯಯುತ" ಆಧಾರದ ಮೇಲೆ ಪೇಜ್‌ಕ್ಯಾಶ್ ಮತ್ತು ಸ್ವಾಪ್‌ಕ್ಯಾಶ್‌ಗೆ ಮುಕ್ತಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. vfs_cache_pressure ಅನ್ನು ಕಡಿಮೆ ಮಾಡುವುದರಿಂದ ಕರ್ನಲ್ ಡೆಂಟ್ರಿ ಮತ್ತು ಐನೋಡ್ ಕ್ಯಾಶ್‌ಗಳನ್ನು ಇರಿಸಿಕೊಳ್ಳಲು ಕಾರಣವಾಗುತ್ತದೆ. ಮೌಲ್ಯವು "0" ಆಗಿರುವಾಗ, ಮೆಮೊರಿ ಒತ್ತಡದಿಂದಾಗಿ ಕರ್ನಲ್ ಡೆಂಟ್ರಿ ಮತ್ತು ಐನೋಡ್ ಸಂಗ್ರಹವನ್ನು ಎಂದಿಗೂ ಫ್ಲಶ್ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಇದು ಸುಲಭವಾಗಿ ಔಟ್-ಆಫ್-ಮೆಮೊರಿ ದೋಷಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು. vfs_cache_pressure ಅನ್ನು 100 ಕ್ಕಿಂತ ಹೆಚ್ಚಿಸುವುದರಿಂದ ಕರ್ನಲ್ ಡೆಂಟ್ರಿ ಮತ್ತು ಐನೋಡ್ ಫ್ಲಶಿಂಗ್‌ಗೆ ಆದ್ಯತೆ ನೀಡುತ್ತದೆ.
GlusterFS ಅನ್ನು ಬಳಸುವಾಗ, ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಡೇಟಾ ಮತ್ತು ಅನೇಕ ಸಣ್ಣ ಫೈಲ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಅನೇಕ ಬಳಕೆದಾರರು ಐನೋಡ್/ಡೆಂಟ್ರಿ ಕ್ಯಾಶಿಂಗ್‌ನಿಂದಾಗಿ ಸರ್ವರ್‌ನಲ್ಲಿ ಗಮನಾರ್ಹ ಪ್ರಮಾಣದ RAM ಅನ್ನು ಸುಲಭವಾಗಿ ಬಳಸಬಹುದು, ಇದು ಕರ್ನಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಡೇಟಾ ರಚನೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದರಿಂದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅವನತಿಗೆ ಕಾರಣವಾಗಬಹುದು. 40 GB ಮೆಮೊರಿಯೊಂದಿಗೆ. ಈ ಮೌಲ್ಯವನ್ನು 100 ಕ್ಕಿಂತ ಹೆಚ್ಚು ಹೊಂದಿಸುವುದು ಅನೇಕ ಬಳಕೆದಾರರಿಗೆ ಉತ್ತಮವಾದ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವಿಕೆ ಮತ್ತು ಸುಧಾರಿತ ಕರ್ನಲ್ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸಾಧಿಸಲು ಸಹಾಯ ಮಾಡಿದೆ.
vm.dirty_background_ratio ಮತ್ತು vm.dirty_ratio
ಮೊದಲ ಪ್ಯಾರಾಮೀಟರ್ (vm.dirty_background_ratio) ಕೊಳಕು ಪುಟಗಳೊಂದಿಗೆ ಮೆಮೊರಿಯ ಶೇಕಡಾವಾರು ಪ್ರಮಾಣವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಅದನ್ನು ತಲುಪಿದ ನಂತರ ಡಿಸ್ಕ್ಗೆ ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಕೊಳಕು ಪುಟಗಳನ್ನು ಫ್ಲಶಿಂಗ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುವುದು ಅವಶ್ಯಕ. ಈ ಶೇಕಡಾವಾರು ತಲುಪುವವರೆಗೆ, ಯಾವುದೇ ಪುಟಗಳನ್ನು ಡಿಸ್ಕ್ಗೆ ಫ್ಲಶ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ. ಮತ್ತು ಮರುಹೊಂದಿಕೆಯು ಪ್ರಾರಂಭವಾದಾಗ, ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ಅಡ್ಡಿಯಾಗದಂತೆ ಅದು ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಚಲಿಸುತ್ತದೆ.
ಎರಡನೇ ನಿಯತಾಂಕ (vm.dirty_ratio) ಬಲವಂತದ ಫ್ಲಾಶ್ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಕೊಳಕು ಪುಟಗಳಿಂದ ಆಕ್ರಮಿಸಬಹುದಾದ ಮೆಮೊರಿಯ ಶೇಕಡಾವಾರು ಪ್ರಮಾಣವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಈ ಮಿತಿಯನ್ನು ತಲುಪಿದ ನಂತರ, ಎಲ್ಲಾ ಪ್ರಕ್ರಿಯೆಗಳು ಸಿಂಕ್ರೊನಸ್ ಆಗುತ್ತವೆ (ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ) ಮತ್ತು ಅವರು ವಿನಂತಿಸಿದ I/O ನಿಜವಾಗಿ ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಮತ್ತು ಡೇಟಾ ಡಿಸ್ಕ್‌ನಲ್ಲಿರುವವರೆಗೆ ಮುಂದುವರೆಯಲು ಅನುಮತಿಸಲಾಗುವುದಿಲ್ಲ. ಭಾರೀ I/O ನೊಂದಿಗೆ, ಇದು ಸಮಸ್ಯೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ ಏಕೆಂದರೆ ಯಾವುದೇ ಡೇಟಾ ಕ್ಯಾಶಿಂಗ್ ಇಲ್ಲ ಮತ್ತು I/O ಮಾಡುವ ಎಲ್ಲಾ ಪ್ರಕ್ರಿಯೆಗಳು I/O ಗಾಗಿ ಕಾಯುವುದನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ. ಇದು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಹಂಗ್ ಪ್ರಕ್ರಿಯೆಗಳು, ಹೆಚ್ಚಿನ ಹೊರೆ, ಸಿಸ್ಟಮ್ ಅಸ್ಥಿರತೆ ಮತ್ತು ಕಳಪೆ ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಈ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುವುದರಿಂದ ಡೇಟಾವನ್ನು ಹೆಚ್ಚಾಗಿ ಡಿಸ್ಕ್ಗೆ ಫ್ಲಶ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು RAM ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುವುದಿಲ್ಲ. ಇದು 45-90 GB ಪುಟದ ಕ್ಯಾಶ್‌ಗಳನ್ನು ಡಿಸ್ಕ್ಗೆ ಫ್ಲಶ್ ಮಾಡುವುದರೊಂದಿಗೆ ಸರಿಯಾಗಿರುವ ಮೆಮೊರಿ-ಹೆವಿ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಇದರ ಪರಿಣಾಮವಾಗಿ ಮುಂಭಾಗದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಭಾರಿ ಸುಪ್ತತೆ ಉಂಟಾಗುತ್ತದೆ, ಒಟ್ಟಾರೆ ಪ್ರತಿಕ್ರಿಯೆ ಮತ್ತು ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
"1" > /proc/sys/vm/pagecache
ಪುಟ ಸಂಗ್ರಹವು ಫೈಲ್‌ಗಳು ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಪ್ರೋಗ್ರಾಂಗಳ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ ಸಂಗ್ರಹವಾಗಿದೆ, ಅಂದರೆ, ಇವುಗಳು ಫೈಲ್‌ಗಳು ಅಥವಾ ಬ್ಲಾಕ್ ಸಾಧನಗಳ ನಿಜವಾದ ವಿಷಯಗಳೊಂದಿಗೆ ಪುಟಗಳಾಗಿವೆ. ಡಿಸ್ಕ್ ರೀಡ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಈ ಸಂಗ್ರಹವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. "1" ಮೌಲ್ಯವು ಸಂಗ್ರಹಕ್ಕಾಗಿ RAM ನ 1% ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು RAM ಗಿಂತ ಡಿಸ್ಕ್‌ನಿಂದ ಹೆಚ್ಚು ಓದುತ್ತದೆ. ಈ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಬದಲಾಯಿಸುವ ಅಗತ್ಯವಿಲ್ಲ, ಆದರೆ ಪುಟದ ಸಂಗ್ರಹವನ್ನು ನಿಯಂತ್ರಿಸುವ ಬಗ್ಗೆ ನೀವು ವ್ಯಾಮೋಹ ಹೊಂದಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಬಳಸಬಹುದು.
"ಗಡುವು" > /sys/block/sdc/queue/scheduler
I/O ಶೆಡ್ಯೂಲರ್ ಒಂದು Linux ಕರ್ನಲ್ ಘಟಕವಾಗಿದ್ದು ಅದು ಓದಲು ಮತ್ತು ಬರೆಯಲು ಕ್ಯೂಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಸ್ಮಾರ್ಟ್ RAID ನಿಯಂತ್ರಕಕ್ಕಾಗಿ "noop" ಅನ್ನು ಬಳಸುವುದು ಉತ್ತಮವಾಗಿದೆ, ಏಕೆಂದರೆ Linux ಗೆ ಡಿಸ್ಕ್‌ನ ಭೌತಿಕ ರೇಖಾಗಣಿತದ ಬಗ್ಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲ, ಆದ್ದರಿಂದ ಡಿಸ್ಕ್ ಜ್ಯಾಮಿತಿಯನ್ನು ಚೆನ್ನಾಗಿ ತಿಳಿದಿರುವ ನಿಯಂತ್ರಕವು ವಿನಂತಿಯನ್ನು ತ್ವರಿತವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಅವಕಾಶ ನೀಡುವುದು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ. ಸಾಧ್ಯ. ಆದರೆ "ಗಡುವು" ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ ಎಂದು ತೋರುತ್ತಿದೆ. ನೀವು Linux ಕರ್ನಲ್ ಮೂಲ ಕೋಡ್ ದಾಖಲಾತಿಯಲ್ಲಿ ಶೆಡ್ಯೂಲರ್‌ಗಳ ಕುರಿತು ಇನ್ನಷ್ಟು ಓದಬಹುದು: linux/Documentation/block/*osched.txt. ಮತ್ತು ಮಿಶ್ರ ಕಾರ್ಯಾಚರಣೆಗಳ ಸಮಯದಲ್ಲಿ ನಾನು ಓದುವ ಥ್ರೋಪುಟ್‌ನಲ್ಲಿ ಹೆಚ್ಚಳವನ್ನು ಕಂಡಿದ್ದೇನೆ (ಹಲವು ಬರೆಯುವ ಕಾರ್ಯಾಚರಣೆಗಳು).
"256" > /sys/block/sdc/queue/nr_requests
ಶೆಡ್ಯೂಲರ್‌ಗೆ ರವಾನಿಸುವ ಮೊದಲು ಬಫರ್‌ನಲ್ಲಿರುವ I/O ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ. ಕೆಲವು ನಿಯಂತ್ರಕಗಳ ಆಂತರಿಕ ಸರತಿ ಗಾತ್ರವು (ಕ್ಯೂ_ಡೆಪ್ತ್) I/O ಶೆಡ್ಯೂಲರ್‌ನ nr_requests ಗಿಂತ ದೊಡ್ಡದಾಗಿದೆ, ಆದ್ದರಿಂದ I/O ಶೆಡ್ಯೂಲರ್ ವಿನಂತಿಗಳನ್ನು ಸರಿಯಾಗಿ ಆದ್ಯತೆ ನೀಡುವ ಮತ್ತು ವಿಲೀನಗೊಳಿಸುವ ಅವಕಾಶವನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. ಡೆಡ್‌ಲೈನ್ ಮತ್ತು CFQ ಶೆಡ್ಯೂಲರ್‌ಗಳಿಗೆ, nr_requests ನಿಯಂತ್ರಕದ ಆಂತರಿಕ ಸರತಿಗಿಂತ 2 ಪಟ್ಟು ಹೆಚ್ಚಿದ್ದರೆ ಅದು ಉತ್ತಮವಾಗಿರುತ್ತದೆ. ವಿನಂತಿಗಳನ್ನು ವಿಲೀನಗೊಳಿಸುವುದು ಮತ್ತು ಮರುಕ್ರಮಗೊಳಿಸುವುದು ಶೆಡ್ಯೂಲರ್‌ಗೆ ಹೆಚ್ಚಿನ ಹೊರೆಯ ಅಡಿಯಲ್ಲಿ ಹೆಚ್ಚು ಸ್ಪಂದಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಪ್ರತಿಧ್ವನಿ "16" > /proc/sys/vm/page-cluster
ಪುಟ-ಕ್ಲಸ್ಟರ್ ಪ್ಯಾರಾಮೀಟರ್ ಒಂದು ಸಮಯದಲ್ಲಿ ಸ್ವಾಪ್‌ಗೆ ಬರೆಯಲಾದ ಪುಟಗಳ ಸಂಖ್ಯೆಯನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಮೇಲಿನ ಉದಾಹರಣೆಯಲ್ಲಿ, 16 KB ನ RAID ಪಟ್ಟಿಯ ಗಾತ್ರದ ಪ್ರಕಾರ ಮೌಲ್ಯವನ್ನು "64" ಗೆ ಹೊಂದಿಸಲಾಗಿದೆ. ಸ್ವಾಪ್ಪಿನೆಸ್ = 0 ನೊಂದಿಗೆ ಅರ್ಥವಿಲ್ಲ, ಆದರೆ ನೀವು ಸ್ವಾಪ್ಪಿನೆಸ್ ಅನ್ನು 10 ಅಥವಾ 20 ಗೆ ಹೊಂದಿಸಿದರೆ, ಈ ಮೌಲ್ಯವನ್ನು ಬಳಸುವುದರಿಂದ RAID ಸ್ಟ್ರೈಪ್ ಗಾತ್ರವು 64K ಆಗಿರುವಾಗ ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.
blockdev --setra 4096 /dev/<ದೇವಹೆಸರು> (-sdb, hdc ಅಥವಾ dev_mapper)
ಅನೇಕ RAID ನಿಯಂತ್ರಕಗಳಿಗಾಗಿ ಡಿಫಾಲ್ಟ್ ಬ್ಲಾಕ್ ಸಾಧನ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಭಯಾನಕ ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಕಾರಣವಾಗುತ್ತವೆ. ಮೇಲಿನ ಆಯ್ಕೆಯನ್ನು ಸೇರಿಸುವುದರಿಂದ 4096 * 512-ಬೈಟ್ ಸೆಕ್ಟರ್‌ಗಳಿಗೆ ಓದಲು-ಮುಂದೆ ಹೊಂದಿಸುತ್ತದೆ. ಕನಿಷ್ಠ, ಸ್ಟ್ರೀಮಿಂಗ್ ಕಾರ್ಯಾಚರಣೆಗಳಿಗಾಗಿ, I/O ಅನ್ನು ತಯಾರಿಸಲು ಕರ್ನಲ್ ಬಳಸುವ ಅವಧಿಯಲ್ಲಿ ಆನ್-ಚಿಪ್ ಡಿಸ್ಕ್ ಸಂಗ್ರಹವನ್ನು ಓದಲು-ಮುಂದೆ ತುಂಬುವ ಮೂಲಕ ವೇಗವನ್ನು ಹೆಚ್ಚಿಸಲಾಗುತ್ತದೆ. ಸಂಗ್ರಹವು ಮುಂದಿನ ಓದುವಿಕೆಯಲ್ಲಿ ವಿನಂತಿಸಲಾದ ಡೇಟಾವನ್ನು ಒಳಗೊಂಡಿರಬಹುದು. ಹೆಚ್ಚು ಪೂರ್ವಪಡೆಯುವಿಕೆ ದೊಡ್ಡ ಫೈಲ್‌ಗಳಿಗಾಗಿ ಯಾದೃಚ್ಛಿಕ I/O ಅನ್ನು ನಾಶಪಡಿಸಬಹುದು, ಅದು ಸಂಭಾವ್ಯವಾಗಿ ಉಪಯುಕ್ತವಾದ ಡಿಸ್ಕ್ ಸಮಯವನ್ನು ಬಳಸಿದರೆ ಅಥವಾ ಸಂಗ್ರಹದ ಹೊರಗೆ ಡೇಟಾವನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ.
ಫೈಲ್ ಸಿಸ್ಟಮ್ ಮಟ್ಟದಲ್ಲಿ ಇನ್ನೂ ಕೆಲವು ಶಿಫಾರಸುಗಳನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ. ಆದರೆ ಅವರು ಇನ್ನೂ ಪರೀಕ್ಷೆಗೆ ಒಳಪಟ್ಟಿಲ್ಲ. ನಿಮ್ಮ ಫೈಲ್‌ಸಿಸ್ಟಮ್ ಸ್ಟ್ರೈಪ್‌ನ ಗಾತ್ರ ಮತ್ತು ಅರೇಯಲ್ಲಿರುವ ಡಿಸ್ಕ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ತಿಳಿದಿದೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಉದಾಹರಣೆಗೆ, ಇದು ಆರು ಡಿಸ್ಕ್‌ಗಳ 5K ಸ್ಟ್ರೈಪ್ ರೈಡ್64 ಶ್ರೇಣಿಯಾಗಿದೆ (ವಾಸ್ತವವಾಗಿ ಐದು, ಏಕೆಂದರೆ ಒಂದು ಡಿಸ್ಕ್ ಅನ್ನು ಸಮಾನತೆಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ). ಈ ಶಿಫಾರಸುಗಳು ಸೈದ್ಧಾಂತಿಕ ಊಹೆಗಳನ್ನು ಆಧರಿಸಿವೆ ಮತ್ತು RAID ತಜ್ಞರಿಂದ ವಿವಿಧ ಬ್ಲಾಗ್‌ಗಳು/ಲೇಖನಗಳಿಂದ ಸಂಕಲಿಸಲಾಗಿದೆ.
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))ದೊಡ್ಡ ಫೈಲ್‌ಗಳಿಗಾಗಿ, ಮೇಲೆ ಪಟ್ಟಿ ಮಾಡಲಾದ ಪಟ್ಟಿಯ ಗಾತ್ರಗಳನ್ನು ಹೆಚ್ಚಿಸುವುದನ್ನು ಪರಿಗಣಿಸಿ.
ಗಮನ! ಕೆಲವು ವಿಧದ ಅನ್ವಯಗಳಿಗೆ ಮೇಲೆ ವಿವರಿಸಿದ ಎಲ್ಲವೂ ಹೆಚ್ಚು ವ್ಯಕ್ತಿನಿಷ್ಠವಾಗಿದೆ. ಸಂಬಂಧಿತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಪೂರ್ವ ಬಳಕೆದಾರ ಪರೀಕ್ಷೆಯಿಲ್ಲದೆ ಈ ಲೇಖನವು ಯಾವುದೇ ಸುಧಾರಣೆಗಳನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ಸಿಸ್ಟಮ್ನ ಒಟ್ಟಾರೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸುಧಾರಿಸಲು ಅಥವಾ ಪ್ರಸ್ತುತ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಅಗತ್ಯವಿದ್ದರೆ ಮಾತ್ರ ಇದನ್ನು ಬಳಸಬೇಕು.
Дополнительные:
ಮತ್ತಷ್ಟು ಓದು
ಮೂಲ: www.habr.com