ਇਲਿਆ ਕੋਸਮੋਡੇਮਯਾਂਸਕੀ ਦੀ 2015 ਦੀ ਰਿਪੋਰਟ ਦੀ ਪ੍ਰਤੀਲਿਪੀLinux PostgreSQL ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਟਿਊਨਿੰਗ"
ਬੇਦਾਅਵਾ: ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਕਿ ਇਹ ਗੱਲਬਾਤ ਨਵੰਬਰ 2015 ਦੀ ਹੈ—ਚਾਰ ਸਾਲ ਤੋਂ ਵੱਧ ਸਮਾਂ ਬੀਤ ਚੁੱਕਾ ਹੈ, ਅਤੇ ਬਹੁਤ ਸਾਰਾ ਸਮਾਂ ਬੀਤ ਚੁੱਕਾ ਹੈ। ਗੱਲਬਾਤ ਵਿੱਚ ਚਰਚਾ ਕੀਤਾ ਗਿਆ ਸੰਸਕਰਣ 9.4 ਹੁਣ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ। ਪਿਛਲੇ ਚਾਰ ਸਾਲਾਂ ਵਿੱਚ, ਪੰਜ ਨਵੇਂ PostgreSQL ਰੀਲੀਜ਼ ਜਾਰੀ ਕੀਤੇ ਗਏ ਹਨ, ਨਾਲ ਹੀ 15 ਕਰਨਲ ਸੰਸਕਰਣ ਵੀ। Linuxਜੇਕਰ ਤੁਸੀਂ ਇਹਨਾਂ ਹਿੱਸਿਆਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਵੱਖਰੀ ਰਿਪੋਰਟ ਮਿਲੇਗੀ। ਪਰ ਇੱਥੇ ਅਸੀਂ ਬੁਨਿਆਦੀ ਟਿਊਨਿੰਗ ਨੂੰ ਕਵਰ ਕਰਾਂਗੇ। Linux PostgreSQL ਲਈ, ਜੋ ਕਿ ਅੱਜ ਵੀ ਢੁਕਵਾਂ ਹੈ।
ਮੇਰਾ ਨਾਮ ਇਲਿਆ ਕੋਸਮੋਡੇਮਯਾਂਸਕੀ ਹੈ। ਮੈਂ ਪੋਸਟਗ੍ਰੇਐਸਕਿਊਐਲ-ਕੰਸਲਟਿੰਗ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹਾਂ। ਅਤੇ ਹੁਣ ਮੈਂ ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਥੋੜ੍ਹਾ ਜਿਹਾ ਦੱਸਾਂਗਾ ਕਿ ਕੀ ਕਰਨਾ ਹੈ Linux ਆਮ ਤੌਰ 'ਤੇ ਡੇਟਾਬੇਸਾਂ ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ PostgreSQL ਦੇ ਸਬੰਧ ਵਿੱਚ, ਕਿਉਂਕਿ ਸਿਧਾਂਤ ਕਾਫ਼ੀ ਸਮਾਨ ਹਨ।
ਕੀ ਮਤਲਬ ਹੈ? ਜੇਕਰ ਤੁਸੀਂ PostgreSQL ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਕੁਝ ਹੱਦ ਤੱਕ UNIX ਐਡਮਿਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸਦਾ ਕੀ ਮਤਲਬ ਹੈ? ਜੇਕਰ ਅਸੀਂ Oracle ਅਤੇ PostgreSQL ਦੀ ਤੁਲਨਾ ਕਰੀਏ, ਤਾਂ Oracle ਵਿੱਚ ਤੁਹਾਨੂੰ 80% DBA/ਡਾਟਾਬੇਸ ਐਡਮਿਨ ਅਤੇ 20% ਐਡਮਿਨਿਸਟ੍ਰੇਟਰ ਹੋਣ ਦੀ ਲੋੜ ਹੈ। Linux.
PostgreSQL ਦੇ ਨਾਲ ਇਹ ਥੋੜ੍ਹਾ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੈ। PostgreSQL ਦੇ ਨਾਲ ਤੁਹਾਨੂੰ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਇਸਦੀ ਬਿਹਤਰ ਸਮਝ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। Linuxਅਤੇ ਇਸ ਦੇ ਨਾਲ ਹੀ, ਇਹ ਸਮੇਂ ਦੇ ਨਾਲ ਚੱਲਣ ਦੀ ਥੋੜ੍ਹੀ ਜਿਹੀ ਦੌੜ ਹੈ, ਕਿਉਂਕਿ ਹਾਲ ਹੀ ਵਿੱਚ ਹਰ ਚੀਜ਼ ਕਾਫ਼ੀ ਅੱਪਡੇਟ ਹੋ ਰਹੀ ਹੈ। ਨਵੇਂ ਕੋਰ ਜਾਰੀ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ, ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਜਾ ਰਹੀਆਂ ਹਨ, ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਸੁਧਾਰ ਹੋ ਰਿਹਾ ਹੈ, ਆਦਿ।
ਅਸੀਂ ਕਿਉਂ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ? Linux? ਬਿਲਕੁਲ ਨਹੀਂ ਕਿਉਂਕਿ ਅਸੀਂ ਇੱਕ ਕਾਨਫਰੰਸ ਵਿੱਚ ਹਾਂ। Linux ਪੀਟਰ, ਕਿਉਂਕਿ ਆਧੁਨਿਕ ਹਾਲਤਾਂ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਡੇਟਾਬੇਸਾਂ ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ PostgreSQL ਨਾਲ ਵਰਤਣ ਲਈ ਸਭ ਤੋਂ ਜਾਇਜ਼ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ Linuxਕਿਉਂਕਿ, ਬਦਕਿਸਮਤੀ ਨਾਲ, FreeBSD ਇੱਕ ਬਹੁਤ ਹੀ ਅਜੀਬ ਦਿਸ਼ਾ ਵਿੱਚ ਵਿਕਸਤ ਹੋ ਰਿਹਾ ਹੈ। ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਹੋਣਗੀਆਂ। PostgreSQL ਪ੍ਰਦਰਸ਼ਨ ਚਾਲੂ ਹੈ Windows - ਇਹ ਇੱਕ ਬਿਲਕੁਲ ਵੱਖਰਾ ਅਤੇ ਗੰਭੀਰ ਵਿਸ਼ਾ ਹੈ, ਜੋ ਇਸ ਤੱਥ 'ਤੇ ਅਧਾਰਤ ਹੈ ਕਿ Windows UNIX ਵਰਗੀ ਕੋਈ ਸਾਂਝੀ ਮੈਮੋਰੀ ਨਹੀਂ ਹੈ, ਪਰ PostgreSQL ਪੂਰੀ ਤਰ੍ਹਾਂ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਬਹੁ-ਪ੍ਰਕਿਰਿਆ ਪ੍ਰਣਾਲੀ ਹੈ।
ਅਤੇ ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਹਰ ਕੋਈ ਸੋਲਾਰਿਸ ਵਰਗੇ ਐਕਸੋਟਿਕਸ ਵਿੱਚ ਘੱਟ ਦਿਲਚਸਪੀ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਚਲੋ.
ਆਧੁਨਿਕ ਵੰਡ ਵਿੱਚ ਹੈ Linux ਕਰਨਲ ਨੂੰ ਕਿਵੇਂ ਕੰਪਾਇਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, 1,000 ਤੋਂ ਵੱਧ syctl ਪੈਰਾਮੀਟਰ ਹਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜੇਕਰ ਅਸੀਂ ਵੱਖ-ਵੱਖ ਨਟ ਐਂਡ ਬੋਲਟਸ ਨੂੰ ਵੇਖਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ ਚੀਜ਼ਾਂ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰਨ ਦੇ ਹੋਰ ਵੀ ਬਹੁਤ ਸਾਰੇ ਤਰੀਕੇ ਹਨ। ਫਾਈਲ ਸਿਸਟਮ ਪੈਰਾਮੀਟਰ ਹਨ, ਜਿਵੇਂ ਕਿ ਮਾਊਂਟਿੰਗ ਵਿਕਲਪ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਕਰਨਲ ਨੂੰ ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ, BIOS ਵਿੱਚ ਕੀ ਸਮਰੱਥ ਕਰਨਾ ਹੈ, ਹਾਰਡਵੇਅਰ ਨੂੰ ਕਿਵੇਂ ਸੰਰਚਿਤ ਕਰਨਾ ਹੈ, ਆਦਿ ਬਾਰੇ ਸਵਾਲ ਹਨ।
ਇਹ ਇੱਕ ਬਹੁਤ ਵੱਡਾ ਖੰਡ ਹੈ, ਜਿਸ ਬਾਰੇ ਕਈ ਦਿਨਾਂ ਲਈ ਚਰਚਾ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਰਿਪੋਰਟ ਵਿੱਚ ਨਹੀਂ, ਪਰ ਹੁਣ ਮੈਂ ਮਹੱਤਵਪੂਰਨ ਗੱਲਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਾਂਗਾ, ਉਨ੍ਹਾਂ ਰੇਕਾਂ ਤੋਂ ਕਿਵੇਂ ਬਚਿਆ ਜਾਵੇ ਜੋ ਤੁਹਾਨੂੰ ਡੇਟਾਬੇਸ ਦੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਰੋਕਣ ਦੀ ਗਰੰਟੀ ਹਨ। Linux, ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਐਡਜਸਟ ਨਹੀਂ ਕਰਦੇ। ਅਤੇ ਇਹ ਧਿਆਨ ਦੇਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਬਹੁਤ ਸਾਰੇ ਡਿਫਾਲਟ ਪੈਰਾਮੀਟਰ ਸਹੀ ਡੇਟਾਬੇਸ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਹ ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਮਾੜੇ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨਗੇ ਜਾਂ ਬਿਲਕੁਲ ਨਹੀਂ ਕਰਨਗੇ।
ਕਿਹੜੇ ਰਵਾਇਤੀ ਟਿਊਨਿੰਗ ਟੀਚੇ ਹਨ? Linux? ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਕਿਉਂਕਿ ਤੁਸੀਂ ਸਾਰੇ ਪ੍ਰਸ਼ਾਸਨ ਨਾਲ ਨਜਿੱਠਦੇ ਹੋ Linux, ਤਾਂ ਫਿਰ ਨਿਸ਼ਾਨਾ ਕੀ ਹਨ, ਇਸ ਬਾਰੇ ਅਸਲ ਵਿੱਚ ਕਿਸੇ ਵਿਆਖਿਆ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।
ਤੁਸੀਂ ਟਿਊਨ ਕਰ ਸਕਦੇ ਹੋ:
- ਸੀਪੀਯੂ.
- ਯਾਦਦਾਸ਼ਤ.
- ਸਟੋਰੇਜ.
- ਹੋਰ। ਅਸੀਂ ਇੱਕ ਸਨੈਕ ਲਈ ਅੰਤ ਵਿੱਚ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ. ਇੱਥੋਂ ਤੱਕ ਕਿ, ਉਦਾਹਰਨ ਲਈ, ਊਰਜਾ ਬੱਚਤ ਨੀਤੀ ਵਰਗੇ ਮਾਪਦੰਡ ਇੱਕ ਬਹੁਤ ਹੀ ਅਨੁਮਾਨਿਤ ਅਤੇ ਸਭ ਤੋਂ ਸੁਹਾਵਣੇ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੇ ਹਨ।
PostgreSQL ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਡਾਟਾਬੇਸ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਕੀ ਹਨ? ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀਗਤ ਗਿਰੀ ਨੂੰ ਟਵੀਕ ਨਹੀਂ ਕਰ ਸਕਦੇ ਅਤੇ ਇਹ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਸਾਡੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਕਾਫ਼ੀ ਸੁਧਾਰ ਹੋਇਆ ਹੈ।
ਹਾਂ, ਅਜਿਹੇ ਯੰਤਰ ਹਨ, ਪਰ ਇੱਕ ਡੇਟਾਬੇਸ ਇੱਕ ਗੁੰਝਲਦਾਰ ਚੀਜ਼ ਹੈ. ਇਹ ਉਹਨਾਂ ਸਾਰੇ ਸਰੋਤਾਂ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦਾ ਹੈ ਜੋ ਸਰਵਰ ਕੋਲ ਹਨ ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਨਾ ਪਸੰਦ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਓਰੇਕਲ ਦੀਆਂ ਮੌਜੂਦਾ ਸਿਫ਼ਾਰਸ਼ਾਂ ਨੂੰ ਦੇਖਦੇ ਹੋ ਕਿ ਹੋਸਟ OS ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਨੀ ਹੈ, ਤਾਂ ਇਹ ਉਸ ਮੰਗੋਲੀਆਈ ਪੁਲਾੜ ਯਾਤਰੀ ਬਾਰੇ ਮਜ਼ਾਕ ਵਾਂਗ ਹੋਵੇਗਾ - ਕੁੱਤੇ ਨੂੰ ਫੀਡ ਕਰੋ ਅਤੇ ਕੁਝ ਵੀ ਨਾ ਛੂਹੋ। ਆਉ ਡੇਟਾਬੇਸ ਨੂੰ ਸਾਰੇ ਸਰੋਤ ਦਿੰਦੇ ਹਾਂ, ਡੇਟਾਬੇਸ ਆਪਣੇ ਆਪ ਸਭ ਕੁਝ ਛਾਂਟ ਲਵੇਗਾ।
ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਕੁਝ ਹੱਦ ਤੱਕ, ਸਥਿਤੀ PostgreSQL ਨਾਲ ਬਿਲਕੁਲ ਉਹੀ ਹੈ। ਫਰਕ ਇਹ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਵਿੱਚ ਅਜੇ ਤੱਕ ਸਾਰੇ ਸਰੋਤ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਨਹੀਂ ਹੈ, ਭਾਵ ਇਸਨੂੰ ਪੱਧਰ 'ਤੇ ਕਿਤੇ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ। Linux ਮੈਨੂੰ ਇਹ ਸਭ ਆਪਣੇ ਆਪ ਹੀ ਹੱਲ ਕਰਨਾ ਪਵੇਗਾ।
ਮੁੱਖ ਵਿਚਾਰ ਇੱਕ ਸਿੰਗਲ ਟੀਚੇ ਨੂੰ ਚੁਣਨਾ ਅਤੇ ਇਸ ਨੂੰ ਟਿਊਨ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਨਾ ਨਹੀਂ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਮੈਮੋਰੀ, CPU ਜਾਂ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਕੋਈ ਚੀਜ਼, ਪਰ ਕੰਮ ਦੇ ਬੋਝ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨਾ ਅਤੇ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਥ੍ਰੁਪੁੱਟ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਹੈ ਤਾਂ ਜੋ ਲੋਡ ਜੋ ਚੰਗੇ ਪ੍ਰੋਗਰਾਮਰਾਂ ਨੇ ਬਣਾਇਆ ਹੈ. ਸਾਡੇ ਉਪਭੋਗਤਾਵਾਂ ਸਮੇਤ, ਸਾਡੇ ਲਈ।
ਇਹ ਕੀ ਹੈ, ਇਹ ਦੱਸਣ ਲਈ ਇੱਕ ਤਸਵੀਰ ਹੈ। ਇੱਕ OS ਬਫਰ ਹੈ। Linux ਇੱਥੇ ਸਾਂਝੀ ਮੈਮੋਰੀ ਹੈ ਅਤੇ PostgreSQL ਸਾਂਝੇ ਬਫਰ ਵੀ ਹਨ। Oracle ਦੇ ਉਲਟ, PostgreSQL ਸਿੱਧੇ ਕਰਨਲ ਬਫਰ ਰਾਹੀਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਮਤਲਬ ਕਿ ਇੱਕ ਪੰਨੇ ਨੂੰ ਡਿਸਕ ਤੋਂ ਆਪਣੀ ਸਾਂਝੀ ਮੈਮੋਰੀ ਵਿੱਚ ਜਾਣ ਲਈ, ਇਸਨੂੰ ਕਰਨਲ ਬਫਰ ਵਿੱਚੋਂ ਲੰਘਣਾ ਪੈਂਦਾ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਵਾਪਸ ਜਾਣਾ ਪੈਂਦਾ ਹੈ - ਇਹੀ ਸਥਿਤੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ।
ਡਿਸਕਾਂ ਇਸ ਸਿਸਟਮ ਦੇ ਅਧੀਨ ਰਹਿੰਦੀਆਂ ਹਨ। ਮੈਂ ਇਸਨੂੰ ਡਿਸਕਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਖਿੱਚਿਆ. ਅਸਲ ਵਿੱਚ, ਇੱਕ RAID ਕੰਟਰੋਲਰ, ਆਦਿ ਹੋ ਸਕਦਾ ਹੈ.
ਅਤੇ ਇਹ ਇਨਪੁਟ-ਆਉਟਪੁੱਟ ਇੱਕ ਜਾਂ ਦੂਜੇ ਤਰੀਕੇ ਨਾਲ ਇਸ ਮਾਮਲੇ ਦੁਆਰਾ ਵਾਪਰਦਾ ਹੈ.
PostgreSQL ਇੱਕ ਕਲਾਸਿਕ ਡਾਟਾਬੇਸ ਹੈ। ਅੰਦਰ ਇੱਕ ਪੰਨਾ ਹੈ। ਅਤੇ ਸਾਰੇ ਇੰਪੁੱਟ ਅਤੇ ਆਉਟਪੁੱਟ ਪੰਨਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਵਾਪਰਦੇ ਹਨ। ਅਸੀਂ ਪੰਨਿਆਂ ਦੇ ਨਾਲ ਮੈਮੋਰੀ ਵਿੱਚ ਬਲਾਕਾਂ ਨੂੰ ਵਧਾ ਰਹੇ ਹਾਂ। ਅਤੇ ਜੇ ਕੁਝ ਨਹੀਂ ਹੋਇਆ, ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਪੜ੍ਹਦੇ ਹਾਂ, ਫਿਰ ਹੌਲੀ-ਹੌਲੀ ਉਹ ਇਸ ਕੈਸ਼ ਤੋਂ, ਸਾਂਝੇ ਬਫਰਾਂ ਤੋਂ ਅਲੋਪ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਵਾਪਸ ਡਿਸਕ 'ਤੇ ਖਤਮ ਹੋ ਜਾਂਦੇ ਹਨ.
ਜੇਕਰ ਅਸੀਂ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਕਿਤੇ ਬਦਲਦੇ ਹਾਂ, ਤਾਂ ਪੂਰੇ ਪੰਨੇ 'ਤੇ ਗੰਦੇ ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਮੈਂ ਉਹਨਾਂ ਨੂੰ ਇੱਥੇ ਨੀਲੇ ਵਿੱਚ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਹੈ। ਅਤੇ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਪੰਨਾ ਬਲਾਕ ਸਟੋਰੇਜ ਨਾਲ ਸਮਕਾਲੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਯਾਨੀ ਜਦੋਂ ਅਸੀਂ ਇਸ ਨੂੰ ਗੰਦਾ ਕੀਤਾ, ਅਸੀਂ WAL ਵਿੱਚ ਐਂਟਰੀ ਕੀਤੀ। ਅਤੇ ਸਮੇਂ ਦੇ ਕਿਸੇ ਸ਼ਾਨਦਾਰ ਪਲ 'ਤੇ, ਚੈਕਪੁਆਇੰਟ ਨਾਮਕ ਇੱਕ ਘਟਨਾ ਆਈ. ਅਤੇ ਇਸ ਲੌਗ ਵਿੱਚ ਜਾਣਕਾਰੀ ਦਰਜ ਕੀਤੀ ਗਈ ਸੀ ਕਿ ਉਹ ਆ ਗਿਆ ਸੀ। ਅਤੇ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਾਰੇ ਗੰਦੇ ਪੰਨੇ ਜੋ ਕਿ ਇਹਨਾਂ ਸਾਂਝੇ ਬਫਰਾਂ ਵਿੱਚ ਉਸ ਸਮੇਂ ਇੱਥੇ ਸਨ, ਨੂੰ ਕਰਨਲ ਬਫਰ ਦੁਆਰਾ fsync ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਟੋਰੇਜ਼ ਡਿਸਕ ਨਾਲ ਸਮਕਾਲੀ ਕੀਤਾ ਗਿਆ ਸੀ।
ਅਜਿਹਾ ਕਿਉਂ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ? ਜੇ ਅਸੀਂ ਵੋਲਟੇਜ ਗੁਆ ਦਿੱਤੀ, ਤਾਂ ਸਾਨੂੰ ਇਹ ਸਥਿਤੀ ਨਹੀਂ ਮਿਲੀ ਕਿ ਸਾਰਾ ਡਾਟਾ ਖਤਮ ਹੋ ਗਿਆ ਸੀ. ਸਥਾਈ ਮੈਮੋਰੀ, ਜਿਸ ਬਾਰੇ ਹਰ ਕੋਈ ਸਾਨੂੰ ਦੱਸਦਾ ਹੈ, ਹੁਣ ਤੱਕ ਡੇਟਾਬੇਸ ਥਿਊਰੀ ਵਿੱਚ ਹੈ - ਇਹ ਇੱਕ ਚਮਕਦਾਰ ਭਵਿੱਖ ਹੈ, ਜਿਸ ਲਈ ਅਸੀਂ, ਬੇਸ਼ਕ, ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਪਸੰਦ ਕਰਦੇ ਹਾਂ, ਪਰ ਹੁਣ ਲਈ ਉਹ ਘੱਟ ਤੋਂ ਘੱਟ 20 ਸਾਲਾਂ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ. ਅਤੇ, ਬੇਸ਼ਕ, ਇਸ ਸਭ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ.
ਅਤੇ ਥ੍ਰੁਪੁੱਟ ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਕਰਨ ਦਾ ਕੰਮ ਇਹਨਾਂ ਸਾਰੇ ਪੜਾਵਾਂ 'ਤੇ ਵਧੀਆ-ਟਿਊਨ ਕਰਨਾ ਹੈ ਤਾਂ ਜੋ ਇਹ ਸਭ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ-ਪਿੱਛੇ ਚਲੇ ਜਾਣ। ਸ਼ੇਅਰਡ ਮੈਮੋਰੀ ਅਸਲ ਵਿੱਚ ਇੱਕ ਪੇਜ ਕੈਸ਼ ਹੈ। PostgreSQL ਵਿੱਚ ਅਸੀਂ ਇੱਕ ਚੋਣਵੀਂ ਪੁੱਛਗਿੱਛ ਜਾਂ ਕੁਝ ਭੇਜਿਆ ਹੈ, ਇਸਨੇ ਡਿਸਕ ਤੋਂ ਇਹ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ। ਉਹ ਸਾਂਝੇ ਬਫਰਾਂ ਵਿੱਚ ਖਤਮ ਹੋਏ। ਇਸ ਅਨੁਸਾਰ, ਇਸ ਨੂੰ ਬਿਹਤਰ ਕੰਮ ਕਰਨ ਲਈ, ਬਹੁਤ ਸਾਰੀ ਯਾਦਦਾਸ਼ਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ.
ਇਹ ਸਭ ਚੰਗੀ ਤਰ੍ਹਾਂ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਸਾਰੇ ਪੜਾਵਾਂ 'ਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਅਤੇ ਸੰਤੁਲਿਤ ਹਾਰਡਵੇਅਰ ਦੀ ਚੋਣ ਕਰੋ, ਕਿਉਂਕਿ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਕਿਸੇ ਥਾਂ 'ਤੇ ਅਸੰਤੁਲਨ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੀ ਮੈਮੋਰੀ ਬਣਾ ਸਕਦੇ ਹੋ, ਪਰ ਇਹ ਲੋੜੀਂਦੀ ਗਤੀ ਨਾਲ ਸੇਵਾ ਨਹੀਂ ਕੀਤੀ ਜਾਵੇਗੀ.
ਅਤੇ ਆਓ ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਬਿੰਦੂ ਵਿੱਚੋਂ ਲੰਘੀਏ.
ਇਹਨਾਂ ਪੰਨਿਆਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ-ਪਿੱਛੇ ਯਾਤਰਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਹੇਠ ਲਿਖਿਆਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ:
- ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਮੈਮੋਰੀ ਨਾਲ ਵਧੇਰੇ ਕੁਸ਼ਲਤਾ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ.
- ਦੂਜਾ, ਜਦੋਂ ਮੈਮੋਰੀ ਤੋਂ ਪੰਨੇ ਡਿਸਕ 'ਤੇ ਜਾਂਦੇ ਹਨ ਤਾਂ ਇਹ ਤਬਦੀਲੀ ਵਧੇਰੇ ਕੁਸ਼ਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
- ਅਤੇ ਤੀਜਾ, ਚੰਗੀਆਂ ਡਿਸਕਾਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।
ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ 512 GB RAM ਹੈ ਸਰਵਰ ਅਤੇ ਜੇਕਰ ਇਹ ਸਭ ਕੁਝ ਬਿਨਾਂ ਕਿਸੇ ਕੈਸ਼ ਦੇ SATA ਹਾਰਡ ਡਰਾਈਵ 'ਤੇ ਖਤਮ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਪੂਰਾ ਡੇਟਾਬੇਸ ਸਰਵਰ ਸਿਰਫ਼ ਇੱਕ ਕੱਦੂ ਵਿੱਚ ਨਹੀਂ, ਸਗੋਂ SATA ਇੰਟਰਫੇਸ ਵਾਲੇ ਇੱਕ ਕੱਦੂ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਉੱਥੇ ਹੀ ਫਸ ਜਾਓਗੇ। ਅਤੇ ਕੁਝ ਵੀ ਤੁਹਾਨੂੰ ਨਹੀਂ ਬਚਾ ਸਕੇਗਾ।
ਯਾਦਦਾਸ਼ਤ ਦੇ ਨਾਲ ਪਹਿਲੇ ਨੁਕਤੇ ਬਾਰੇ, ਤਿੰਨ ਚੀਜ਼ਾਂ ਹਨ ਜੋ ਜੀਵਨ ਨੂੰ ਬਹੁਤ ਮੁਸ਼ਕਲ ਬਣਾ ਸਕਦੀਆਂ ਹਨ.
ਉਹਨਾਂ ਵਿੱਚੋਂ ਪਹਿਲਾ NUMA ਹੈ। NUMA ਇੱਕ ਅਜਿਹੀ ਚੀਜ਼ ਹੈ ਜੋ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਬਣਾਈ ਗਈ ਹੈ। ਕੰਮ ਦੇ ਬੋਝ 'ਤੇ ਨਿਰਭਰ ਕਰਦਿਆਂ, ਵੱਖ-ਵੱਖ ਚੀਜ਼ਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਅਤੇ ਇਸਦੇ ਨਵੇਂ ਮੌਜੂਦਾ ਰੂਪ ਵਿੱਚ, ਇਹ ਐਪਲੀਕੇਸ਼ਨਾਂ ਜਿਵੇਂ ਕਿ ਡੇਟਾਬੇਸ ਲਈ ਬਹੁਤ ਵਧੀਆ ਨਹੀਂ ਹੈ ਜੋ ਪੇਜ ਕੈਸ਼ ਸ਼ੇਅਰ ਬਫਰਾਂ ਦੀ ਤੀਬਰਤਾ ਨਾਲ ਵਰਤੋਂ ਕਰਦੇ ਹਨ.
ਸੰਖੇਪ ਵਿਁਚ. ਤੁਸੀਂ ਕਿਵੇਂ ਦੱਸ ਸਕਦੇ ਹੋ ਕਿ NUMA ਵਿੱਚ ਕੁਝ ਗਲਤ ਹੈ? ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਅਣਸੁਖਾਵੀਂ ਦਸਤਕ ਹੈ, ਅਚਾਨਕ ਕੁਝ CPU ਓਵਰਲੋਡ ਹੋ ਗਿਆ ਹੈ। ਉਸੇ ਸਮੇਂ, ਤੁਸੀਂ PostgreSQL ਵਿੱਚ ਸਵਾਲਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਹੋ ਅਤੇ ਦੇਖੋ ਕਿ ਉੱਥੇ ਕੁਝ ਵੀ ਸਮਾਨ ਨਹੀਂ ਹੈ. ਇਹ ਸਵਾਲ ਇੰਨੇ CPU ਇੰਟੈਂਸਿਵ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ। ਤੁਸੀਂ ਇਸ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਲਈ ਫੜ ਸਕਦੇ ਹੋ. PostgreSQL ਲਈ NUMA ਨੂੰ ਕਿਵੇਂ ਸੰਰਚਿਤ ਕਰਨਾ ਹੈ ਇਸ ਬਾਰੇ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸਹੀ ਸਿਫ਼ਾਰਿਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਆਸਾਨ ਹੈ।
ਅਸਲ ਵਿੱਚ ਕੀ ਹੋ ਰਿਹਾ ਹੈ? NUMA ਦਾ ਅਰਥ ਹੈ ਗੈਰ-ਯੂਨੀਫਾਰਮ ਮੈਮੋਰੀ ਐਕਸੈਸ। ਗੱਲ ਕੀ ਹੈ? ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ CPU ਹੈ, ਇਸਦੇ ਅੱਗੇ ਇਸਦੀ ਸਥਾਨਕ ਮੈਮੋਰੀ ਹੈ. ਅਤੇ ਇਹ ਮੈਮੋਰੀ ਇੰਟਰਕਨੈਕਟ ਦੂਜੇ CPU ਤੋਂ ਮੈਮੋਰੀ ਨੂੰ ਖਿੱਚ ਸਕਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਦੌੜਦੇ ਹੋ numactl --hardware, ਫਿਰ ਤੁਹਾਨੂੰ ਇੰਨੀ ਵੱਡੀ ਸ਼ੀਟ ਮਿਲੇਗੀ। ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਨਾਲ, ਇੱਕ ਦੂਰੀ ਵਾਲਾ ਖੇਤਰ ਹੋਵੇਗਾ. ਨੰਬਰ ਹੋਣਗੇ - 10-20, ਕੁਝ ਅਜਿਹਾ। ਇਹ ਨੰਬਰ ਇਸ ਰਿਮੋਟ ਮੈਮੋਰੀ ਨੂੰ ਚੁੱਕਣ ਅਤੇ ਇਸਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਵਰਤਣ ਲਈ ਹੌਪਾਂ ਦੀ ਗਿਣਤੀ ਤੋਂ ਵੱਧ ਕੁਝ ਨਹੀਂ ਹਨ। ਸਿਧਾਂਤ ਵਿੱਚ, ਇੱਕ ਚੰਗਾ ਵਿਚਾਰ. ਇਹ ਕੰਮ ਦੇ ਬੋਝ ਦੀ ਇੱਕ ਸੀਮਾ ਦੇ ਅਧੀਨ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਤੇਜ਼ ਕਰਦਾ ਹੈ।
ਹੁਣ ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ CPU ਹੈ ਜੋ ਪਹਿਲਾਂ ਆਪਣੀ ਸਥਾਨਕ ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ, ਫਿਰ ਕਿਸੇ ਚੀਜ਼ ਲਈ ਇੰਟਰਕਨੈਕਟ ਦੁਆਰਾ ਦੂਜੀ ਮੈਮੋਰੀ ਨੂੰ ਖਿੱਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ। ਅਤੇ ਇਹ CPU ਤੁਹਾਡਾ ਪੂਰਾ PostgreSQL ਪੇਜ ਕੈਸ਼ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ - ਬੱਸ, ਕੁਝ ਗੀਗਾਬਾਈਟ। ਤੁਹਾਨੂੰ ਹਮੇਸ਼ਾ ਸਭ ਤੋਂ ਮਾੜਾ ਕੇਸ ਮਿਲਦਾ ਹੈ, ਕਿਉਂਕਿ CPU 'ਤੇ ਉਸ ਮੋਡੀਊਲ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਬਹੁਤ ਘੱਟ ਮੈਮੋਰੀ ਹੁੰਦੀ ਹੈ। ਅਤੇ ਸੇਵਾ ਕੀਤੀ ਗਈ ਸਾਰੀ ਮੈਮੋਰੀ ਇਹਨਾਂ ਆਪਸ ਵਿੱਚ ਜੁੜਦੀ ਹੈ। ਇਹ ਹੌਲੀ ਅਤੇ ਉਦਾਸ ਬਾਹਰ ਕਾਮੁਕ. ਅਤੇ ਤੁਹਾਡਾ ਪ੍ਰੋਸੈਸਰ ਜੋ ਇਸ ਨੋਡ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ ਲਗਾਤਾਰ ਓਵਰਲੋਡ ਹੁੰਦਾ ਹੈ. ਅਤੇ ਇਸ ਮੈਮੋਰੀ ਦਾ ਐਕਸੈਸ ਟਾਈਮ ਖਰਾਬ, ਹੌਲੀ ਹੈ। ਇਹ ਉਹ ਸਥਿਤੀ ਹੈ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਚਾਹੁੰਦੇ ਹੋ ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਡੇਟਾਬੇਸ ਲਈ ਵਰਤ ਰਹੇ ਹੋ।
ਇਸ ਲਈ, ਡੇਟਾਬੇਸ ਲਈ ਵਧੇਰੇ ਸਹੀ ਵਿਕਲਪ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਲਈ ਹੈ। Linux ਮੈਨੂੰ ਪਤਾ ਵੀ ਨਹੀਂ ਸੀ ਕਿ ਉੱਥੇ ਕੀ ਹੋ ਰਿਹਾ ਹੈ। ਇਸ ਲਈ ਉਹ ਆਪਣੀ ਯਾਦਦਾਸ਼ਤ ਤੱਕ ਉਸੇ ਤਰ੍ਹਾਂ ਪਹੁੰਚ ਕਰ ਸਕਦੀ ਸੀ ਜਿਵੇਂ ਉਹ ਕਰਦੀ ਹੈ।
ਅਜਿਹਾ ਕਿਉਂ ਹੈ? ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਇਹ ਇਸ ਦੇ ਉਲਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਇਹ ਇੱਕ ਸਧਾਰਨ ਕਾਰਨ ਕਰਕੇ ਵਾਪਰਦਾ ਹੈ: ਸਾਨੂੰ ਪੇਜ ਕੈਸ਼ ਲਈ ਬਹੁਤ ਸਾਰੀ ਮੈਮੋਰੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ - ਦਸਾਂ, ਸੈਂਕੜੇ ਗੀਗਾਬਾਈਟ।
ਅਤੇ ਜੇਕਰ ਅਸੀਂ ਇਹ ਸਭ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ ਅਤੇ ਆਪਣੇ ਡੇਟਾ ਨੂੰ ਉੱਥੇ ਕੈਸ਼ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਕੈਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਲਾਭ ਮੈਮੋਰੀ ਤੱਕ ਅਜਿਹੀ ਮੁਸ਼ਕਲ ਪਹੁੰਚ ਤੋਂ ਹੋਣ ਵਾਲੇ ਲਾਭ ਨਾਲੋਂ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਹੋਵੇਗਾ। ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਸਾਨੂੰ ਇਸ ਤੱਥ ਦੇ ਮੁਕਾਬਲੇ ਅਸਾਧਾਰਣ ਲਾਭ ਹੋਵੇਗਾ ਕਿ ਅਸੀਂ NUMA ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮੈਮੋਰੀ ਨੂੰ ਵਧੇਰੇ ਕੁਸ਼ਲਤਾ ਨਾਲ ਐਕਸੈਸ ਕਰਾਂਗੇ।
ਇਸ ਲਈ, ਇਸ ਸਮੇਂ ਇੱਥੇ ਦੋ ਪਹੁੰਚ ਹਨ, ਜਦੋਂ ਤੱਕ ਕਿ ਉੱਜਵਲ ਭਵਿੱਖ ਨਹੀਂ ਆ ਜਾਂਦਾ, ਅਤੇ ਡੇਟਾਬੇਸ ਖੁਦ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦੇ ਯੋਗ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਇਹ ਕਿਹੜੇ CPUs 'ਤੇ ਚੱਲ ਰਿਹਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਕਿੱਥੋਂ ਕੁਝ ਕੱਢਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ.
ਇਸ ਲਈ, ਸਹੀ ਪਹੁੰਚ NUMA ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਯੋਗ ਕਰਨਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਰੀਬੂਟ ਕਰਨ ਵੇਲੇ। ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਜਿੱਤਾਂ ਇੰਨੇ ਵਿਸ਼ਾਲਤਾ ਦੇ ਆਦੇਸ਼ਾਂ ਦੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਕਿ ਕਿਹੜਾ ਬਿਹਤਰ ਹੈ ਦਾ ਸਵਾਲ ਹੀ ਪੈਦਾ ਨਹੀਂ ਹੁੰਦਾ।
ਇੱਕ ਹੋਰ ਵਿਕਲਪ ਹੈ. ਅਸੀਂ ਇਸਨੂੰ ਪਹਿਲੇ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਵਾਰ ਵਰਤਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਜਦੋਂ ਕੋਈ ਗਾਹਕ ਸਹਾਇਤਾ ਲਈ ਸਾਡੇ ਕੋਲ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਸਰਵਰ ਨੂੰ ਰੀਬੂਟ ਕਰਨਾ ਉਸ ਲਈ ਇੱਕ ਵੱਡੀ ਗੱਲ ਹੈ। ਉਸਦਾ ਉਥੇ ਕਾਰੋਬਾਰ ਹੈ। ਅਤੇ ਉਹ NUMA ਦੇ ਕਾਰਨ ਸਮੱਸਿਆਵਾਂ ਦਾ ਅਨੁਭਵ ਕਰਦੇ ਹਨ. ਇਸ ਲਈ, ਅਸੀਂ ਇਸਨੂੰ ਰੀਬੂਟ ਕਰਨ ਨਾਲੋਂ ਘੱਟ ਹਮਲਾਵਰ ਤਰੀਕਿਆਂ ਨਾਲ ਅਯੋਗ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ, ਪਰ ਇਹ ਜਾਂਚ ਕਰਨ ਲਈ ਸਾਵਧਾਨ ਰਹੋ ਕਿ ਇਹ ਅਯੋਗ ਹੈ। ਕਿਉਂਕਿ, ਜਿਵੇਂ ਕਿ ਤਜਰਬਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਇਹ ਚੰਗਾ ਹੈ ਕਿ ਅਸੀਂ NUMA ਨੂੰ ਪੇਰੈਂਟ PostgreSQL ਪ੍ਰਕਿਰਿਆ 'ਤੇ ਅਸਮਰੱਥ ਕਰਦੇ ਹਾਂ, ਪਰ ਇਹ ਬਿਲਕੁਲ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਕੰਮ ਕਰੇਗਾ। ਸਾਨੂੰ ਇਹ ਦੇਖਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਉਹ ਸੱਚਮੁੱਚ ਬੰਦ ਹੋ ਗਈ ਹੈ।
ਰੌਬਰਟ ਹਾਸ ਦੁਆਰਾ ਇੱਕ ਚੰਗੀ ਪੋਸਟ ਹੈ. ਇਹ PostgreSQL ਪ੍ਰਤੀਬੱਧਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਸਾਰੇ ਨੀਵੇਂ-ਪੱਧਰ ਦੇ ਗਿਬਲਟਸ ਦੇ ਮੁੱਖ ਡਿਵੈਲਪਰਾਂ ਵਿੱਚੋਂ ਇੱਕ। ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਪੋਸਟ ਤੋਂ ਲਿੰਕਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹ ਕਈ ਰੰਗੀਨ ਕਹਾਣੀਆਂ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ ਕਿ ਕਿਵੇਂ NUMA ਨੇ ਲੋਕਾਂ ਲਈ ਜੀਵਨ ਮੁਸ਼ਕਲ ਬਣਾਇਆ. ਦੇਖੋ, ਸਾਡੇ ਡੇਟਾਬੇਸ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨ ਲਈ ਸਰਵਰ 'ਤੇ ਕਿਸ ਚੀਜ਼ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਇਸ ਬਾਰੇ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਚੈਕਲਿਸਟ ਦਾ ਅਧਿਐਨ ਕਰੋ। ਇਹਨਾਂ ਸੈਟਿੰਗਾਂ ਨੂੰ ਲਿਖਣ ਅਤੇ ਜਾਂਚਣ ਦੀ ਲੋੜ ਹੈ, ਕਿਉਂਕਿ ਨਹੀਂ ਤਾਂ ਇਹ ਬਹੁਤ ਵਧੀਆ ਨਹੀਂ ਹੋਵੇਗਾ।
ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ ਕਿ ਇਹ ਉਹਨਾਂ ਸਾਰੀਆਂ ਸੈਟਿੰਗਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਮੈਂ ਗੱਲ ਕਰਾਂਗਾ। ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਡੇਟਾਬੇਸ ਨੂੰ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਲਈ ਮਾਸਟਰ-ਸਲੇਵ ਮੋਡ ਵਿੱਚ ਇਕੱਤਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਗੁਲਾਮ 'ਤੇ ਇਹ ਸੈਟਿੰਗਾਂ ਕਰਨਾ ਨਾ ਭੁੱਲੋ ਕਿਉਂਕਿ ਇੱਕ ਦਿਨ ਤੁਹਾਡੇ ਨਾਲ ਦੁਰਘਟਨਾ ਹੋਵੇਗੀ ਅਤੇ ਤੁਸੀਂ ਨੌਕਰ ਵੱਲ ਸਵਿਚ ਕਰੋਗੇ ਅਤੇ ਇਹ ਮਾਲਕ ਬਣ ਜਾਵੇਗਾ।
ਐਮਰਜੈਂਸੀ ਸਥਿਤੀ ਵਿੱਚ, ਜਦੋਂ ਸਭ ਕੁਝ ਬਹੁਤ ਖਰਾਬ ਹੁੰਦਾ ਹੈ, ਤੁਹਾਡਾ ਫੋਨ ਲਗਾਤਾਰ ਵੱਜ ਰਿਹਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡਾ ਬੌਸ ਇੱਕ ਵੱਡੀ ਸੋਟੀ ਲੈ ਕੇ ਦੌੜਦਾ ਹੈ, ਤੁਹਾਡੇ ਕੋਲ ਜਾਂਚ ਕਰਨ ਬਾਰੇ ਸੋਚਣ ਦਾ ਸਮਾਂ ਨਹੀਂ ਹੋਵੇਗਾ। ਅਤੇ ਨਤੀਜੇ ਕਾਫ਼ੀ ਵਿਨਾਸ਼ਕਾਰੀ ਹੋ ਸਕਦੇ ਹਨ.
ਅਗਲਾ ਬਿੰਦੂ ਵੱਡੇ ਪੰਨੇ ਹਨ. ਵੱਡੇ ਪੰਨਿਆਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਟੈਸਟ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ, ਅਤੇ ਅਜਿਹਾ ਕਰਨ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ, ਹਾਲਾਂਕਿ ਅਜਿਹੇ ਬੈਂਚਮਾਰਕ ਹਨ ਜੋ ਇਹ ਕਰ ਸਕਦੇ ਹਨ. ਉਹ ਗੂਗਲ ਲਈ ਆਸਾਨ ਹਨ।
ਗੱਲ ਕੀ ਹੈ? ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਜ਼ਿਆਦਾ RAM ਵਾਲਾ ਬਹੁਤ ਮਹਿੰਗਾ ਸਰਵਰ ਨਹੀਂ ਹੈ, ਉਦਾਹਰਨ ਲਈ, 30 GB ਤੋਂ ਵੱਧ। ਤੁਸੀਂ ਵੱਡੇ ਪੰਨਿਆਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਮੈਮੋਰੀ ਵਰਤੋਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਓਵਰਹੈੱਡ ਹੈ। ਅਤੇ ਇਹ ਓਵਰਹੈੱਡ ਸਭ ਤੋਂ ਸੁਹਾਵਣਾ ਤੋਂ ਬਹੁਤ ਦੂਰ ਹੈ.
ਅਜਿਹਾ ਕਿਉਂ ਹੈ? ਤਾਂ ਕੀ ਹੋ ਰਿਹਾ ਹੈ? ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਮੈਮੋਰੀ ਨੂੰ ਛੋਟੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ। ਇਹ ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਹੈ, ਇਹ ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਹੋਇਆ ਹੈ। ਅਤੇ ਜੇਕਰ ਅਸੀਂ ਵਿਸਥਾਰ ਵਿੱਚ ਜਾਂਦੇ ਹਾਂ, ਤਾਂ OS ਨੂੰ ਵਰਚੁਅਲ ਪਤਿਆਂ ਦਾ ਭੌਤਿਕ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਅਤੇ ਇਹ ਪ੍ਰਕਿਰਿਆ ਸਭ ਤੋਂ ਸਰਲ ਨਹੀਂ ਹੈ, ਇਸਲਈ OS ਟ੍ਰਾਂਸਲੇਸ਼ਨ ਲੁਕਸਾਈਡ ਬਫਰ (TLB) ਵਿੱਚ ਇਸ ਕਾਰਵਾਈ ਦੇ ਨਤੀਜੇ ਨੂੰ ਕੈਸ਼ ਕਰਦਾ ਹੈ।
ਅਤੇ ਕਿਉਂਕਿ TLB ਇੱਕ ਕੈਸ਼ ਹੈ, ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਕੈਸ਼ ਵਿੱਚ ਮੌਜੂਦ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੀ RAM ਹੈ ਅਤੇ ਇਹ ਸਭ ਛੋਟੇ ਭਾਗਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ, ਤਾਂ ਇਹ ਬਫਰ ਬਹੁਤ ਵੱਡਾ ਬਣ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਜੇ ਕੈਸ਼ ਵੱਡਾ ਹੈ, ਤਾਂ ਇਸ ਦੁਆਰਾ ਖੋਜ ਕਰਨਾ ਹੌਲੀ ਹੈ. ਓਵਰਹੈੱਡ ਸਿਹਤਮੰਦ ਹੈ ਅਤੇ ਇਹ ਆਪਣੇ ਆਪ ਵਿੱਚ ਜਗ੍ਹਾ ਲੈਂਦਾ ਹੈ, ਯਾਨੀ ਕਿ RAM ਨੂੰ ਕਿਸੇ ਗਲਤ ਚੀਜ਼ ਦੁਆਰਾ ਖਪਤ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ। ਇਸ ਸਮੇਂ.
ਦੋ: ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਕੈਸ਼ ਜਿੰਨਾ ਵੱਡਾ ਹੁੰਦਾ ਹੈ, ਓਨਾ ਹੀ ਜ਼ਿਆਦਾ ਸੰਭਾਵਨਾ ਹੁੰਦੀ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕੈਸ਼ ਮਿਸ ਹੋਣ ਦਾ ਅਨੁਭਵ ਹੋਵੇਗਾ। ਅਤੇ ਇਸ ਕੈਸ਼ ਦੀ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਤੇਜ਼ੀ ਨਾਲ ਘੱਟ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਇਸਦਾ ਆਕਾਰ ਵਧਦਾ ਹੈ। ਇਸ ਲਈ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਇੱਕ ਸਧਾਰਨ ਪਹੁੰਚ ਲੈ ਕੇ ਆਏ ਹਨ। Linux ਇਹ ਬਹੁਤ ਸਮੇਂ ਤੋਂ ਵਰਤੋਂ ਵਿੱਚ ਹੈ। ਇਹ ਬਹੁਤ ਸਮਾਂ ਪਹਿਲਾਂ FreeBSD ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਇਆ ਸੀ। ਪਰ ਅਸੀਂ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ Linuxਇਹ ਬਹੁਤ ਵੱਡੇ ਪੰਨੇ ਹਨ।
ਅਤੇ ਇੱਥੇ ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਵਿਸ਼ਾਲ ਪੰਨੇ, ਇੱਕ ਵਿਚਾਰ ਦੇ ਰੂਪ ਵਿੱਚ, ਸ਼ੁਰੂ ਵਿੱਚ ਓਰੇਕਲ ਅਤੇ IBM ਸ਼ਾਮਲ ਕਰਨ ਵਾਲੇ ਭਾਈਚਾਰਿਆਂ ਦੁਆਰਾ ਧੱਕੇ ਗਏ ਸਨ, ਅਰਥਾਤ ਡੇਟਾਬੇਸ ਨਿਰਮਾਤਾਵਾਂ ਨੇ ਜ਼ੋਰਦਾਰ ਸੋਚਿਆ ਕਿ ਇਹ ਡੇਟਾਬੇਸ ਲਈ ਵੀ ਲਾਭਦਾਇਕ ਹੋਵੇਗਾ।
ਅਤੇ ਇਸ ਨੂੰ PostgreSQL ਨਾਲ ਕਿਵੇਂ ਦੋਸਤ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ? ਪਹਿਲਾਂ, ਲੀਨਕਸ ਕਰਨਲ ਵਿੱਚ ਵੱਡੇ ਪੰਨਿਆਂ ਨੂੰ ਯੋਗ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਦੂਜਾ, ਉਹਨਾਂ ਨੂੰ sysctl ਪੈਰਾਮੀਟਰ ਦੁਆਰਾ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ - ਕਿੰਨੇ ਹਨ। ਇੱਥੇ ਨੰਬਰ ਕਿਸੇ ਪੁਰਾਣੇ ਸਰਵਰ ਤੋਂ ਹਨ। ਤੁਸੀਂ ਗਣਨਾ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਿੰਨੇ ਸਾਂਝੇ ਬਫਰ ਹਨ ਤਾਂ ਜੋ ਵੱਡੇ ਪੰਨੇ ਉੱਥੇ ਫਿੱਟ ਹੋ ਸਕਣ।
ਅਤੇ ਜੇਕਰ ਤੁਹਾਡਾ ਪੂਰਾ ਸਰਵਰ PostgreSQL ਨੂੰ ਸਮਰਪਿਤ ਹੈ, ਤਾਂ ਇੱਕ ਵਧੀਆ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਸ਼ੇਅਰਡ ਬਫਰਾਂ ਲਈ RAM ਦਾ 25% ਨਿਰਧਾਰਤ ਕਰਨਾ ਹੈ, ਜਾਂ 75% ਜੇਕਰ ਤੁਹਾਨੂੰ ਯਕੀਨ ਹੈ ਕਿ ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਇਸ 75% ਵਿੱਚ ਫਿੱਟ ਹੋਵੇਗਾ। ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਇੱਕ। ਅਤੇ ਵਿਚਾਰ ਕਰੋ, ਜੇ ਤੁਹਾਡੇ ਕੋਲ 256 GB RAM ਹੈ, ਤਾਂ, ਇਸਦੇ ਅਨੁਸਾਰ, ਤੁਹਾਡੇ ਕੋਲ 64 GB ਵੱਡੇ ਬਫਰ ਹੋਣਗੇ. ਕੁਝ ਹਾਸ਼ੀਏ ਨਾਲ ਲਗਭਗ ਗਣਨਾ ਕਰੋ - ਇਹ ਅੰਕੜਾ ਕਿਸ ਲਈ ਸੈੱਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਸੰਸਕਰਣ 9.2 ਤੋਂ ਪਹਿਲਾਂ (ਜੇ ਮੈਂ ਗਲਤ ਨਹੀਂ ਹਾਂ, ਸੰਸਕਰਣ 8.2 ਤੋਂ), ਤੀਜੀ-ਧਿਰ ਦੀ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਪੋਸਟਗ੍ਰੇਸਕਿਯੂਐਲ ਨੂੰ ਵੱਡੇ ਪੰਨਿਆਂ ਨਾਲ ਜੋੜਨਾ ਸੰਭਵ ਸੀ. ਅਤੇ ਇਹ ਹਮੇਸ਼ਾ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ. ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਵੱਡੇ ਪੰਨਿਆਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਨਿਰਧਾਰਤ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ ਲਈ ਕਰਨਲ ਦੀ ਲੋੜ ਹੈ। ਅਤੇ, ਦੂਜਾ, ਤਾਂ ਜੋ ਉਹਨਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕੇ. ਇਹ ਸਿਰਫ਼ ਇਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਵਰਤਿਆ ਜਾਵੇਗਾ। ਕਿਉਂਕਿ PostgreSQL ਨੇ ਸਿਸਟਮ 5 ਸ਼ੈਲੀ ਵਿੱਚ ਮੈਮੋਰੀ ਨਿਰਧਾਰਤ ਕੀਤੀ ਹੈ, ਇਹ libhugetlbfs ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ - ਇਹ ਲਾਇਬ੍ਰੇਰੀ ਦਾ ਪੂਰਾ ਨਾਮ ਹੈ।
9.3 ਵਿੱਚ, ਮੈਮੋਰੀ ਦੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ PostgreSQL ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਸੁਧਾਰ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਸਿਸਟਮ 5 ਮੈਮੋਰੀ ਵੰਡ ਵਿਧੀ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਗਿਆ ਸੀ। ਹਰ ਕੋਈ ਬਹੁਤ ਖੁਸ਼ ਸੀ, ਕਿਉਂਕਿ ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਮਸ਼ੀਨ 'ਤੇ ਦੋ PostgreSQL ਉਦਾਹਰਨਾਂ ਨੂੰ ਚਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ, ਅਤੇ ਉਹ ਕਹਿੰਦਾ ਹੈ ਕਿ ਮੇਰੇ ਕੋਲ ਲੋੜੀਂਦੀ ਸਾਂਝੀ ਮੈਮੋਰੀ ਨਹੀਂ ਹੈ. ਅਤੇ ਉਹ ਕਹਿੰਦਾ ਹੈ ਕਿ sysctl ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਅਤੇ ਅਜਿਹਾ ਇੱਕ sysctl ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਰੀਬੂਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਆਦਿ ਆਮ ਤੌਰ 'ਤੇ, ਹਰ ਕੋਈ ਖੁਸ਼ ਸੀ. ਪਰ mmap ਮੈਮੋਰੀ ਵੰਡ ਨੇ ਵੱਡੇ ਪੰਨਿਆਂ ਦੀ ਵਰਤੋਂ ਨੂੰ ਤੋੜ ਦਿੱਤਾ। ਸਾਡੇ ਜ਼ਿਆਦਾਤਰ ਗਾਹਕ ਵੱਡੇ ਸਾਂਝੇ ਬਫਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਅਤੇ ਅਸੀਂ ਜ਼ੋਰਦਾਰ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਹੈ ਕਿ 9.3 'ਤੇ ਸਵਿਚ ਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਓਵਰਹੈੱਡ ਦੀ ਚੰਗੀ ਪ੍ਰਤੀਸ਼ਤਤਾ ਵਿੱਚ ਗਣਨਾ ਕੀਤੀ ਜਾਣ ਲੱਗੀ।
ਪਰ ਕਮਿਊਨਿਟੀ ਨੇ ਇਸ ਸਮੱਸਿਆ ਵੱਲ ਧਿਆਨ ਦਿੱਤਾ ਅਤੇ 9.4 ਵਿੱਚ ਉਹਨਾਂ ਨੇ ਇਸ ਘਟਨਾ ਨੂੰ ਬਹੁਤ ਵਧੀਆ ਢੰਗ ਨਾਲ ਦੁਬਾਰਾ ਕੀਤਾ। ਅਤੇ 9.4 ਵਿੱਚ postgresql.conf ਵਿੱਚ ਇੱਕ ਪੈਰਾਮੀਟਰ ਦਿਖਾਈ ਦਿੱਤਾ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਕੋਸ਼ਿਸ਼, ਚਾਲੂ ਜਾਂ ਬੰਦ ਨੂੰ ਸਮਰੱਥ ਕਰ ਸਕਦੇ ਹੋ।
ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਹੈ। ਜਦੋਂ PostgreSQL ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਇਹ ਸ਼ੇਅਰਡ ਮੈਮੋਰੀ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ, ਇਹ ਇਸ ਮੈਮੋਰੀ ਨੂੰ ਵੱਡੇ ਪੰਨਿਆਂ ਤੋਂ ਫੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਅਤੇ ਜੇਕਰ ਇਹ ਕੰਮ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਇਹ ਆਮ ਚੋਣ 'ਤੇ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਫ੍ਰੀਬੀਐਸਡੀ ਜਾਂ ਸੋਲਾਰਿਸ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ, ਇਹ ਹਮੇਸ਼ਾ ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ।
ਜੇਕਰ "ਚਾਲੂ" ਹੈ, ਤਾਂ ਇਹ ਸਿਰਫ਼ ਉਦੋਂ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਵੇਗਾ ਜਦੋਂ ਇਹ ਵੱਡੇ ਪੰਨਿਆਂ ਤੋਂ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਇਹ ਤਰਜੀਹ ਦਾ ਮਾਮਲਾ ਹੈ। ਪਰ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ "ਕੋਸ਼ਿਸ਼" ਹੈ, ਤਾਂ ਜਾਂਚ ਕਰੋ ਕਿ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਉਹ ਨਿਰਧਾਰਤ ਕੀਤਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਗਲਤੀ ਲਈ ਕਾਫ਼ੀ ਜਗ੍ਹਾ ਹੈ। ਵਰਤਮਾਨ ਵਿੱਚ, ਇਹ ਕਾਰਜਸ਼ੀਲਤਾ ਸਿਰਫ਼ Linux.
ਅੱਗੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਹੋਰ ਛੋਟਾ ਨੋਟ। ਪਾਰਦਰਸ਼ੀ ਵਿਸ਼ਾਲ ਪੰਨੇ ਅਜੇ ਤੱਕ PostgreSQL ਬਾਰੇ ਨਹੀਂ ਹਨ. ਉਹ ਇਹਨਾਂ ਦੀ ਆਮ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਅਤੇ ਅਜਿਹੇ ਵਰਕਲੋਡ ਲਈ ਪਾਰਦਰਸ਼ੀ ਵਿਸ਼ਾਲ ਪੰਨਿਆਂ ਦੇ ਨਾਲ, ਜਦੋਂ ਸ਼ੇਅਰਡ ਮੈਮੋਰੀ ਦੇ ਇੱਕ ਵੱਡੇ ਟੁਕੜੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਲਾਭ ਸਿਰਫ ਬਹੁਤ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਆਉਂਦੇ ਹਨ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਟੈਰਾਬਾਈਟ ਮੈਮੋਰੀ ਹੈ ਤਾਂ ਇਹ ਪਲੇਅ ਹੋ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਅਸੀਂ ਰੋਜ਼ਾਨਾ ਦੀਆਂ ਹੋਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਜਦੋਂ ਤੁਹਾਡੀ ਮਸ਼ੀਨ 'ਤੇ 32, 64, 128, 256 GB ਮੈਮੋਰੀ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਆਮ ਵੱਡੇ ਪੰਨੇ ਠੀਕ ਹਨ, ਅਤੇ ਅਸੀਂ ਸਿਰਫ਼ ਪਾਰਦਰਸ਼ੀ ਨੂੰ ਅਯੋਗ ਕਰਦੇ ਹਾਂ।
ਅਤੇ ਯਾਦਦਾਸ਼ਤ ਬਾਰੇ ਆਖਰੀ ਗੱਲ ਫਲੂਟ ਨਾਲ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸਬੰਧਤ ਨਹੀਂ ਹੈ, ਇਹ ਅਸਲ ਵਿੱਚ ਤੁਹਾਡੀ ਜ਼ਿੰਦਗੀ ਨੂੰ ਬਰਬਾਦ ਕਰ ਸਕਦੀ ਹੈ. ਸਾਰੇ ਥ੍ਰੋਪੁੱਟ ਇਸ ਤੱਥ ਦੁਆਰਾ ਬਹੁਤ ਪ੍ਰਭਾਵਿਤ ਹੋਣਗੇ ਕਿ ਸਰਵਰ ਲਗਾਤਾਰ ਸਵੈਪ ਕਰ ਰਿਹਾ ਹੈ।
ਅਤੇ ਇਹ ਕਈ ਤਰੀਕਿਆਂ ਨਾਲ ਬਹੁਤ ਤੰਗ ਕਰਨ ਵਾਲਾ ਹੋਵੇਗਾ। ਮੁੱਖ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਆਧੁਨਿਕ ਕਰਨਲ ਪੁਰਾਣੇ ਕਰਨਲਾਂ ਨਾਲੋਂ ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ। Linuxਅਤੇ ਇਹ ਇੱਕ ਅਜਿਹੀ ਚੀਜ਼ ਹੈ ਜਿਸ 'ਤੇ ਕਦਮ ਰੱਖਣਾ ਕਾਫ਼ੀ ਅਣਸੁਖਾਵਾਂ ਹੈ, ਕਿਉਂਕਿ ਜਦੋਂ ਅਸੀਂ ਕਿਸੇ ਕਿਸਮ ਦੇ ਸਵੈਪ ਓਪਰੇਸ਼ਨ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਾਂ, ਤਾਂ ਇਹ ਇੱਕ ਅਚਨਚੇਤੀ OOM ਕਿਲਰ ਨਾਲ ਖਤਮ ਹੁੰਦਾ ਹੈ। ਅਤੇ ਇੱਕ ਅਚਨਚੇਤੀ OOM ਕਿਲਰ ਜੋ PostgreSQL ਨੂੰ ਕਰੈਸ਼ ਕਰਦਾ ਹੈ, ਅਣਸੁਖਾਵਾਂ ਹੈ। ਹਰ ਕੋਈ, ਆਖਰੀ ਉਪਭੋਗਤਾ ਤੱਕ, ਇਸ ਬਾਰੇ ਜਾਣਦਾ ਹੋਵੇਗਾ।
ਕੀ ਹੋ ਰਿਹਾ ਹੈ? ਤੁਹਾਡੇ ਕੋਲ ਉੱਥੇ RAM ਦੀ ਇੱਕ ਵੱਡੀ ਮਾਤਰਾ ਹੈ, ਸਭ ਕੁਝ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ। ਪਰ ਕਿਸੇ ਕਾਰਨ ਸਰਵਰ ਸਵੈਪ ਵਿੱਚ ਹੈਂਗ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਸ ਕਾਰਨ ਹੌਲੀ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਲਗਦਾ ਹੈ ਕਿ ਬਹੁਤ ਸਾਰੀ ਯਾਦਾਸ਼ਤ ਹੈ, ਪਰ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ.
ਪਹਿਲਾਂ, ਅਸੀਂ vm.swappiness ਨੂੰ ਜ਼ੀਰੋ 'ਤੇ ਸੈੱਟ ਕਰਨ ਦੀ ਸਲਾਹ ਦਿੱਤੀ ਸੀ, ਯਾਨੀ ਸਵੈਪ ਨੂੰ ਅਯੋਗ ਕਰਨਾ। ਪਹਿਲਾਂ, ਇਹ ਜਾਪਦਾ ਸੀ ਕਿ 32 GB RAM ਅਤੇ ਅਨੁਸਾਰੀ ਸ਼ੇਅਰ ਬਫਰ ਇੱਕ ਵੱਡੀ ਰਕਮ ਸੀ. ਸਵੈਪ ਦਾ ਮੁੱਖ ਉਦੇਸ਼ ਇਹ ਹੈ ਕਿ ਜੇ ਅਸੀਂ ਡਿੱਗਦੇ ਹਾਂ ਤਾਂ ਛਾਲੇ ਨੂੰ ਸੁੱਟਣ ਲਈ ਜਗ੍ਹਾ ਹੋਵੇ। ਅਤੇ ਇਹ ਹੁਣ ਖਾਸ ਤੌਰ 'ਤੇ ਪੂਰਾ ਨਹੀਂ ਹੋਇਆ ਸੀ. ਅਤੇ ਫਿਰ ਤੁਸੀਂ ਇਸ ਛਾਲੇ ਨਾਲ ਕੀ ਕਰਨ ਜਾ ਰਹੇ ਹੋ? ਇਹ ਇੱਕ ਅਜਿਹਾ ਕੰਮ ਹੈ ਜਿੱਥੇ ਇਹ ਬਹੁਤ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ ਕਿ ਸਵੈਪ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ, ਖਾਸ ਕਰਕੇ ਅਜਿਹੇ ਆਕਾਰ ਦੀ।
ਪਰ ਵਧੇਰੇ ਆਧੁਨਿਕ, ਭਾਵ, ਕਰਨਲ ਦੇ ਤੀਜੇ ਸੰਸਕਰਣ ਵਿੱਚ, ਵਿਹਾਰ ਬਦਲ ਗਿਆ ਹੈ। ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਸਵੈਪ ਨੂੰ ਜ਼ੀਰੋ 'ਤੇ ਸੈੱਟ ਕਰਦੇ ਹੋ, ਭਾਵ ਇਸਨੂੰ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਜਲਦੀ ਜਾਂ ਬਾਅਦ ਵਿੱਚ, ਭਾਵੇਂ ਕਿ ਕੁਝ ਰੈਮ ਬਚੀ ਹੈ, ਇੱਕ OOM ਕਿਲਰ ਤੁਹਾਡੇ ਕੋਲ ਸਭ ਤੋਂ ਤੀਬਰ ਖਪਤਕਾਰਾਂ ਨੂੰ ਮਾਰਨ ਲਈ ਆਵੇਗਾ। ਕਿਉਂਕਿ ਉਹ ਵਿਚਾਰ ਕਰੇਗਾ ਕਿ ਅਜਿਹੇ ਕੰਮ ਦੇ ਬੋਝ ਦੇ ਨਾਲ ਸਾਡੇ ਕੋਲ ਅਜੇ ਵੀ ਥੋੜਾ ਜਿਹਾ ਬਚਿਆ ਹੈ ਅਤੇ ਅਸੀਂ ਬਾਹਰ ਛਾਲ ਮਾਰਾਂਗੇ, ਅਰਥਾਤ, ਸਿਸਟਮ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਨੱਥ ਪਾਉਣ ਲਈ ਨਹੀਂ, ਪਰ ਕਿਸੇ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ। ਇਹ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਸ਼ੇਅਰਡ ਮੈਮੋਰੀ ਦਾ ਤੀਬਰ ਖਪਤਕਾਰ ਹੋਵੇਗਾ, ਅਰਥਾਤ ਪੋਸਟਮਾਸਟਰ। ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਇਹ ਚੰਗਾ ਹੋਵੇਗਾ ਜੇਕਰ ਅਧਾਰ ਨੂੰ ਬਹਾਲ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ.
ਇਸ ਲਈ, ਹੁਣ ਡਿਫਾਲਟ, ਜਿੱਥੋਂ ਤੱਕ ਮੈਨੂੰ ਯਾਦ ਹੈ, ਜ਼ਿਆਦਾਤਰ ਡਿਸਟਰੀਬਿਊਸ਼ਨ 6 ਦੇ ਆਸ-ਪਾਸ ਹਨ, ਯਾਨੀ ਕਿ ਕਿੰਨੀ ਮੈਮੋਰੀ ਬਚੀ ਹੈ, ਇਸ ਦੇ ਆਧਾਰ 'ਤੇ ਤੁਹਾਨੂੰ ਸਵੈਪ ਦੀ ਵਰਤੋਂ ਕਿਸ ਬਿੰਦੂ 'ਤੇ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਅਸੀਂ ਹੁਣ vm.swappiness = 1 ਨੂੰ ਸੈੱਟ ਕਰਨ ਦੀ ਸਿਫ਼ਾਰਿਸ਼ ਕਰਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਇਹ ਅਮਲੀ ਤੌਰ 'ਤੇ ਇਸਨੂੰ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਪਰ ਓਓਐਮ-ਕਿਲਰ ਵਾਂਗ ਉਹੀ ਪ੍ਰਭਾਵ ਨਹੀਂ ਦਿੰਦਾ ਜੋ ਅਚਾਨਕ ਆ ਗਿਆ ਅਤੇ ਪੂਰੀ ਚੀਜ਼ ਨੂੰ ਮਾਰ ਦਿੱਤਾ।
ਅੱਗੇ ਕੀ ਹੈ? ਜਦੋਂ ਅਸੀਂ ਡਾਟਾਬੇਸ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ ਅਤੇ ਹੌਲੀ-ਹੌਲੀ ਡਿਸਕ ਵੱਲ ਵਧਦੇ ਹਾਂ, ਤਾਂ ਹਰ ਕੋਈ ਆਪਣਾ ਸਿਰ ਫੜਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ. ਕਿਉਂਕਿ ਇਹ ਸੱਚਾਈ ਕਿ ਡਿਸਕ ਹੌਲੀ ਹੈ ਅਤੇ ਯਾਦਦਾਸ਼ਤ ਤੇਜ਼ ਹੈ, ਬਚਪਨ ਤੋਂ ਹਰ ਕੋਈ ਜਾਣੂ ਹੈ. ਅਤੇ ਹਰ ਕੋਈ ਜਾਣਦਾ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਵਿੱਚ ਡਿਸਕ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਹੋਣਗੀਆਂ.
ਚੈਕਪੁਆਇੰਟ ਸਪਾਈਕ ਨਾਲ ਸੰਬੰਧਿਤ ਮੁੱਖ PostgreSQL ਕਾਰਜਕੁਸ਼ਲਤਾ ਸਮੱਸਿਆ ਪੈਦਾ ਨਹੀਂ ਹੁੰਦੀ ਕਿਉਂਕਿ ਡਿਸਕ ਹੌਲੀ ਹੈ। ਇਹ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਹੈ ਕਿ ਮੈਮੋਰੀ ਅਤੇ ਡਿਸਕ ਬੈਂਡਵਿਡਥ ਸੰਤੁਲਿਤ ਨਹੀਂ ਹਨ। ਹਾਲਾਂਕਿ, ਉਹ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ 'ਤੇ ਸੰਤੁਲਿਤ ਨਹੀਂ ਹੋ ਸਕਦੇ ਹਨ। PostgreSQL ਕੌਂਫਿਗਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ, OS ਕੌਂਫਿਗਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ, ਹਾਰਡਵੇਅਰ ਕੌਂਫਿਗਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਅਤੇ ਹਾਰਡਵੇਅਰ ਗਲਤ ਹੈ। ਅਤੇ ਇਹ ਸਮੱਸਿਆ ਉਦੋਂ ਨਹੀਂ ਵਾਪਰਦੀ ਜਦੋਂ ਸਭ ਕੁਝ ਉਸੇ ਤਰ੍ਹਾਂ ਵਾਪਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਭਾਵ ਜਾਂ ਤਾਂ ਕੋਈ ਲੋਡ ਨਹੀਂ ਹੈ, ਜਾਂ ਸੈਟਿੰਗਾਂ ਅਤੇ ਹਾਰਡਵੇਅਰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਚੁਣੇ ਗਏ ਹਨ।
ਇਹ ਕੀ ਹੈ ਅਤੇ ਇਹ ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ? ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਲੋਕ ਜੋ PostgreSQL ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ, ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰ ਦਾਖਲ ਹੋਏ ਹਨ। ਮੈਂ ਸਮਝਾਵਾਂਗਾ। ਜਿਵੇਂ ਕਿ ਮੈਂ ਕਿਹਾ, PostgreSQL ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਗੰਦੇ ਪੰਨਿਆਂ ਨੂੰ ਸ਼ੇਅਰਡ ਮੈਮੋਰੀ ਵਿੱਚ ਡਿਸਕ ਵਿੱਚ ਡੰਪ ਕਰਨ ਲਈ ਚੈਕਪੁਆਇੰਟ ਬਣਾਉਂਦਾ ਹੈ। ਜੇ ਸਾਡੇ ਕੋਲ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਸਾਂਝੀ ਕੀਤੀ ਮੈਮੋਰੀ ਹੈ, ਤਾਂ ਚੈਕਪੁਆਇੰਟ ਡਿਸਕ 'ਤੇ ਗਹਿਰਾ ਪ੍ਰਭਾਵ ਪਾਉਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਇਹਨਾਂ ਪੰਨਿਆਂ ਨੂੰ fsync ਨਾਲ ਡੰਪ ਕਰਦਾ ਹੈ। ਇਹ ਕਰਨਲ ਬਫਰ ਵਿੱਚ ਆਉਂਦਾ ਹੈ ਅਤੇ fsync ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਡਿਸਕਾਂ ਉੱਤੇ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਜੇਕਰ ਇਸ ਕਾਰੋਬਾਰ ਦੀ ਮਾਤਰਾ ਵੱਡੀ ਹੈ, ਤਾਂ ਅਸੀਂ ਇੱਕ ਕੋਝਾ ਪ੍ਰਭਾਵ ਦੇਖ ਸਕਦੇ ਹਾਂ, ਅਰਥਾਤ ਡਿਸਕਾਂ ਦੀ ਇੱਕ ਬਹੁਤ ਵੱਡੀ ਵਰਤੋਂ.
ਇੱਥੇ ਮੇਰੇ ਕੋਲ ਦੋ ਤਸਵੀਰਾਂ ਹਨ. ਮੈਂ ਹੁਣ ਦੱਸਾਂਗਾ ਕਿ ਇਹ ਕੀ ਹੈ। ਇਹ ਦੋ ਸਮੇਂ-ਸਬੰਧਿਤ ਗ੍ਰਾਫ ਹਨ। ਪਹਿਲਾ ਗ੍ਰਾਫ ਡਿਸਕ ਉਪਯੋਗਤਾ ਹੈ। ਇੱਥੇ ਇਹ ਸਮੇਂ ਵਿੱਚ ਇਸ ਸਮੇਂ ਲਗਭਗ 90% ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਭੌਤਿਕ ਡਿਸਕਾਂ ਦੇ ਨਾਲ ਇੱਕ ਡਾਟਾਬੇਸ ਅਸਫਲਤਾ ਹੈ, ਇੱਕ RAID ਕੰਟਰੋਲਰ ਉਪਯੋਗਤਾ ਦੇ ਨਾਲ 90%, ਤਾਂ ਇਹ ਬੁਰੀ ਖ਼ਬਰ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਥੋੜਾ ਹੋਰ ਅਤੇ ਇਹ 100 ਤੱਕ ਪਹੁੰਚ ਜਾਵੇਗਾ ਅਤੇ I/O ਬੰਦ ਹੋ ਜਾਵੇਗਾ।
ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਡਿਸਕ ਐਰੇ ਹੈ, ਤਾਂ ਇਹ ਥੋੜੀ ਵੱਖਰੀ ਕਹਾਣੀ ਹੈ। ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਕਿਵੇਂ ਸੰਰਚਿਤ ਹੈ, ਇਹ ਕਿਸ ਕਿਸਮ ਦੀ ਐਰੇ ਹੈ, ਆਦਿ।
ਅਤੇ ਸਮਾਨਾਂਤਰ ਵਿੱਚ, ਅੰਦਰੂਨੀ ਪੋਸਟਗ੍ਰੇਸ ਦ੍ਰਿਸ਼ ਤੋਂ ਇੱਕ ਗ੍ਰਾਫ਼ ਇੱਥੇ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਚੈਕਪੁਆਇੰਟ ਕਿਵੇਂ ਵਾਪਰਦਾ ਹੈ। ਅਤੇ ਇੱਥੇ ਹਰਾ ਰੰਗ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕਿੰਨੇ ਬਫਰ, ਇਹ ਗੰਦੇ ਪੰਨੇ, ਉਸ ਸਮੇਂ ਸਮਕਾਲੀਕਰਨ ਲਈ ਇਸ ਚੈਕਪੁਆਇੰਟ 'ਤੇ ਪਹੁੰਚੇ। ਅਤੇ ਇਹ ਮੁੱਖ ਚੀਜ਼ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਇੱਥੇ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਕੋਲ ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਪੰਨੇ ਹਨ ਅਤੇ ਕਿਸੇ ਸਮੇਂ ਅਸੀਂ ਬੋਰਡ ਨੂੰ ਮਾਰਦੇ ਹਾਂ, ਯਾਨੀ ਅਸੀਂ ਲਿਖਿਆ ਅਤੇ ਲਿਖਿਆ, ਇੱਥੇ ਡਿਸਕ ਸਿਸਟਮ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਬਹੁਤ ਵਿਅਸਤ ਹੈ। ਅਤੇ ਸਾਡੇ ਚੈਕਪੁਆਇੰਟ ਦਾ ਡਿਸਕ 'ਤੇ ਬਹੁਤ ਮਜ਼ਬੂਤ ਪ੍ਰਭਾਵ ਹੈ. ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ, ਸਥਿਤੀ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ, ਯਾਨੀ ਸਾਡੇ ਕੋਲ ਇੱਥੇ ਘੱਟ ਰਿਕਾਰਡਿੰਗ ਸੀ। ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਸੈਟਿੰਗਾਂ ਦੇ ਨਾਲ ਠੀਕ ਕਰ ਸਕਦੇ ਹਾਂ ਤਾਂ ਜੋ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੁੰਦਾ ਰਹੇ। ਯਾਨੀ ਰੀਸਾਈਕਲਿੰਗ ਛੋਟੀ ਹੈ, ਪਰ ਕਿਤੇ ਨਾ ਕਿਤੇ ਅਸੀਂ ਇੱਥੇ ਕੁਝ ਲਿਖ ਰਹੇ ਹਾਂ।
ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਦੂਰ ਕਰਨ ਲਈ ਕੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ? ਜੇ ਤੁਸੀਂ ਡਾਟਾਬੇਸ ਦੇ ਅਧੀਨ IO ਨੂੰ ਰੋਕ ਦਿੱਤਾ ਹੈ, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਹ ਸਾਰੇ ਉਪਭੋਗਤਾ ਜੋ ਉਹਨਾਂ ਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਆਏ ਸਨ, ਉਡੀਕ ਕਰਨਗੇ.
ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਦੇਖਦੇ ਹੋ Linuxਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਚੰਗਾ ਹਾਰਡਵੇਅਰ ਹੈ, ਇਸਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕੀਤਾ ਹੈ, PostgreSQL ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕੀਤਾ ਹੈ ਤਾਂ ਜੋ ਇਹ ਇਹਨਾਂ ਚੈਕਪੁਆਇੰਟਾਂ ਨੂੰ ਘੱਟ ਵਾਰ ਬਣਾ ਸਕੇ, ਉਹਨਾਂ ਨੂੰ ਸਮੇਂ ਦੇ ਨਾਲ ਫੈਲਾ ਸਕੇ, ਤਾਂ ਤੁਸੀਂ ਡਿਫਾਲਟ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਪੂਰਾ ਕਰ ਰਹੇ ਹੋ। Debianਜ਼ਿਆਦਾਤਰ ਵੰਡਾਂ ਲਈ Linux ਇਹ ਤਸਵੀਰ ਹੈ: vm.dirty_ratio=20, vm.dirty_background_ratio=10।
ਇਸਦਾ ਮਤਲੱਬ ਕੀ ਹੈ? ਕਰਨਲ 2.6 ਤੋਂ ਇੱਕ ਫਲੱਸ਼ਿੰਗ ਡੈਮਨ ਪ੍ਰਗਟ ਹੋਇਆ। Pdglush, ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਕੌਣ ਕਿਸ ਦੀ ਵਰਤੋਂ ਕਰ ਰਿਹਾ ਹੈ, ਜੋ ਕਿ ਕਰਨਲ ਬਫਰ ਤੋਂ ਗੰਦੇ ਪੰਨਿਆਂ ਨੂੰ ਬੈਕਗ੍ਰਾਉਂਡ ਰੱਦ ਕਰਨ ਵਿੱਚ ਰੁੱਝਿਆ ਹੋਇਆ ਹੈ ਅਤੇ ਜਦੋਂ ਗੰਦੇ ਪੰਨਿਆਂ ਨੂੰ ਰੱਦ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ, ਭਾਵੇਂ ਕੋਈ ਵੀ ਹੋਵੇ, ਜਦੋਂ ਬੈਕਗ੍ਰਾਉਂਡ ਰੱਦ ਕਰਨਾ ਮਦਦ ਨਹੀਂ ਕਰਦਾ ਹੈ।
ਪਿਛੋਕੜ ਕਦੋਂ ਆਉਂਦਾ ਹੈ? ਜਦੋਂ ਸਰਵਰ 'ਤੇ ਉਪਲਬਧ ਕੁੱਲ RAM ਦਾ 10% ਕਰਨਲ ਬਫਰ ਵਿੱਚ ਗੰਦੇ ਪੰਨਿਆਂ ਦੁਆਰਾ ਕਬਜ਼ਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਬੈਕਗ੍ਰਾਉਂਡ ਵਿੱਚ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਰਾਈਟ-ਆਫ ਫੰਕਸ਼ਨ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਪਿਛੋਕੜ ਕਿਉਂ ਹੈ? ਪੈਰਾਮੀਟਰ ਦੇ ਰੂਪ ਵਿੱਚ, ਇਹ ਇਸ ਗੱਲ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦਾ ਹੈ ਕਿ ਕਿੰਨੇ ਪੰਨਿਆਂ ਨੂੰ ਲਿਖਣਾ ਹੈ। ਅਤੇ, ਮੰਨ ਲਓ, ਉਹ N ਪੰਨਿਆਂ ਨੂੰ ਲਿਖਦਾ ਹੈ. ਅਤੇ ਕੁਝ ਸਮੇਂ ਲਈ ਇਹ ਚੀਜ਼ ਸੌਂ ਜਾਂਦੀ ਹੈ. ਅਤੇ ਫਿਰ ਉਹ ਦੁਬਾਰਾ ਆਉਂਦੀ ਹੈ ਅਤੇ ਕੁਝ ਹੋਰ ਪੰਨਿਆਂ ਦੀ ਨਕਲ ਕਰਦੀ ਹੈ.
ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਕਹਾਣੀ ਹੈ. ਇੱਥੇ ਸਮੱਸਿਆ ਇੱਕ ਸਵੀਮਿੰਗ ਪੂਲ ਵਰਗੀ ਹੈ, ਜਦੋਂ ਇਹ ਇੱਕ ਪਾਈਪ ਵਿੱਚ ਡੋਲ੍ਹਦਾ ਹੈ, ਇਹ ਦੂਜੇ ਵਿੱਚ ਵਹਿ ਜਾਂਦਾ ਹੈ। ਸਾਡਾ ਚੈਕਪੁਆਇੰਟ ਆ ਗਿਆ ਹੈ ਅਤੇ ਜੇਕਰ ਇਸ ਨੇ ਕੁਝ ਗੰਦੇ ਪੰਨੇ ਰੱਦ ਕਰਨ ਲਈ ਭੇਜੇ ਹਨ, ਤਾਂ ਹੌਲੀ-ਹੌਲੀ ਸਾਰੀ ਚੀਜ਼ ਨੂੰ ਕਰਨਲ ਬਫਰ pgflush ਤੋਂ ਸਾਫ਼-ਸੁਥਰਾ ਹੱਲ ਕੀਤਾ ਜਾਵੇਗਾ।
ਜੇਕਰ ਇਹ ਗੰਦੇ ਪੰਨੇ ਇਕੱਠੇ ਹੁੰਦੇ ਰਹਿੰਦੇ ਹਨ, ਤਾਂ ਉਹ 20% ਤੱਕ ਇਕੱਠੇ ਹੁੰਦੇ ਹਨ, ਜਿਸ ਤੋਂ ਬਾਅਦ OS ਦੀ ਤਰਜੀਹ ਸਾਰੀ ਚੀਜ਼ ਨੂੰ ਡਿਸਕ 'ਤੇ ਲਿਖਣਾ ਹੈ, ਕਿਉਂਕਿ ਪਾਵਰ ਫੇਲ ਹੋ ਜਾਵੇਗੀ ਅਤੇ ਸਾਡੇ ਲਈ ਸਭ ਕੁਝ ਬੁਰਾ ਹੋਵੇਗਾ। ਅਸੀਂ ਇਸ ਡੇਟਾ ਨੂੰ ਗੁਆ ਦੇਵਾਂਗੇ, ਉਦਾਹਰਨ ਲਈ।
ਚਾਲ ਕੀ ਹੈ? ਚਾਲ ਇਹ ਹੈ ਕਿ ਆਧੁਨਿਕ ਸੰਸਾਰ ਵਿੱਚ ਇਹ ਮਾਪਦੰਡ ਮਸ਼ੀਨ ਦੀ ਕੁੱਲ RAM ਦਾ 20 ਅਤੇ 10% ਹਨ, ਉਹ ਤੁਹਾਡੇ ਕੋਲ ਮੌਜੂਦ ਕਿਸੇ ਵੀ ਡਿਸਕ ਸਿਸਟਮ ਦੇ ਥ੍ਰਰੂਪੁਟ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਬਿਲਕੁਲ ਭਿਆਨਕ ਹਨ।
ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ 128 GB RAM ਹੈ। 12,8 GB ਤੁਹਾਡੇ ਡਿਸਕ ਸਿਸਟਮ ਵਿੱਚ ਆਉਂਦਾ ਹੈ। ਅਤੇ ਇਸ ਗੱਲ ਦਾ ਕੋਈ ਫ਼ਰਕ ਨਹੀਂ ਪੈਂਦਾ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਉੱਥੇ ਕੀ ਕੈਸ਼ ਹੈ, ਭਾਵੇਂ ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਵੀ ਐਰੇ ਹੈ, ਉਹ ਇੰਨੇ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਨਹੀਂ ਰਹਿਣਗੇ।
ਇਸ ਲਈ, ਅਸੀਂ ਸਿਫ਼ਾਰਿਸ਼ ਕਰਦੇ ਹਾਂ ਕਿ ਤੁਸੀਂ ਆਪਣੇ RAID ਕੰਟਰੋਲਰ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਇਹਨਾਂ ਨੰਬਰਾਂ ਨੂੰ ਤੁਰੰਤ ਅਨੁਕੂਲਿਤ ਕਰੋ। ਮੈਂ ਤੁਰੰਤ ਇੱਥੇ ਇੱਕ ਕੰਟਰੋਲਰ ਲਈ ਇੱਕ ਸਿਫ਼ਾਰਿਸ਼ ਕੀਤੀ ਜਿਸ ਵਿੱਚ 512 MB ਕੈਸ਼ ਹੈ।
ਹਰ ਚੀਜ਼ ਨੂੰ ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਮੰਨਿਆ ਗਿਆ ਹੈ. ਤੁਸੀਂ vm.dirty_background ਨੂੰ ਬਾਈਟਾਂ ਵਿੱਚ ਪਾ ਸਕਦੇ ਹੋ। ਅਤੇ ਇਹ ਸੈਟਿੰਗਾਂ ਪਿਛਲੇ ਦੋ ਨੂੰ ਰੱਦ ਕਰਦੀਆਂ ਹਨ। ਜਾਂ ਤਾਂ ਅਨੁਪਾਤ ਪੂਰਵ-ਨਿਰਧਾਰਤ ਤੌਰ 'ਤੇ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਬਾਈਟਸ ਵਾਲੇ ਐਕਟੀਵੇਟ ਹੁੰਦੇ ਹਨ, ਫਿਰ ਬਾਈਟਸ ਵਾਲੇ ਕੰਮ ਕਰਨਗੇ। ਪਰ ਕਿਉਂਕਿ ਮੈਂ ਇੱਕ ਡੀਬੀਏ ਸਲਾਹਕਾਰ ਹਾਂ ਅਤੇ ਵੱਖ-ਵੱਖ ਗਾਹਕਾਂ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹਾਂ, ਮੈਂ ਸਟ੍ਰਾ ਨੂੰ ਖਿੱਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹਾਂ ਅਤੇ ਇਸਲਈ, ਜੇ ਬਾਈਟ ਵਿੱਚ, ਤਾਂ ਬਾਈਟਸ ਵਿੱਚ. ਕਿਸੇ ਨੇ ਕੋਈ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੱਤੀ ਕਿ ਇੱਕ ਚੰਗਾ ਐਡਮਿਨ ਸਰਵਰ ਵਿੱਚ ਹੋਰ ਮੈਮੋਰੀ ਨਹੀਂ ਜੋੜੇਗਾ, ਇਸਨੂੰ ਰੀਬੂਟ ਕਰੇਗਾ, ਅਤੇ ਅੰਕੜਾ ਉਹੀ ਰਹੇਗਾ। ਬਸ ਇਹਨਾਂ ਸੰਖਿਆਵਾਂ ਦੀ ਗਣਨਾ ਕਰੋ ਤਾਂ ਕਿ ਹਰ ਚੀਜ਼ ਉੱਥੇ ਗਾਰੰਟੀ ਦੇ ਨਾਲ ਫਿੱਟ ਹੋਵੇ।
ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ? ਮੈਂ ਲਿਖਿਆ ਹੈ ਕਿ ਕਿਸੇ ਵੀ ਫਲੱਸ਼ਿੰਗ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਅਸਲ ਵਿੱਚ ਇਹ ਭਾਸ਼ਣ ਦਾ ਇੱਕ ਚਿੱਤਰ ਹੈ. ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਵਿੱਚ ਇੱਕ ਵੱਡੀ ਸਮੱਸਿਆ ਹੈ - ਇਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਗੰਦੇ ਪੰਨੇ ਹਨ, ਇਸਲਈ ਤੁਹਾਡੇ ਕਲਾਇੰਟਸ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਗਏ IO ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਰੋਕ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਯਾਨੀ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਡੇਟਾਬੇਸ ਨੂੰ ਇੱਕ sql ਪੁੱਛਗਿੱਛ ਭੇਜਣ ਲਈ ਆਈ ਹੈ, ਇਹ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ. ਇਸ ਵਿੱਚ ਕੋਈ ਵੀ ਇਨਪੁਟ/ਆਉਟਪੁੱਟ ਸਭ ਤੋਂ ਘੱਟ ਤਰਜੀਹ ਹੈ, ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਇੱਕ ਚੈਕਪੁਆਇੰਟ ਦੁਆਰਾ ਰੱਖਿਆ ਗਿਆ ਹੈ। ਅਤੇ ਉਹ ਕਦੋਂ ਖਤਮ ਕਰੇਗੀ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸਪਸ਼ਟ ਹੈ। ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਗੈਰ-ਬੈਕਗ੍ਰਾਉਂਡ ਫਲੱਸ਼ਿੰਗ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੇ ਸਾਰੇ IO ਦਾ ਕਬਜ਼ਾ ਹੈ. ਅਤੇ ਜਦੋਂ ਤੱਕ ਇਹ ਖਤਮ ਨਹੀਂ ਹੁੰਦਾ, ਤੁਸੀਂ ਕੁਝ ਨਹੀਂ ਕਰੋਗੇ.
ਇੱਥੇ ਦੋ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਨੁਕਤੇ ਹਨ ਜੋ ਇਸ ਰਿਪੋਰਟ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹਨ। ਇਹ ਸੈਟਿੰਗਾਂ postgresql.conf ਵਿੱਚ ਸੈਟਿੰਗਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਚੈੱਕਪੁਆਇੰਟ ਸੈਟਿੰਗਜ਼। ਅਤੇ ਤੁਹਾਡੇ ਡਿਸਕ ਸਿਸਟਮ ਨੂੰ ਉਚਿਤ ਰੂਪ ਵਿੱਚ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ. ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ RAID 'ਤੇ ਕੈਸ਼ ਹੈ, ਤਾਂ ਇਸ ਵਿੱਚ ਇੱਕ ਬੈਟਰੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਲੋਕ ਬਿਨਾਂ ਬੈਟਰੀ ਦੇ ਚੰਗੇ ਕੈਸ਼ ਨਾਲ ਰੇਡ ਖਰੀਦਦੇ ਹਨ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ RAID ਵਿੱਚ SSDs ਹਨ, ਤਾਂ ਉਹ ਸਰਵਰ ਵਾਲੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਉੱਥੇ ਕੈਪੇਸੀਟਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਇੱਥੇ ਇੱਕ ਵਿਸਤ੍ਰਿਤ ਚੈਕਲਿਸਟ ਹੈ। ਇਸ ਲਿੰਕ ਵਿੱਚ ਮੇਰੀ ਰਿਪੋਰਟ ਹੈ ਕਿ PostgreSQL ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਡਿਸਕ ਨੂੰ ਕਿਵੇਂ ਸੰਰਚਿਤ ਕਰਨਾ ਹੈ। ਉੱਥੇ ਇਹ ਸਾਰੀਆਂ ਚੈਕਲਿਸਟਾਂ ਹਨ.
ਹੋਰ ਕਿਹੜੀ ਚੀਜ਼ ਜ਼ਿੰਦਗੀ ਨੂੰ ਬਹੁਤ ਮੁਸ਼ਕਲ ਬਣਾ ਸਕਦੀ ਹੈ? ਇਹ ਦੋ ਪੈਰਾਮੀਟਰ ਹਨ। ਉਹ ਮੁਕਾਬਲਤਨ ਨਵੇਂ ਹਨ। ਮੂਲ ਰੂਪ ਵਿੱਚ, ਉਹਨਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਅਤੇ ਉਹ ਜ਼ਿੰਦਗੀ ਨੂੰ ਓਨਾ ਹੀ ਮੁਸ਼ਕਲ ਬਣਾ ਸਕਦੇ ਹਨ ਜੇਕਰ ਉਹ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਚਾਲੂ ਹੋ ਜਾਂਦੇ ਹਨ।
ਦੋ ਮੁਕਾਬਲਤਨ ਨਵੀਆਂ ਚੀਜ਼ਾਂ ਹਨ. ਉਹ ਪਹਿਲਾਂ ਹੀ ਤੀਜੇ ਕੋਰ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਏ ਹਨ. ਇਹ ਨੈਨੋ ਸਕਿੰਟਾਂ ਵਿੱਚ sched_migration_cost ਹੈ ਅਤੇ sched_autogroup_enabled, ਜੋ ਕਿ ਮੂਲ ਰੂਪ ਵਿੱਚ ਇੱਕ ਹੈ।
ਅਤੇ ਉਹ ਜ਼ਿੰਦਗੀਆਂ ਕਿਵੇਂ ਬਰਬਾਦ ਕਰਦੇ ਹਨ? sched_migration_cost ਕੀ ਹੈ? Linux ਸ਼ਡਿਊਲਰ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਇੱਕ CPU ਤੋਂ ਦੂਜੇ CPU ਵਿੱਚ ਮਾਈਗ੍ਰੇਟ ਕਰ ਸਕਦਾ ਹੈ। ਅਤੇ PostgreSQL ਲਈ, ਜੋ ਕਿ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ, ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸਪਸ਼ਟ ਹੈ ਕਿ ਇਸਨੂੰ ਦੂਜੇ CPU ਵਿੱਚ ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਕਿਉਂ ਪਵੇਗੀ। ਇੱਕ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਜਦੋਂ ਤੁਸੀਂ ਓਪਨਆਫਿਸ ਅਤੇ ਟਰਮੀਨਲ ਵਿਚਕਾਰ ਵਿੰਡੋਜ਼ ਨੂੰ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਇਹ ਠੀਕ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇੱਕ ਡੇਟਾਬੇਸ ਲਈ ਇਹ ਬਹੁਤ ਮਾੜਾ ਹੈ। ਇਸਲਈ, ਇੱਕ ਵਾਜਬ ਨੀਤੀ ਹੈ ਮਾਈਗ੍ਰੇਸ਼ਨ_ਕੋਸਟ ਨੂੰ ਕੁਝ ਵੱਡੇ ਮੁੱਲ, ਘੱਟੋ-ਘੱਟ ਕਈ ਹਜ਼ਾਰ ਨੈਨੋਸਕਿੰਡ ਵਿੱਚ ਸੈੱਟ ਕਰਨਾ।
ਸ਼ਡਿਊਲਰ ਲਈ ਇਸਦਾ ਕੀ ਅਰਥ ਹੋਵੇਗਾ? ਇਹ ਮੰਨਿਆ ਜਾਵੇਗਾ ਕਿ ਇਸ ਸਮੇਂ ਦੌਰਾਨ ਪ੍ਰਕਿਰਿਆ ਅਜੇ ਵੀ ਗਰਮ ਹੈ. ਭਾਵ, ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਚੱਲ ਰਿਹਾ ਲੈਣ-ਦੇਣ ਹੈ ਜੋ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਕੁਝ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਸ਼ਡਿਊਲਰ ਇਸ ਨੂੰ ਸਮਝੇਗਾ। ਉਹ ਇਹ ਮੰਨ ਲਵੇਗਾ ਕਿ ਜਦੋਂ ਤੱਕ ਇਹ ਸਮਾਂ ਸਮਾਪਤ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਕਿਤੇ ਵੀ ਮਾਈਗਰੇਟ ਕਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ। ਜੇ ਉਸੇ ਸਮੇਂ ਪ੍ਰਕਿਰਿਆ ਕੁਝ ਕਰਦੀ ਹੈ, ਤਾਂ ਇਹ ਕਿਤੇ ਵੀ ਮਾਈਗਰੇਟ ਨਹੀਂ ਕੀਤੀ ਜਾਵੇਗੀ, ਇਹ ਚੁੱਪਚਾਪ ਉਸ CPU 'ਤੇ ਕੰਮ ਕਰੇਗੀ ਜੋ ਇਸ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਅਤੇ ਨਤੀਜਾ ਸ਼ਾਨਦਾਰ ਹੈ.
ਦੂਜਾ ਬਿੰਦੂ ਆਟੋਗਰੁੱਪ ਹੈ। ਖਾਸ ਵਰਕਲੋਡਾਂ ਲਈ ਇੱਕ ਚੰਗਾ ਵਿਚਾਰ ਹੈ ਜੋ ਆਧੁਨਿਕ ਡੇਟਾਬੇਸ ਨਾਲ ਸਬੰਧਤ ਨਹੀਂ ਹਨ - ਇਹ ਵਰਚੁਅਲ ਟਰਮੀਨਲ ਦੁਆਰਾ ਸਮੂਹ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਹੈ ਜਿੱਥੋਂ ਉਹ ਲਾਂਚ ਕੀਤੇ ਗਏ ਹਨ। ਇਹ ਕੁਝ ਕੰਮਾਂ ਲਈ ਸੁਵਿਧਾਜਨਕ ਹੈ। ਅਭਿਆਸ ਵਿੱਚ, PostgreSQL ਇੱਕ ਪ੍ਰੀਫੋਰਕ ਵਾਲਾ ਇੱਕ ਬਹੁ-ਪ੍ਰਕਿਰਿਆ ਸਿਸਟਮ ਹੈ ਜੋ ਇੱਕ ਸਿੰਗਲ ਟਰਮੀਨਲ ਤੋਂ ਚੱਲਦਾ ਹੈ। ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਲਾਕ ਰਾਈਟਰ, ਚੈਕਪੁਆਇੰਟ ਹੈ, ਅਤੇ ਤੁਹਾਡੀਆਂ ਸਾਰੀਆਂ ਕਲਾਇੰਟ ਬੇਨਤੀਆਂ ਨੂੰ ਇੱਕ ਅਨੁਸੂਚੀ ਵਿੱਚ, ਪ੍ਰਤੀ CPU ਵਿੱਚ ਸਮੂਹਬੱਧ ਕੀਤਾ ਜਾਵੇਗਾ। ਅਤੇ ਉਹ ਇੱਕ ਦੂਜੇ ਦੇ ਨਾਲ ਦਖਲ ਦੇਣ ਅਤੇ ਉਸਨੂੰ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਵਿਅਸਤ ਰੱਖਣ ਲਈ, ਉਸਦੇ ਆਜ਼ਾਦ ਹੋਣ ਲਈ ਇੱਕਜੁੱਟ ਹੋ ਕੇ ਉੱਥੇ ਉਡੀਕ ਕਰਨਗੇ। ਇਹ ਇੱਕ ਅਜਿਹੀ ਕਹਾਣੀ ਹੈ ਜੋ ਅਜਿਹੇ ਲੋਡ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੇਲੋੜੀ ਹੈ ਅਤੇ ਇਸ ਲਈ ਇਸਨੂੰ ਬੰਦ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
ਮੇਰੇ ਸਹਿਕਰਮੀ ਅਲੈਕਸੀ ਲੇਸੋਵਸਕੀ ਨੇ ਇੱਕ ਸਧਾਰਨ ਪੀਜੀਬੈਂਚ ਨਾਲ ਟੈਸਟ ਕੀਤੇ, ਜਿੱਥੇ ਉਸਨੇ ਮਾਈਗ੍ਰੇਸ਼ਨ_ਕਸਟ ਨੂੰ ਇੱਕ ਕ੍ਰਮ ਦੇ ਮਾਪ ਨਾਲ ਵਧਾ ਦਿੱਤਾ ਅਤੇ ਆਟੋਗਰੁੱਪ ਨੂੰ ਬੰਦ ਕਰ ਦਿੱਤਾ। ਖਰਾਬ ਹਾਰਡਵੇਅਰ 'ਤੇ ਅੰਤਰ ਲਗਭਗ 10% ਸੀ. ਪੋਸਟਗ੍ਰੇਸ ਮੇਲਿੰਗ ਲਿਸਟ 'ਤੇ ਚਰਚਾ ਹੈ ਜਿੱਥੇ ਲੋਕ ਪੁੱਛਗਿੱਛ ਦੀ ਗਤੀ ਦੇ ਸਮਾਨ ਬਦਲਾਅ ਦੇ ਨਤੀਜੇ ਦਿੰਦੇ ਹਨ 50% ਪ੍ਰਭਾਵਿਤ. ਅਜਿਹੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਕਹਾਣੀਆਂ ਹਨ।
ਅਤੇ ਅੰਤ ਵਿੱਚ, ਬਿਜਲੀ ਬਚਾਉਣ ਵਾਲੀ ਨੀਤੀ ਬਾਰੇ। ਇਹ ਚੰਗਾ ਹੈ ਕਿ ਹੁਣ Linux ਤੁਸੀਂ ਇਸਨੂੰ ਲੈਪਟਾਪ 'ਤੇ ਵਰਤ ਸਕਦੇ ਹੋ। ਅਤੇ ਇਹ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਇਹ ਬੈਟਰੀ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਖਤਮ ਕਰ ਦੇਵੇਗਾ। ਪਰ ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਸਰਵਰ 'ਤੇ ਵੀ ਇਹੀ ਚੀਜ਼ ਹੋ ਸਕਦੀ ਹੈ।
ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਹੋਸਟਿੰਗ ਪ੍ਰਦਾਤਾ ਤੋਂ ਸਰਵਰ ਕਿਰਾਏ 'ਤੇ ਲੈਂਦੇ ਹੋ, ਤਾਂ "ਚੰਗਾ" ਮੇਜ਼ਬਾਨ ਉਹਨਾਂ ਨੂੰ ਤੁਹਾਡੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦੀ ਕੋਈ ਪਰਵਾਹ ਨਹੀਂ ਹੈ। ਉਹਨਾਂ ਦਾ ਕੰਮ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਉਹਨਾਂ ਦੇ ਹਾਰਡਵੇਅਰ ਦੀ ਵਰਤੋਂ ਵੱਧ ਤੋਂ ਵੱਧ ਕੁਸ਼ਲਤਾ ਨਾਲ ਕੀਤੀ ਜਾਵੇ। ਇਸ ਲਈ ਉਹ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਵਿੱਚ ਲੈਪਟਾਪ ਵਰਗੇ ਪਾਵਰ-ਸੇਵਿੰਗ ਮੋਡ ਨੂੰ ਸਮਰੱਥ ਬਣਾ ਸਕਦੇ ਹਨ।
ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਸਮੱਗਰੀ ਨੂੰ ਸਰਵਰ 'ਤੇ ਭਾਰੀ ਬੋਝ ਹੇਠ ਇੱਕ ਡਾਟਾਬੇਸ ਨਾਲ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੀ ਪਸੰਦ acpi_cpufreq + permormance ਹੈ। ਔਨਡਿਮਾਂਡ ਨਾਲ ਵੀ ਸਮੱਸਿਆਵਾਂ ਹੋਣਗੀਆਂ।
Intel_pstate ਇੱਕ ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਡਰਾਈਵਰ ਹੈ। ਅਤੇ ਹੁਣ ਇਸ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਬਾਅਦ ਵਿੱਚ ਹੈ ਅਤੇ ਬਿਹਤਰ ਕੰਮ ਕਰਦਾ ਹੈ।
ਅਤੇ, ਇਸਦੇ ਅਨੁਸਾਰ, ਰਾਜਪਾਲ ਸਿਰਫ ਪ੍ਰਦਰਸ਼ਨ ਹੈ. ਔਨਡਿਮਾਂਡ, ਪਾਵਰਸੇਵ ਅਤੇ ਹੋਰ ਸਭ ਕੁਝ ਤੁਹਾਡੇ ਬਾਰੇ ਨਹੀਂ ਹੈ।
ਜੇਕਰ ਤੁਸੀਂ ਪਾਵਰ ਸੇਵ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਵਿਆਖਿਆ ਵਿਸ਼ਲੇਸ਼ਣ ਪੋਸਟਗਰੇਐਸਕਯੂਐਲ ਦੇ ਨਤੀਜੇ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ, ਕਿਉਂਕਿ ਵਿਹਾਰਕ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਦੇ ਅਧੀਨ CPU ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਣਪਛਾਤੇ ਤਰੀਕੇ ਨਾਲ ਚੱਲ ਰਿਹਾ ਹੋਵੇਗਾ।
ਇਹ ਆਈਟਮਾਂ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਇਹ ਦੇਖਣ ਲਈ ਧਿਆਨ ਨਾਲ ਦੇਖੋ ਕਿ ਕੀ ਉਹਨਾਂ ਨੇ ਇਸਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਚਾਲੂ ਕੀਤਾ ਹੈ। ਇਹ ਇੱਕ ਸੱਚਮੁੱਚ ਵੱਡੀ ਸਮੱਸਿਆ ਹੋ ਸਕਦੀ ਹੈ.
ਅਤੇ ਅੰਤ ਵਿੱਚ, ਮੈਂ ਸਾਡੀ PosgreSQL-ਕੰਸਲਟਿੰਗ DBA ਟੀਮ ਦੇ ਮੁੰਡਿਆਂ, ਅਰਥਾਤ ਮੈਕਸ ਬੋਗੁਕ ਅਤੇ ਅਲੈਕਸੀ ਲੇਸੋਵਸਕੀ, ਜੋ ਹਰ ਰੋਜ਼ ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਅੱਗੇ ਵੱਧ ਰਹੇ ਹਨ, ਦਾ ਧੰਨਵਾਦ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ। ਅਤੇ ਅਸੀਂ ਆਪਣੇ ਗਾਹਕਾਂ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ ਤਾਂ ਜੋ ਇਹ ਸਭ ਉਹਨਾਂ ਲਈ ਕੰਮ ਕਰੇ। ਇਹ ਹਵਾਬਾਜ਼ੀ ਸੁਰੱਖਿਆ ਨਿਰਦੇਸ਼ਾਂ ਵਾਂਗ ਹੈ। ਇੱਥੇ ਸਭ ਕੁਝ ਖੂਨ ਵਿੱਚ ਲਿਖਿਆ ਹੋਇਆ ਹੈ. ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਅਖਰੋਟ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਕਿਸੇ ਨਾ ਕਿਸੇ ਤਰ੍ਹਾਂ ਦੀ ਸਮੱਸਿਆ ਪਾਈ ਜਾਂਦੀ ਹੈ। ਮੈਂ ਉਹਨਾਂ ਨੂੰ ਤੁਹਾਡੇ ਨਾਲ ਸਾਂਝਾ ਕਰਕੇ ਖੁਸ਼ ਹਾਂ।
ਸਵਾਲ:
ਤੁਹਾਡਾ ਧੰਨਵਾਦ! ਜੇ, ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਕੰਪਨੀ ਪੈਸੇ ਦੀ ਬਚਤ ਕਰਨਾ ਚਾਹੁੰਦੀ ਹੈ ਅਤੇ ਇੱਕ ਸਰਵਰ 'ਤੇ ਡੇਟਾਬੇਸ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਤਰਕ ਰੱਖਣਾ ਚਾਹੁੰਦੀ ਹੈ, ਜਾਂ ਜੇਕਰ ਕੰਪਨੀ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ ਦੇ ਫੈਸ਼ਨੇਬਲ ਰੁਝਾਨ ਦੀ ਪਾਲਣਾ ਕਰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ PostgreSQL ਇੱਕ ਕੰਟੇਨਰ ਵਿੱਚ ਚੱਲਦਾ ਹੈ। ਚਾਲ ਕੀ ਹੈ? Sysctl ਵਿਸ਼ਵ ਪੱਧਰ 'ਤੇ ਪੂਰੇ ਕਰਨਲ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰੇਗਾ। ਮੈਂ sysctls ਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਵਰਚੁਅਲ ਹੋਣ ਬਾਰੇ ਨਹੀਂ ਸੁਣਿਆ ਹੈ ਤਾਂ ਜੋ ਉਹ ਇੱਕ ਕੰਟੇਨਰ 'ਤੇ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਨ। ਉੱਥੇ ਸਿਰਫ਼ ਇੱਕ cgroup ਹੈ ਅਤੇ ਉੱਥੇ ਸਿਰਫ਼ ਕੰਟਰੋਲ ਦਾ ਹਿੱਸਾ ਹੈ। ਤੁਸੀਂ ਇਸ ਨਾਲ ਕਿਵੇਂ ਰਹਿ ਸਕਦੇ ਹੋ? ਜਾਂ ਜੇਕਰ ਤੁਸੀਂ ਪ੍ਰਦਰਸ਼ਨ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਵੱਖਰੇ ਹਾਰਡਵੇਅਰ ਸਰਵਰ 'ਤੇ PostgreSQL ਚਲਾਓ ਅਤੇ ਇਸਨੂੰ ਟਿਊਨ ਕਰੋ?
ਅਸੀਂ ਤੁਹਾਡੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਲਗਭਗ ਤਿੰਨ ਤਰੀਕਿਆਂ ਨਾਲ ਦਿੱਤਾ ਹੈ। ਜੇ ਅਸੀਂ ਇੱਕ ਹਾਰਡਵੇਅਰ ਸਰਵਰ ਬਾਰੇ ਗੱਲ ਨਹੀਂ ਕਰ ਰਹੇ ਹਾਂ ਜਿਸ ਨੂੰ ਟਿਊਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਆਦਿ, ਤਾਂ ਆਰਾਮ ਕਰੋ, ਇਹਨਾਂ ਸੈਟਿੰਗਾਂ ਤੋਂ ਬਿਨਾਂ ਸਭ ਕੁਝ ਠੀਕ ਕੰਮ ਕਰੇਗਾ. ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਇੰਨਾ ਲੋਡ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਇਹ ਸੈਟਿੰਗਾਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਹਨਾਂ ਸੈਟਿੰਗਾਂ ਤੋਂ ਪਹਿਲਾਂ ਆਇਰਨ ਸਰਵਰ 'ਤੇ ਆ ਜਾਓਗੇ।
ਸਮੱਸਿਆ ਕੀ ਹੈ? ਜੇ ਇਹ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਹੈ, ਤਾਂ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਬਹੁਤ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹੋਣਗੀਆਂ, ਉਦਾਹਰਨ ਲਈ, ਇਸ ਤੱਥ ਦੇ ਨਾਲ ਕਿ ਜ਼ਿਆਦਾਤਰ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ 'ਤੇ ਡਿਸਕ ਦੀ ਲੇਟੈਂਸੀ ਕਾਫ਼ੀ ਅਸੰਗਤ ਹੈ. ਭਾਵੇਂ ਡਿਸਕ ਥ੍ਰਰੂਪੁਟ ਵਧੀਆ ਹੈ, ਫਿਰ ਵੀ ਇੱਕ ਅਸਫਲ I/O ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਜੋ ਚੈਕਪੁਆਇੰਟ ਦੇ ਸਮੇਂ ਜਾਂ WAL ਨੂੰ ਲਿਖਣ ਦੇ ਸਮੇਂ ਹੋਏ ਔਸਤ ਥ੍ਰੋਪੁੱਟ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਫਿਰ ਡੇਟਾਬੇਸ ਨੂੰ ਇਸ ਤੋਂ ਬਹੁਤ ਨੁਕਸਾਨ ਹੋਵੇਗਾ। ਅਤੇ ਇਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੁਸੀਂ ਇਸ ਨੂੰ ਵੇਖੋਗੇ.
ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਉਸੇ ਸਰਵਰ 'ਤੇ NGINX ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਵੀ ਇਹੀ ਸਮੱਸਿਆ ਹੋਵੇਗੀ। ਉਹ ਸਾਂਝੀ ਯਾਦ ਲਈ ਲੜੇਗਾ। ਅਤੇ ਤੁਸੀਂ ਇੱਥੇ ਦੱਸੀਆਂ ਸਮੱਸਿਆਵਾਂ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚੋਗੇ।
ਪਰ ਦੂਜੇ ਪਾਸੇ, ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਪੈਰਾਮੀਟਰ ਅਜੇ ਵੀ ਤੁਹਾਡੇ ਲਈ ਢੁਕਵੇਂ ਹੋਣਗੇ। ਉਦਾਹਰਨ ਲਈ, sysctl ਨਾਲ dirty_ratio ਸੈਟ ਕਰੋ ਤਾਂ ਜੋ ਇਹ ਇੰਨਾ ਪਾਗਲ ਨਾ ਹੋਵੇ - ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ, ਇਹ ਮਦਦ ਕਰੇਗਾ. ਇੱਕ ਤਰੀਕੇ ਨਾਲ ਜਾਂ ਕੋਈ ਹੋਰ, ਤੁਹਾਡੇ ਕੋਲ ਡਿਸਕ ਨਾਲ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਹੋਵੇਗਾ. ਅਤੇ ਇਹ ਗਲਤ ਪੈਟਰਨ ਦੇ ਅਨੁਸਾਰ ਹੋਵੇਗਾ. ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਮਾਪਦੰਡਾਂ ਲਈ ਡਿਫੌਲਟ ਹੁੰਦਾ ਹੈ ਜੋ ਮੈਂ ਦਿਖਾਇਆ ਹੈ। ਅਤੇ ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ ਬਦਲਣਾ ਬਿਹਤਰ ਹੈ.
ਪਰ NUMA ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। VmWare, ਉਦਾਹਰਨ ਲਈ, ਬਿਲਕੁਲ ਉਲਟ ਸੈਟਿੰਗਾਂ ਦੇ ਨਾਲ NUMA ਨਾਲ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ। ਅਤੇ ਇੱਥੇ ਤੁਹਾਨੂੰ ਚੋਣ ਕਰਨੀ ਪਵੇਗੀ - ਇੱਕ ਲੋਹੇ ਦਾ ਸਰਵਰ ਜਾਂ ਇੱਕ ਗੈਰ-ਲੋਹੇ ਵਾਲਾ.
ਮੇਰੇ ਕੋਲ Amazon AWS ਨਾਲ ਸਬੰਧਤ ਇੱਕ ਸਵਾਲ ਹੈ। ਉਹਨਾਂ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਸੰਰਚਿਤ ਚਿੱਤਰ ਹਨ। ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ Amazon RDS ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਕੀ ਉਹਨਾਂ ਦੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਲਈ ਕੋਈ ਕਸਟਮ ਸੈਟਿੰਗਜ਼ ਹਨ?
ਉੱਥੇ ਸੈਟਿੰਗਾਂ ਹਨ, ਪਰ ਉਹ ਵੱਖਰੀਆਂ ਸੈਟਿੰਗਾਂ ਹਨ. ਇੱਥੇ ਅਸੀਂ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਸੰਰਚਿਤ ਕਰਦੇ ਹਾਂ ਕਿ ਡੇਟਾਬੇਸ ਇਸ ਚੀਜ਼ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰੇਗਾ। ਅਤੇ ਇੱਥੇ ਪੈਰਾਮੀਟਰ ਹਨ ਜੋ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਸਾਨੂੰ ਹੁਣ ਕਿੱਥੇ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਆਕਾਰ ਦੇਣਾ। ਭਾਵ, ਸਾਨੂੰ ਬਹੁਤ ਸਾਰੇ ਸਾਧਨਾਂ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਅਸੀਂ ਹੁਣ ਉਨ੍ਹਾਂ ਨੂੰ ਖਾ ਲਵਾਂਗੇ. ਇਸ ਤੋਂ ਬਾਅਦ, ਐਮਾਜ਼ਾਨ ਆਰਡੀਐਸ ਇਹਨਾਂ ਸਰੋਤਾਂ ਨੂੰ ਤੰਗ ਕਰਦਾ ਹੈ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਉੱਥੇ ਘੱਟ ਜਾਂਦਾ ਹੈ. ਇੱਥੇ ਵਿਅਕਤੀਗਤ ਕਹਾਣੀਆਂ ਹਨ ਕਿ ਲੋਕ ਇਸ ਮਾਮਲੇ ਨਾਲ ਕਿਵੇਂ ਗੜਬੜ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹਨ। ਕਈ ਵਾਰ ਵੀ ਕਾਫ਼ੀ ਸਫਲਤਾ ਨਾਲ. ਪਰ ਇਸਦਾ OS ਸੈਟਿੰਗਾਂ ਨਾਲ ਕੋਈ ਲੈਣਾ-ਦੇਣਾ ਨਹੀਂ ਹੈ। ਇਹ ਕਲਾਉਡ ਨੂੰ ਹੈਕ ਕਰਨ ਵਰਗਾ ਹੈ। ਇਹ ਇੱਕ ਵੱਖਰੀ ਕਹਾਣੀ ਹੈ।
ਵਿਸ਼ਾਲ TLB ਦੇ ਮੁਕਾਬਲੇ ਪਾਰਦਰਸ਼ੀ ਵਿਸ਼ਾਲ ਪੰਨਿਆਂ ਦਾ ਕੋਈ ਪ੍ਰਭਾਵ ਕਿਉਂ ਨਹੀਂ ਹੁੰਦਾ?
ਨਹੀਂ ਦੇਣਾ। ਇਸ ਨੂੰ ਕਈ ਤਰੀਕਿਆਂ ਨਾਲ ਸਮਝਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਪਰ ਅਸਲ ਵਿੱਚ ਉਹ ਇਸਨੂੰ ਨਹੀਂ ਦਿੰਦੇ. PostgreSQL ਦਾ ਇਤਿਹਾਸ ਕੀ ਹੈ? ਸ਼ੁਰੂਆਤ 'ਤੇ, ਇਹ ਸ਼ੇਅਰਡ ਮੈਮੋਰੀ ਦਾ ਇੱਕ ਵੱਡਾ ਹਿੱਸਾ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਕੀ ਉਹ ਪਾਰਦਰਸ਼ੀ ਹਨ ਜਾਂ ਨਹੀਂ, ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਪ੍ਰਸੰਗਿਕ ਹੈ। ਤੱਥ ਇਹ ਹੈ ਕਿ ਉਹ ਸ਼ੁਰੂਆਤ 'ਤੇ ਬਾਹਰ ਖੜ੍ਹੇ ਹਨ ਸਭ ਕੁਝ ਦੱਸਦਾ ਹੈ. ਅਤੇ ਜੇਕਰ ਬਹੁਤ ਸਾਰੀ ਮੈਮੋਰੀ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਸ਼ੇਅਰ_ਮੈਮੋਰੀ ਹਿੱਸੇ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਪਾਰਦਰਸ਼ੀ ਵਿਸ਼ਾਲ ਪੰਨੇ ਢੁਕਵੇਂ ਹੋਣਗੇ. PostgreSQL ਵਿੱਚ, ਇਹ ਬਸ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਇੱਕ ਵੱਡੇ ਹਿੱਸੇ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਇਹ ਹੀ ਹੈ, ਅਤੇ ਫਿਰ ਉੱਥੇ ਕੁਝ ਖਾਸ ਨਹੀਂ ਹੁੰਦਾ ਹੈ. ਤੁਸੀਂ, ਬੇਸ਼ਕ, ਇਸਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਸਾਂਝੀ_ਮੈਮੋਰੀ ਦੇ ਭ੍ਰਿਸ਼ਟਾਚਾਰ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਇੱਕ ਮੌਕਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਮੁੜ-ਅਲਾਟ ਕਰਦਾ ਹੈ। PostgreSQL ਇਸ ਬਾਰੇ ਨਹੀਂ ਜਾਣਦਾ ਹੈ।
ਸਰੋਤ: www.habr.com
