GlusterFS ਲਈ ਲੀਨਕਸ ਕਰਨਲ ਸੈੱਟਅੱਪ ਕਰਨਾ

ਲੇਖ ਦਾ ਅਨੁਵਾਦ ਕੋਰਸ ਦੀ ਸ਼ੁਰੂਆਤ ਦੀ ਪੂਰਵ ਸੰਧਿਆ 'ਤੇ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ ਐਡਮਿਨਿਸਟ੍ਰੇਟਰ ਲੀਨਕਸ। ਪੇਸ਼ੇਵਰ».

ਸਮੇਂ-ਸਮੇਂ 'ਤੇ, ਇੱਥੇ ਅਤੇ ਉੱਥੇ, ਕਰਨਲ ਟਿਊਨਿੰਗ ਦੇ ਸੰਬੰਧ ਵਿੱਚ ਗਲੂਸਟਰ ਦੀਆਂ ਸਿਫ਼ਾਰਸ਼ਾਂ ਬਾਰੇ ਸਵਾਲ ਉੱਠਦੇ ਹਨ ਅਤੇ ਕੀ ਇਸਦੀ ਲੋੜ ਹੈ।

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

ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਇਹ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਭਾਰੀ ਬੋਝ ਹੇਠ ਇਹ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।

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

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

ਜਦੋਂ ਮੈਮੋਰੀ ਟਿਊਨਿੰਗ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਦੇਖਣ ਵਾਲੀ ਚੀਜ਼ ਵਰਚੁਅਲ ਮੈਮੋਰੀ ਸਬਸਿਸਟਮ (VM, ਵਰਚੁਅਲ ਮੈਮੋਰੀ) ਹੈ, ਜਿਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਵਿਕਲਪ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਉਲਝਣ ਵਿੱਚ ਪਾ ਸਕਦੇ ਹਨ।

vm.swappiness

ਪੈਰਾਮੀਟਰ vm.swappiness ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਕਰਨਲ ਰੈਮ ਦੇ ਮੁਕਾਬਲੇ ਸਵੈਪ (ਸਵੈਪ, ਪੇਜਿੰਗ) ਦੀ ਕਿੰਨੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇਸਨੂੰ ਸਰੋਤ ਕੋਡ ਵਿੱਚ "ਮੈਪਡ ਮੈਮੋਰੀ ਚੋਰੀ ਕਰਨ ਦੀ ਪ੍ਰਵਿਰਤੀ" ਵਜੋਂ ਵੀ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਉੱਚ ਅਦਲਾ-ਬਦਲੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਰਨਲ ਮੈਪ ਕੀਤੇ ਪੰਨਿਆਂ ਨੂੰ ਸਵੈਪ ਕਰਨ ਲਈ ਵਧੇਰੇ ਝੁਕਾਅ ਵਾਲਾ ਹੋਵੇਗਾ। ਇੱਕ ਘੱਟ ਸਵੈਪਿਨੈੱਸ ਮੁੱਲ ਦਾ ਮਤਲਬ ਹੈ ਉਲਟ: ਕਰਨਲ ਮੈਮੋਰੀ ਤੋਂ ਘੱਟ ਪੇਜ ਕਰੇਗਾ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿਚ, ਮੁੱਲ ਜਿੰਨਾ ਉੱਚਾ ਹੋਵੇਗਾ vm.swappiness, ਜਿੰਨਾ ਜ਼ਿਆਦਾ ਸਿਸਟਮ ਸਵੈਪ ਦੀ ਵਰਤੋਂ ਕਰੇਗਾ।

ਅਦਲਾ-ਬਦਲੀ ਦੀ ਇੱਕ ਵੱਡੀ ਵਰਤੋਂ ਅਣਚਾਹੇ ਹੈ, ਕਿਉਂਕਿ ਡੇਟਾ ਦੇ ਵੱਡੇ ਬਲਾਕਾਂ ਨੂੰ RAM ਵਿੱਚ ਲੋਡ ਅਤੇ ਅਨਲੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਇਹ ਦਲੀਲ ਦਿੰਦੇ ਹਨ ਕਿ ਸਵੈਪਿਨੈਸ ਮੁੱਲ ਵੱਡਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਮੇਰੇ ਅਨੁਭਵ ਵਿੱਚ, ਇਸਨੂੰ "0" ਤੇ ਸੈੱਟ ਕਰਨ ਨਾਲ ਬਿਹਤਰ ਪ੍ਰਦਰਸ਼ਨ ਹੁੰਦਾ ਹੈ।

ਤੁਸੀਂ ਇੱਥੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ - lwn.net/Articles/100978

ਪਰ, ਦੁਬਾਰਾ, ਇਹਨਾਂ ਸੈਟਿੰਗਾਂ ਨੂੰ ਧਿਆਨ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਖਾਸ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰਨ ਤੋਂ ਬਾਅਦ ਹੀ. ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੋਡ ਕੀਤੀਆਂ ਸਟ੍ਰੀਮਿੰਗ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ, ਇਹ ਪੈਰਾਮੀਟਰ "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/Documentation/block/*osched.txt. ਅਤੇ ਮੈਂ ਮਿਕਸਡ ਓਪਰੇਸ਼ਨਾਂ (ਕਈ ਰਾਈਟ ਓਪਰੇਸ਼ਨਾਂ) ਦੇ ਦੌਰਾਨ ਰੀਡ ਥ੍ਰੋਪੁੱਟ ਵਿੱਚ ਵਾਧਾ ਦੇਖਿਆ ਹੈ।

"256" > /sys/block/sdc/queue/nr_requests

ਸ਼ਡਿਊਲਰ ਨੂੰ ਪਾਸ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਬਫਰ ਵਿੱਚ I/O ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ। ਕੁਝ ਕੰਟਰੋਲਰਾਂ ਦਾ ਅੰਦਰੂਨੀ ਕਤਾਰ ਦਾ ਆਕਾਰ (ਕਤਾਰ_ਡੂੰਘਾਈ) I/O ਸ਼ਡਿਊਲਰ ਦੀਆਂ nr_requests ਨਾਲੋਂ ਵੱਡਾ ਹੁੰਦਾ ਹੈ, ਇਸਲਈ I/O ਸ਼ਡਿਊਲਰ ਕੋਲ ਬੇਨਤੀਆਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਤਰਜੀਹ ਦੇਣ ਅਤੇ ਮਿਲਾਉਣ ਦੀ ਘੱਟ ਸੰਭਾਵਨਾ ਹੁੰਦੀ ਹੈ। ਡੈੱਡਲਾਈਨ ਅਤੇ CFQ ਸ਼ਡਿਊਲਰਾਂ ਲਈ, ਇਹ ਬਿਹਤਰ ਹੁੰਦਾ ਹੈ ਜਦੋਂ nr_requests ਕੰਟਰੋਲਰ ਦੀ ਅੰਦਰੂਨੀ ਕਤਾਰ ਨਾਲੋਂ 2 ਗੁਣਾ ਹੋਵੇ। ਬੇਨਤੀਆਂ ਨੂੰ ਮਿਲਾਉਣਾ ਅਤੇ ਮੁੜ ਕ੍ਰਮਬੱਧ ਕਰਨਾ ਸ਼ਡਿਊਲਰ ਨੂੰ ਭਾਰੀ ਬੋਝ ਹੇਠ ਵਧੇਰੇ ਜਵਾਬਦੇਹ ਬਣਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

echo "16" > /proc/sys/vm/page-cluster

ਪੇਜ-ਕਲੱਸਟਰ ਪੈਰਾਮੀਟਰ ਉਹਨਾਂ ਪੰਨਿਆਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ ਜੋ ਇੱਕ ਵਾਰ ਵਿੱਚ ਸਵੈਪ ਵਿੱਚ ਲਿਖੇ ਜਾਂਦੇ ਹਨ। ਉਪਰੋਕਤ ਉਦਾਹਰਨ ਵਿੱਚ, ਮੁੱਲ 16 KB ਦੇ RAID ਪੱਟੀ ਦੇ ਆਕਾਰ ਦੇ ਅਨੁਸਾਰ "64" 'ਤੇ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ। swappiness = 0 ਨਾਲ ਇਸਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ, ਪਰ ਜੇਕਰ ਤੁਸੀਂ 10 ਜਾਂ 20 'ਤੇ ਸਵੈਪਿਨੈੱਸ ਸੈੱਟ ਕਰਦੇ ਹੋ ਤਾਂ ਇਸ ਮੁੱਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਨਾਲ ਤੁਹਾਡੀ ਮਦਦ ਹੋਵੇਗੀ ਜਦੋਂ RAID ਸਟ੍ਰਾਈਪ ਦਾ ਆਕਾਰ 64K ਹੈ।

blockdev --setra 4096 /dev/<devname> (-sdb, hdc ਜਾਂ dev_mapper)

ਬਹੁਤ ਸਾਰੇ RAID ਕੰਟਰੋਲਰਾਂ ਲਈ ਡਿਫਾਲਟ ਬਲਾਕ ਜੰਤਰ ਸੈਟਿੰਗਾਂ ਦਾ ਨਤੀਜਾ ਅਕਸਰ ਭਿਆਨਕ ਪ੍ਰਦਰਸ਼ਨ ਹੁੰਦਾ ਹੈ। ਉਪਰੋਕਤ ਵਿਕਲਪ ਨੂੰ ਜੋੜਨਾ 4096 * 512-ਬਾਈਟ ਸੈਕਟਰਾਂ ਲਈ ਰੀਡ-ਅੱਗੇ ਸੈੱਟ ਕਰਦਾ ਹੈ। ਘੱਟ ਤੋਂ ਘੱਟ, ਸਟ੍ਰੀਮਿੰਗ ਓਪਰੇਸ਼ਨਾਂ ਲਈ, ਕਰਨਲ ਦੁਆਰਾ I/O ਨੂੰ ਤਿਆਰ ਕਰਨ ਲਈ ਵਰਤੇ ਗਏ ਸਮੇਂ ਦੌਰਾਨ ਆਨ-ਚਿੱਪ ਡਿਸਕ ਕੈਸ਼ ਨੂੰ ਰੀਡ-ਅੱਗੇ ਨਾਲ ਭਰ ਕੇ ਗਤੀ ਵਧਾਈ ਜਾਂਦੀ ਹੈ। ਕੈਸ਼ ਵਿੱਚ ਉਹ ਡੇਟਾ ਹੋ ਸਕਦਾ ਹੈ ਜਿਸਦੀ ਅਗਲੀ ਰੀਡ 'ਤੇ ਬੇਨਤੀ ਕੀਤੀ ਜਾਵੇਗੀ। ਬਹੁਤ ਜ਼ਿਆਦਾ ਪ੍ਰੀਫੈਚ ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਲਈ ਬੇਤਰਤੀਬੇ I/O ਨੂੰ ਖਤਮ ਕਰ ਸਕਦਾ ਹੈ ਜੇਕਰ ਇਹ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਉਪਯੋਗੀ ਡਿਸਕ ਸਮੇਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜਾਂ ਕੈਸ਼ ਤੋਂ ਬਾਹਰ ਡਾਟਾ ਲੋਡ ਕਰਦਾ ਹੈ।

ਹੇਠਾਂ ਫਾਈਲ ਸਿਸਟਮ ਪੱਧਰ 'ਤੇ ਕੁਝ ਹੋਰ ਸਿਫ਼ਾਰਸ਼ਾਂ ਹਨ। ਪਰ ਉਨ੍ਹਾਂ ਦਾ ਅਜੇ ਤੱਕ ਟੈਸਟ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡਾ ਫਾਈਲ ਸਿਸਟਮ ਸਟਰਿੱਪ ਦਾ ਆਕਾਰ ਅਤੇ ਐਰੇ ਵਿੱਚ ਡਿਸਕਾਂ ਦੀ ਗਿਣਤੀ ਜਾਣਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਕਿ ਇਹ ਛੇ ਡਿਸਕਾਂ ਦੀ ਇੱਕ 5K ਸਟ੍ਰਾਈਪ raid64 ਐਰੇ ਹੈ (ਅਸਲ ਵਿੱਚ ਪੰਜ, ਕਿਉਂਕਿ ਇੱਕ ਡਿਸਕ ਸਮਾਨਤਾ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ)। ਇਹ ਸਿਫ਼ਾਰਸ਼ਾਂ ਸਿਧਾਂਤਕ ਧਾਰਨਾਵਾਂ 'ਤੇ ਆਧਾਰਿਤ ਹਨ ਅਤੇ 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))

ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਲਈ, ਉੱਪਰ ਸੂਚੀਬੱਧ ਸਟ੍ਰਾਈਪ ਆਕਾਰ ਵਧਾਉਣ 'ਤੇ ਵਿਚਾਰ ਕਰੋ।

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

Ые :ы:

• dom.as/2008/02/05/linux-io-schedulers
• www.nextre.it/oracledocs/oraclemyths.html
• lkml.org/lkml/2006/11/15/40
• misterd77.blogspot.com/2007/11/3ware-hardware-raid-vs-linux-software.html

ਹੋਰ ਪੜ੍ਹੋ

• Red Hat Enterprise Linux 8 ਉੱਤੇ nftables ਦੀ ਵਰਤੋਂ ਕਰਨਾ

ਸਰੋਤ: www.habr.com