PostgreSQL ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਲੀਨਕਸ ਟਿਊਨਿੰਗ। ਇਲਿਆ ਕੋਸਮੋਡੇਮੀਅਨਸਕੀ

Ilya Kosmodemyansky ਦੁਆਰਾ 2015 ਦੀ ਰਿਪੋਰਟ ਦੀ ਪ੍ਰਤੀਲਿਪੀ "PostgreSQL ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਲੀਨਕਸ ਟਿਊਨਿੰਗ"

ਬੇਦਾਅਵਾ: ਮੈਂ ਨੋਟ ਕਰਦਾ ਹਾਂ ਕਿ ਇਹ ਰਿਪੋਰਟ ਨਵੰਬਰ 2015 ਦੀ ਹੈ - 4 ਸਾਲ ਤੋਂ ਵੱਧ ਬੀਤ ਚੁੱਕੇ ਹਨ ਅਤੇ ਬਹੁਤ ਸਮਾਂ ਬੀਤ ਚੁੱਕਾ ਹੈ। ਰਿਪੋਰਟ ਵਿੱਚ ਵਿਚਾਰਿਆ ਗਿਆ ਸੰਸਕਰਣ 9.4 ਹੁਣ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ। ਪਿਛਲੇ 4 ਸਾਲਾਂ ਵਿੱਚ, PostgreSQL ਦੇ 5 ਨਵੇਂ ਰੀਲੀਜ਼ ਜਾਰੀ ਕੀਤੇ ਗਏ ਹਨ, ਅਤੇ ਲੀਨਕਸ ਕਰਨਲ ਦੇ 15 ਸੰਸਕਰਣ ਜਾਰੀ ਕੀਤੇ ਗਏ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਇਹਨਾਂ ਅੰਸ਼ਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਵੱਖਰੀ ਰਿਪੋਰਟ ਦੇ ਨਾਲ ਸਮਾਪਤ ਕਰੋਗੇ। ਪਰ ਇੱਥੇ ਅਸੀਂ PostgreSQL ਲਈ ਬੁਨਿਆਦੀ ਲੀਨਕਸ ਟਿਊਨਿੰਗ 'ਤੇ ਵਿਚਾਰ ਕਰਦੇ ਹਾਂ, ਜੋ ਕਿ ਅੱਜ ਵੀ ਢੁਕਵਾਂ ਹੈ।

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

ਅਸੀਂ ਕਿਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ? ਜੇਕਰ ਤੁਸੀਂ PostgreSQL ਨਾਲ ਸੰਚਾਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਕੁਝ ਹੱਦ ਤੱਕ ਤੁਹਾਨੂੰ UNIX ਐਡਮਿਨ ਹੋਣ ਦੀ ਲੋੜ ਹੈ। ਇਸਦਾ ਮਤਲੱਬ ਕੀ ਹੈ? ਜੇਕਰ ਅਸੀਂ Oracle ਅਤੇ PostgreSQL ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹਾਂ, ਤਾਂ Oracle ਵਿੱਚ ਤੁਹਾਨੂੰ 80% DBA ਡੇਟਾਬੇਸ ਐਡਮਿਨ ਅਤੇ 20% Linux ਐਡਮਿਨ ਹੋਣ ਦੀ ਲੋੜ ਹੈ।

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

ਅਸੀਂ ਲੀਨਕਸ ਬਾਰੇ ਕਿਉਂ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ? ਬਿਲਕੁਲ ਨਹੀਂ ਕਿਉਂਕਿ ਅਸੀਂ ਲੀਨਕਸ ਕਾਨਫਰੰਸ ਪੀਟਰ ਵਿੱਚ ਹਾਂ, ਪਰ ਕਿਉਂਕਿ ਆਧੁਨਿਕ ਸਥਿਤੀਆਂ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਡੇਟਾਬੇਸ ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ PostgreSQL ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਜਾਇਜ਼ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਵਿੱਚੋਂ ਇੱਕ ਲੀਨਕਸ ਹੈ। ਕਿਉਂਕਿ ਫ੍ਰੀਬੀਐਸਡੀ, ਬਦਕਿਸਮਤੀ ਨਾਲ, ਕੁਝ ਬਹੁਤ ਹੀ ਅਜੀਬ ਦਿਸ਼ਾ ਵਿੱਚ ਵਿਕਾਸ ਕਰ ਰਿਹਾ ਹੈ. ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਹੋਣਗੀਆਂ. ਵਿੰਡੋਜ਼ ਉੱਤੇ PostgreSQL ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਵੱਖਰਾ ਗੰਭੀਰ ਮੁੱਦਾ ਹੈ, ਇਸ ਤੱਥ ਦੇ ਅਧਾਰ ਤੇ ਕਿ ਵਿੰਡੋਜ਼ ਕੋਲ UNIX ਵਰਗੀ ਸਾਂਝੀ ਮੈਮੋਰੀ ਨਹੀਂ ਹੈ, ਜਦੋਂ ਕਿ PostgreSQL ਸਭ ਇਸ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਬਹੁ-ਪ੍ਰਕਿਰਿਆ ਪ੍ਰਣਾਲੀ ਹੈ।

ਅਤੇ ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਹਰ ਕੋਈ ਸੋਲਾਰਿਸ ਵਰਗੇ ਐਕਸੋਟਿਕਸ ਵਿੱਚ ਘੱਟ ਦਿਲਚਸਪੀ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਚਲੋ.

ਇੱਕ ਆਧੁਨਿਕ ਲੀਨਕਸ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਵਿੱਚ 1 ਤੋਂ ਵੱਧ syctl ਵਿਕਲਪ ਹਨ, ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਰਨਲ ਕਿਵੇਂ ਬਣਾਉਂਦੇ ਹੋ। ਉਸੇ ਸਮੇਂ, ਜੇ ਅਸੀਂ ਵੱਖੋ-ਵੱਖਰੇ ਗਿਰੀਆਂ ਨੂੰ ਵੇਖਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਕਈ ਤਰੀਕਿਆਂ ਨਾਲ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਅਨੁਕੂਲ ਕਰ ਸਕਦੇ ਹਾਂ. ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਮਾਊਂਟ ਕਰਨਾ ਹੈ ਇਸ ਬਾਰੇ ਫਾਈਲ ਸਿਸਟਮ ਪੈਰਾਮੀਟਰ ਹਨ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਇਸ ਬਾਰੇ ਸਵਾਲ ਹਨ ਕਿ ਇਸਨੂੰ ਕਿਵੇਂ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ: BIOS ਵਿੱਚ ਕੀ ਸਮਰੱਥ ਕਰਨਾ ਹੈ, ਹਾਰਡਵੇਅਰ ਨੂੰ ਕਿਵੇਂ ਸੰਰਚਿਤ ਕਰਨਾ ਹੈ, ਆਦਿ।

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

ਲੀਨਕਸ ਵਿੱਚ ਕਿਹੜੇ ਰਵਾਇਤੀ ਟਿਊਨਿੰਗ ਟੀਚੇ ਹਨ? ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਕਿਉਂਕਿ ਤੁਸੀਂ ਸਾਰੇ ਲੀਨਕਸ ਪ੍ਰਸ਼ਾਸਨ ਨਾਲ ਨਜਿੱਠ ਰਹੇ ਹੋ, ਇਸ ਲਈ ਇਹ ਦੱਸਣ ਦੀ ਕੋਈ ਖਾਸ ਲੋੜ ਨਹੀਂ ਹੈ ਕਿ ਟੀਚੇ ਕੀ ਹਨ.

ਤੁਸੀਂ ਟਿਊਨ ਕਰ ਸਕਦੇ ਹੋ:

• ਸੀਪੀਯੂ.
• ਯਾਦਦਾਸ਼ਤ.
• ਸਟੋਰੇਜ.
• ਹੋਰ। ਅਸੀਂ ਇੱਕ ਸਨੈਕ ਲਈ ਅੰਤ ਵਿੱਚ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ. ਇੱਥੋਂ ਤੱਕ ਕਿ, ਉਦਾਹਰਨ ਲਈ, ਊਰਜਾ ਬੱਚਤ ਨੀਤੀ ਵਰਗੇ ਮਾਪਦੰਡ ਇੱਕ ਬਹੁਤ ਹੀ ਅਨੁਮਾਨਿਤ ਅਤੇ ਸਭ ਤੋਂ ਸੁਹਾਵਣੇ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੇ ਹਨ।

PostgreSQL ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਡਾਟਾਬੇਸ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਕੀ ਹਨ? ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀਗਤ ਗਿਰੀ ਨੂੰ ਟਵੀਕ ਨਹੀਂ ਕਰ ਸਕਦੇ ਅਤੇ ਇਹ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਸਾਡੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਕਾਫ਼ੀ ਸੁਧਾਰ ਹੋਇਆ ਹੈ।

ਹਾਂ, ਅਜਿਹੇ ਯੰਤਰ ਹਨ, ਪਰ ਇੱਕ ਡੇਟਾਬੇਸ ਇੱਕ ਗੁੰਝਲਦਾਰ ਚੀਜ਼ ਹੈ. ਇਹ ਉਹਨਾਂ ਸਾਰੇ ਸਰੋਤਾਂ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦਾ ਹੈ ਜੋ ਸਰਵਰ ਕੋਲ ਹਨ ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਨਾ ਪਸੰਦ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਓਰੇਕਲ ਦੀਆਂ ਮੌਜੂਦਾ ਸਿਫ਼ਾਰਸ਼ਾਂ ਨੂੰ ਦੇਖਦੇ ਹੋ ਕਿ ਹੋਸਟ OS ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਨੀ ਹੈ, ਤਾਂ ਇਹ ਉਸ ਮੰਗੋਲੀਆਈ ਪੁਲਾੜ ਯਾਤਰੀ ਬਾਰੇ ਮਜ਼ਾਕ ਵਾਂਗ ਹੋਵੇਗਾ - ਕੁੱਤੇ ਨੂੰ ਫੀਡ ਕਰੋ ਅਤੇ ਕੁਝ ਵੀ ਨਾ ਛੂਹੋ। ਆਉ ਡੇਟਾਬੇਸ ਨੂੰ ਸਾਰੇ ਸਰੋਤ ਦਿੰਦੇ ਹਾਂ, ਡੇਟਾਬੇਸ ਆਪਣੇ ਆਪ ਸਭ ਕੁਝ ਛਾਂਟ ਲਵੇਗਾ।

ਸਿਧਾਂਤ ਵਿੱਚ, ਕੁਝ ਹੱਦ ਤੱਕ ਸਥਿਤੀ PostgreSQL ਨਾਲ ਬਿਲਕੁਲ ਉਹੀ ਹੈ। ਫਰਕ ਇਹ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਅਜੇ ਤੱਕ ਆਪਣੇ ਲਈ ਸਾਰੇ ਸਰੋਤਾਂ ਨੂੰ ਲੈਣ ਦੇ ਯੋਗ ਨਹੀਂ ਹੈ, ਯਾਨੀ ਕਿ ਲੀਨਕਸ ਪੱਧਰ 'ਤੇ ਕਿਤੇ ਵੀ ਤੁਹਾਨੂੰ ਇਹ ਸਭ ਆਪਣੇ ਆਪ ਨੂੰ ਕ੍ਰਮਬੱਧ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

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

ਇੱਥੇ ਇਹ ਸਮਝਾਉਣ ਲਈ ਇੱਕ ਤਸਵੀਰ ਹੈ ਕਿ ਇਹ ਕੀ ਹੈ. ਇੱਥੇ ਇੱਕ ਲੀਨਕਸ OS ਬਫਰ ਹੈ ਅਤੇ ਸ਼ੇਅਰਡ ਮੈਮੋਰੀ ਹੈ ਅਤੇ ਪੋਸਟਗ੍ਰੇਸਕਿਯੂਐਲ ਸ਼ੇਅਰ ਬਫਰ ਹਨ। PostgreSQL, Oracle ਦੇ ਉਲਟ, ਸਿਰਫ਼ ਕਰਨਲ ਬਫਰ ਰਾਹੀਂ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਭਾਵ, ਡਿਸਕ ਤੋਂ ਇੱਕ ਪੰਨੇ ਨੂੰ ਆਪਣੀ ਸਾਂਝੀ ਮੈਮੋਰੀ ਵਿੱਚ ਜਾਣ ਲਈ, ਇਸ ਨੂੰ ਕਰਨਲ ਬਫਰ ਅਤੇ ਪਿੱਛੇ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਬਿਲਕੁਲ ਉਹੀ ਸਥਿਤੀ।

ਡਿਸਕਾਂ ਇਸ ਸਿਸਟਮ ਦੇ ਅਧੀਨ ਰਹਿੰਦੀਆਂ ਹਨ। ਮੈਂ ਇਸਨੂੰ ਡਿਸਕਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਖਿੱਚਿਆ. ਅਸਲ ਵਿੱਚ, ਇੱਕ 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 'ਤੇ ਉਸ ਮੋਡੀਊਲ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਬਹੁਤ ਘੱਟ ਮੈਮੋਰੀ ਹੁੰਦੀ ਹੈ। ਅਤੇ ਸੇਵਾ ਕੀਤੀ ਗਈ ਸਾਰੀ ਮੈਮੋਰੀ ਇਹਨਾਂ ਆਪਸ ਵਿੱਚ ਜੁੜਦੀ ਹੈ। ਇਹ ਹੌਲੀ ਅਤੇ ਉਦਾਸ ਬਾਹਰ ਕਾਮੁਕ. ਅਤੇ ਤੁਹਾਡਾ ਪ੍ਰੋਸੈਸਰ ਜੋ ਇਸ ਨੋਡ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ ਲਗਾਤਾਰ ਓਵਰਲੋਡ ਹੁੰਦਾ ਹੈ. ਅਤੇ ਇਸ ਮੈਮੋਰੀ ਦਾ ਐਕਸੈਸ ਟਾਈਮ ਖਰਾਬ, ਹੌਲੀ ਹੈ। ਇਹ ਉਹ ਸਥਿਤੀ ਹੈ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਚਾਹੁੰਦੇ ਹੋ ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਡੇਟਾਬੇਸ ਲਈ ਵਰਤ ਰਹੇ ਹੋ।

ਇਸ ਲਈ, ਲੀਨਕਸ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਲਈ ਡੇਟਾਬੇਸ ਲਈ ਇੱਕ ਹੋਰ ਸਹੀ ਵਿਕਲਪ ਇਹ ਨਹੀਂ ਜਾਣਦਾ ਹੈ ਕਿ ਉੱਥੇ ਕੀ ਹੋ ਰਿਹਾ ਹੈ। ਤਾਂ ਜੋ ਇਹ ਮੈਮੋਰੀ ਤੱਕ ਪਹੁੰਚ ਕਰੇ ਜਿਵੇਂ ਇਹ ਕਰਦਾ ਹੈ।

ਅਜਿਹਾ ਕਿਉਂ ਹੈ? ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਇਹ ਇਸ ਦੇ ਉਲਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਇਹ ਇੱਕ ਸਧਾਰਨ ਕਾਰਨ ਕਰਕੇ ਵਾਪਰਦਾ ਹੈ: ਸਾਨੂੰ ਪੇਜ ਕੈਸ਼ ਲਈ ਬਹੁਤ ਸਾਰੀ ਮੈਮੋਰੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ - ਦਸਾਂ, ਸੈਂਕੜੇ ਗੀਗਾਬਾਈਟ।

ਅਤੇ ਜੇਕਰ ਅਸੀਂ ਇਹ ਸਭ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ ਅਤੇ ਆਪਣੇ ਡੇਟਾ ਨੂੰ ਉੱਥੇ ਕੈਸ਼ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਕੈਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਲਾਭ ਮੈਮੋਰੀ ਤੱਕ ਅਜਿਹੀ ਮੁਸ਼ਕਲ ਪਹੁੰਚ ਤੋਂ ਹੋਣ ਵਾਲੇ ਲਾਭ ਨਾਲੋਂ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਹੋਵੇਗਾ। ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਸਾਨੂੰ ਇਸ ਤੱਥ ਦੇ ਮੁਕਾਬਲੇ ਅਸਾਧਾਰਣ ਲਾਭ ਹੋਵੇਗਾ ਕਿ ਅਸੀਂ NUMA ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮੈਮੋਰੀ ਨੂੰ ਵਧੇਰੇ ਕੁਸ਼ਲਤਾ ਨਾਲ ਐਕਸੈਸ ਕਰਾਂਗੇ।

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

ਇਸ ਲਈ, ਸਹੀ ਪਹੁੰਚ NUMA ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਯੋਗ ਕਰਨਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਰੀਬੂਟ ਕਰਨ ਵੇਲੇ। ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਜਿੱਤਾਂ ਇੰਨੇ ਵਿਸ਼ਾਲਤਾ ਦੇ ਆਦੇਸ਼ਾਂ ਦੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਕਿ ਕਿਹੜਾ ਬਿਹਤਰ ਹੈ ਦਾ ਸਵਾਲ ਹੀ ਪੈਦਾ ਨਹੀਂ ਹੁੰਦਾ।

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

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

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

ਐਮਰਜੈਂਸੀ ਸਥਿਤੀ ਵਿੱਚ, ਜਦੋਂ ਸਭ ਕੁਝ ਬਹੁਤ ਖਰਾਬ ਹੁੰਦਾ ਹੈ, ਤੁਹਾਡਾ ਫੋਨ ਲਗਾਤਾਰ ਵੱਜ ਰਿਹਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡਾ ਬੌਸ ਇੱਕ ਵੱਡੀ ਸੋਟੀ ਲੈ ਕੇ ਦੌੜਦਾ ਹੈ, ਤੁਹਾਡੇ ਕੋਲ ਜਾਂਚ ਕਰਨ ਬਾਰੇ ਸੋਚਣ ਦਾ ਸਮਾਂ ਨਹੀਂ ਹੋਵੇਗਾ। ਅਤੇ ਨਤੀਜੇ ਕਾਫ਼ੀ ਵਿਨਾਸ਼ਕਾਰੀ ਹੋ ਸਕਦੇ ਹਨ.

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

ਗੱਲ ਕੀ ਹੈ? ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਜ਼ਿਆਦਾ RAM ਵਾਲਾ ਬਹੁਤ ਮਹਿੰਗਾ ਸਰਵਰ ਨਹੀਂ ਹੈ, ਉਦਾਹਰਨ ਲਈ, 30 GB ਤੋਂ ਵੱਧ। ਤੁਸੀਂ ਵੱਡੇ ਪੰਨਿਆਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਮੈਮੋਰੀ ਵਰਤੋਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਓਵਰਹੈੱਡ ਹੈ। ਅਤੇ ਇਹ ਓਵਰਹੈੱਡ ਸਭ ਤੋਂ ਸੁਹਾਵਣਾ ਤੋਂ ਬਹੁਤ ਦੂਰ ਹੈ.

ਅਜਿਹਾ ਕਿਉਂ ਹੈ? ਤਾਂ ਕੀ ਹੋ ਰਿਹਾ ਹੈ? ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਮੈਮੋਰੀ ਨੂੰ ਛੋਟੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ। ਇਹ ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਹੈ, ਇਹ ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਹੋਇਆ ਹੈ। ਅਤੇ ਜੇਕਰ ਅਸੀਂ ਵਿਸਥਾਰ ਵਿੱਚ ਜਾਂਦੇ ਹਾਂ, ਤਾਂ OS ਨੂੰ ਵਰਚੁਅਲ ਪਤਿਆਂ ਦਾ ਭੌਤਿਕ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਅਤੇ ਇਹ ਪ੍ਰਕਿਰਿਆ ਸਭ ਤੋਂ ਸਰਲ ਨਹੀਂ ਹੈ, ਇਸਲਈ OS ਟ੍ਰਾਂਸਲੇਸ਼ਨ ਲੁਕਸਾਈਡ ਬਫਰ (TLB) ਵਿੱਚ ਇਸ ਕਾਰਵਾਈ ਦੇ ਨਤੀਜੇ ਨੂੰ ਕੈਸ਼ ਕਰਦਾ ਹੈ।

ਅਤੇ ਕਿਉਂਕਿ TLB ਇੱਕ ਕੈਸ਼ ਹੈ, ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਕੈਸ਼ ਵਿੱਚ ਮੌਜੂਦ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੀ RAM ਹੈ ਅਤੇ ਇਹ ਸਭ ਛੋਟੇ ਭਾਗਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ, ਤਾਂ ਇਹ ਬਫਰ ਬਹੁਤ ਵੱਡਾ ਬਣ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਜੇ ਕੈਸ਼ ਵੱਡਾ ਹੈ, ਤਾਂ ਇਸ ਦੁਆਰਾ ਖੋਜ ਕਰਨਾ ਹੌਲੀ ਹੈ. ਓਵਰਹੈੱਡ ਸਿਹਤਮੰਦ ਹੈ ਅਤੇ ਇਹ ਆਪਣੇ ਆਪ ਵਿੱਚ ਜਗ੍ਹਾ ਲੈਂਦਾ ਹੈ, ਯਾਨੀ ਕਿ RAM ਨੂੰ ਕਿਸੇ ਗਲਤ ਚੀਜ਼ ਦੁਆਰਾ ਖਪਤ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ। ਇਸ ਸਮੇਂ.

ਦੋ - ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ ਜਿੰਨਾ ਜ਼ਿਆਦਾ ਕੈਸ਼ ਵਧਦਾ ਹੈ, ਓਨਾ ਹੀ ਜ਼ਿਆਦਾ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕੈਸ਼ ਮਿਸ ਹੋ ਜਾਵੇਗਾ। ਅਤੇ ਇਸ ਕੈਸ਼ ਦੀ ਕੁਸ਼ਲਤਾ ਤੇਜ਼ੀ ਨਾਲ ਘਟਦੀ ਹੈ ਕਿਉਂਕਿ ਇਸਦਾ ਆਕਾਰ ਵਧਦਾ ਹੈ. ਇਸ ਲਈ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਇੱਕ ਸਧਾਰਨ ਪਹੁੰਚ ਨਾਲ ਆਏ ਹਨ. ਇਹ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਲੀਨਕਸ ਵਿੱਚ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ। ਇਹ ਬਹੁਤ ਸਮਾਂ ਪਹਿਲਾਂ ਫ੍ਰੀਬੀਐਸਡੀ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਇਆ ਸੀ. ਪਰ ਅਸੀਂ ਲੀਨਕਸ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ. ਇਹ ਵੱਡੇ ਪੰਨੇ ਹਨ।

ਅਤੇ ਇੱਥੇ ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਵਿਸ਼ਾਲ ਪੰਨੇ, ਇੱਕ ਵਿਚਾਰ ਦੇ ਰੂਪ ਵਿੱਚ, ਸ਼ੁਰੂ ਵਿੱਚ ਓਰੇਕਲ ਅਤੇ 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 ਮੈਮੋਰੀ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਆਮ ਵੱਡੇ ਪੰਨੇ ਠੀਕ ਹਨ, ਅਤੇ ਅਸੀਂ ਸਿਰਫ਼ ਪਾਰਦਰਸ਼ੀ ਨੂੰ ਅਯੋਗ ਕਰਦੇ ਹਾਂ।

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

ਅਤੇ ਇਹ ਕਈ ਤਰੀਕਿਆਂ ਨਾਲ ਬਹੁਤ ਕੋਝਾ ਹੋਵੇਗਾ। ਅਤੇ ਮੁੱਖ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਆਧੁਨਿਕ ਕਰਨਲ ਪੁਰਾਣੇ ਲੀਨਕਸ ਕਰਨਲ ਨਾਲੋਂ ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ। ਅਤੇ ਇਸ ਗੱਲ 'ਤੇ ਕਦਮ ਰੱਖਣ ਲਈ ਕਾਫ਼ੀ ਕੋਝਾ ਹੈ, ਕਿਉਂਕਿ ਜਦੋਂ ਅਸੀਂ ਸਵੈਪ ਨਾਲ ਕਿਸੇ ਕਿਸਮ ਦੇ ਕੰਮ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਇਹ ਓਓਐਮ-ਕਾਤਲ ਦੇ ਅਚਨਚੇਤ ਆਗਮਨ ਨਾਲ ਖਤਮ ਹੁੰਦਾ ਹੈ. ਅਤੇ 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 ਨੂੰ ਰੋਕ ਦਿੱਤਾ ਹੈ, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਹ ਸਾਰੇ ਉਪਭੋਗਤਾ ਜੋ ਉਹਨਾਂ ਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਆਏ ਸਨ, ਉਡੀਕ ਕਰਨਗੇ.

ਜੇ ਤੁਸੀਂ ਲੀਨਕਸ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਦੇਖਦੇ ਹੋ, ਜੇ ਤੁਸੀਂ ਚੰਗਾ ਹਾਰਡਵੇਅਰ ਲਿਆ ਹੈ, ਇਸ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕੀਤਾ ਹੈ, PostgreSQL ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਕੌਂਫਿਗਰ ਕੀਤਾ ਹੈ ਤਾਂ ਕਿ ਇਹ ਇਹਨਾਂ ਚੈਕਪੁਆਇੰਟਾਂ ਨੂੰ ਘੱਟ ਅਕਸਰ ਬਣਾਉਂਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਦੇ ਵਿਚਕਾਰ ਸਮੇਂ ਦੇ ਨਾਲ ਫੈਲਾਉਂਦਾ ਹੈ, ਫਿਰ ਤੁਸੀਂ ਡਿਫੌਲਟ ਡੇਬੀਅਨ ਪੈਰਾਮੀਟਰਾਂ ਵਿੱਚ ਕਦਮ ਰੱਖਦੇ ਹੋ। ਜ਼ਿਆਦਾਤਰ ਲੀਨਕਸ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਲਈ, ਇਹ ਤਸਵੀਰ ਹੈ: 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, ਜੋ ਕਿ ਮੂਲ ਰੂਪ ਵਿੱਚ ਇੱਕ ਹੈ।

ਅਤੇ ਉਹ ਤੁਹਾਡੀ ਜ਼ਿੰਦਗੀ ਨੂੰ ਕਿਵੇਂ ਬਰਬਾਦ ਕਰਦੇ ਹਨ? ਅਨੁਸੂਚਿਤ_ਪ੍ਰਵਾਸ_ਕੀਮਤ ਕੀ ਹੈ? ਲੀਨਕਸ ਉੱਤੇ, ਸ਼ਡਿਊਲਰ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਇੱਕ CPU ਤੋਂ ਦੂਜੇ ਵਿੱਚ ਮਾਈਗਰੇਟ ਕਰ ਸਕਦਾ ਹੈ। ਅਤੇ PostgreSQL ਲਈ, ਜੋ ਕਿ ਸਵਾਲਾਂ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ, ਕਿਸੇ ਹੋਰ CPU ਵਿੱਚ ਮਾਈਗਰੇਟ ਕਰਨਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸਪਸ਼ਟ ਹੈ। ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਜਦੋਂ ਤੁਸੀਂ ਓਪਨ ਆਫਿਸ ਅਤੇ ਟਰਮੀਨਲ ਵਿਚਕਾਰ ਵਿੰਡੋਜ਼ ਨੂੰ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਇਹ ਚੰਗਾ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇੱਕ ਡੇਟਾਬੇਸ ਲਈ ਇਹ ਬਹੁਤ ਮਾੜਾ ਹੈ। ਇਸਲਈ, ਇੱਕ ਵਾਜਬ ਨੀਤੀ ਹੈ ਮਾਈਗ੍ਰੇਸ਼ਨ_ਕੋਸਟ ਨੂੰ ਕੁਝ ਵੱਡੇ ਮੁੱਲ, ਘੱਟੋ-ਘੱਟ ਕਈ ਹਜ਼ਾਰ ਨੈਨੋਸਕਿੰਡ ਵਿੱਚ ਸੈੱਟ ਕਰਨਾ।

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

ਦੂਜਾ ਬਿੰਦੂ ਆਟੋਗਰੁੱਪ ਹੈ। ਖਾਸ ਵਰਕਲੋਡਾਂ ਲਈ ਇੱਕ ਚੰਗਾ ਵਿਚਾਰ ਹੈ ਜੋ ਆਧੁਨਿਕ ਡੇਟਾਬੇਸ ਨਾਲ ਸਬੰਧਤ ਨਹੀਂ ਹਨ - ਇਹ ਵਰਚੁਅਲ ਟਰਮੀਨਲ ਦੁਆਰਾ ਸਮੂਹ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਹੈ ਜਿੱਥੋਂ ਉਹ ਲਾਂਚ ਕੀਤੇ ਗਏ ਹਨ। ਇਹ ਕੁਝ ਕੰਮਾਂ ਲਈ ਸੁਵਿਧਾਜਨਕ ਹੈ। ਅਭਿਆਸ ਵਿੱਚ, PostgreSQL ਇੱਕ ਪ੍ਰੀਫੋਰਕ ਵਾਲਾ ਇੱਕ ਬਹੁ-ਪ੍ਰਕਿਰਿਆ ਸਿਸਟਮ ਹੈ ਜੋ ਇੱਕ ਸਿੰਗਲ ਟਰਮੀਨਲ ਤੋਂ ਚੱਲਦਾ ਹੈ। ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਲਾਕ ਰਾਈਟਰ, ਚੈਕਪੁਆਇੰਟ ਹੈ, ਅਤੇ ਤੁਹਾਡੀਆਂ ਸਾਰੀਆਂ ਕਲਾਇੰਟ ਬੇਨਤੀਆਂ ਨੂੰ ਇੱਕ ਅਨੁਸੂਚੀ ਵਿੱਚ, ਪ੍ਰਤੀ CPU ਵਿੱਚ ਸਮੂਹਬੱਧ ਕੀਤਾ ਜਾਵੇਗਾ। ਅਤੇ ਉਹ ਇੱਕ ਦੂਜੇ ਦੇ ਨਾਲ ਦਖਲ ਦੇਣ ਅਤੇ ਉਸਨੂੰ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਵਿਅਸਤ ਰੱਖਣ ਲਈ, ਉਸਦੇ ਆਜ਼ਾਦ ਹੋਣ ਲਈ ਇੱਕਜੁੱਟ ਹੋ ਕੇ ਉੱਥੇ ਉਡੀਕ ਕਰਨਗੇ। ਇਹ ਇੱਕ ਅਜਿਹੀ ਕਹਾਣੀ ਹੈ ਜੋ ਅਜਿਹੇ ਲੋਡ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੇਲੋੜੀ ਹੈ ਅਤੇ ਇਸ ਲਈ ਇਸਨੂੰ ਬੰਦ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

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

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਹੋਸਟਰ ਤੋਂ ਸਰਵਰ ਕਿਰਾਏ 'ਤੇ ਲੈਂਦੇ ਹੋ, ਤਾਂ "ਚੰਗੇ" ਹੋਸਟਰਾਂ ਨੂੰ ਇਸ ਗੱਲ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਹੁੰਦੀ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਹੈ. ਉਹਨਾਂ ਦਾ ਕੰਮ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਉਹਨਾਂ ਦੇ ਲੋਹੇ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਕੁਸ਼ਲਤਾ ਨਾਲ ਵਰਤਿਆ ਜਾਵੇ। ਇਸ ਲਈ, ਮੂਲ ਰੂਪ ਵਿੱਚ ਉਹ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ 'ਤੇ ਲੈਪਟਾਪ ਪਾਵਰ ਸੇਵਿੰਗ ਮੋਡ ਨੂੰ ਸਮਰੱਥ ਕਰ ਸਕਦੇ ਹਨ।

ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਸਮੱਗਰੀ ਨੂੰ ਸਰਵਰ 'ਤੇ ਭਾਰੀ ਬੋਝ ਹੇਠ ਇੱਕ ਡਾਟਾਬੇਸ ਨਾਲ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੀ ਪਸੰਦ 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