ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਖਾਸ ਤਰੁੱਟੀਆਂ ਜੋ postgresql ਵਿੱਚ ਬਲੋਟ ਵੱਲ ਲੈ ਜਾਂਦੀਆਂ ਹਨ। ਆਂਦਰੇ ਸਾਲਨੀਕੋਵ

ਮੈਂ ਤੁਹਾਨੂੰ ਸੁਝਾਅ ਦਿੰਦਾ ਹਾਂ ਕਿ ਤੁਸੀਂ 2016 ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਆਂਡਰੇ ਸਲਨੀਕੋਵ ਦੁਆਰਾ ਰਿਪੋਰਟ ਦੀ ਪ੍ਰਤੀਲਿਪੀ ਨੂੰ ਪੜ੍ਹੋ "ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਖਾਸ ਗਲਤੀਆਂ ਜੋ ਪੋਸਟਗਰੇਸਕੀਐਲ ਵਿੱਚ ਫੁੱਲਣ ਵੱਲ ਲੈ ਜਾਂਦੀਆਂ ਹਨ"

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

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

ਗਲਤੀਆਂ ਕਿਉਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ? ਉਹ ਦੋ ਕਾਰਨਾਂ ਕਰਕੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ: ਬੇਤਰਤੀਬੇ ਤੌਰ 'ਤੇ, ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਕੰਮ ਕਰੇਗਾ ਅਤੇ ਕੁਝ ਵਿਧੀਆਂ ਦੀ ਅਗਿਆਨਤਾ ਦੇ ਕਾਰਨ ਜੋ ਡੇਟਾਬੇਸ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਨਾਲ-ਨਾਲ ਡੇਟਾਬੇਸ ਵਿੱਚ ਵੀ ਹੁੰਦੇ ਹਨ।

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

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

ਪਲੇਟ ਦਾ ਸ਼ੁਰੂਆਤੀ ਡੇਟਾ: ਇਹ ਕਾਫ਼ੀ ਛੋਟਾ ਹੈ, 2 MB. ਡੇਟਾਬੇਸ ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ ਚਿੰਨ੍ਹ ਲਈ ਪ੍ਰਤੀਕਿਰਿਆ ਸਮਾਂ ਵੀ ਬਹੁਤ ਵਧੀਆ ਹੈ। ਅਤੇ ਇੱਕ ਕਾਫ਼ੀ ਚੰਗਾ ਲੋਡ - ਪਲੇਟ ਦੇ ਅਨੁਸਾਰ ਪ੍ਰਤੀ ਸਕਿੰਟ 2 ਓਪਰੇਸ਼ਨ.

ਅਤੇ ਇਸ ਰਿਪੋਰਟ ਦੇ ਜ਼ਰੀਏ ਮੈਂ ਤੁਹਾਨੂੰ ਗ੍ਰਾਫ ਦਿਖਾਵਾਂਗਾ ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਸਮਝ ਸਕੋ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ। ਗ੍ਰਾਫਾਂ ਦੇ ਨਾਲ ਹਮੇਸ਼ਾ 2 ਸਲਾਈਡਾਂ ਹੋਣਗੀਆਂ। ਪਹਿਲੀ ਸਲਾਈਡ ਉਹ ਹੈ ਜੋ ਸਰਵਰ 'ਤੇ ਆਮ ਤੌਰ 'ਤੇ ਹੁੰਦਾ ਹੈ।

ਅਤੇ ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਕੋਲ ਅਸਲ ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਚਿੰਨ੍ਹ ਹੈ. ਸੂਚਕਾਂਕ 2 MB ਤੇ ਛੋਟਾ ਹੈ। ਇਹ ਖੱਬੇ ਪਾਸੇ ਦਾ ਪਹਿਲਾ ਗ੍ਰਾਫ਼ ਹੈ।

ਸਰਵਰ 'ਤੇ ਔਸਤ ਜਵਾਬ ਸਮਾਂ ਵੀ ਸਥਿਰ ਅਤੇ ਛੋਟਾ ਹੈ। ਇਹ ਉੱਪਰੀ ਸੱਜੇ ਗ੍ਰਾਫ਼ ਹੈ।

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

ਦੂਜੀ ਸਲਾਈਡ ਹਮੇਸ਼ਾ ਟੈਸਟ ਕੀਤੀ ਜਾ ਰਹੀ ਪਲੇਟ ਨੂੰ ਸਮਰਪਿਤ ਹੋਵੇਗੀ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਅਸੀਂ ਗਾਹਕ ਦੇ ਖਾਤੇ ਦੇ ਬਕਾਏ ਨੂੰ ਲਗਾਤਾਰ ਅਪਡੇਟ ਕਰਦੇ ਹਾਂ। ਅਤੇ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਇੱਕ ਅੱਪਡੇਟ ਓਪਰੇਸ਼ਨ ਲਈ ਔਸਤ ਜਵਾਬ ਸਮਾਂ ਕਾਫ਼ੀ ਵਧੀਆ ਹੈ, ਇੱਕ ਮਿਲੀਸਕਿੰਟ ਤੋਂ ਵੀ ਘੱਟ। ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਪ੍ਰੋਸੈਸਰ ਸਰੋਤ (ਇਹ ਉੱਪਰੀ ਸੱਜੇ ਗ੍ਰਾਫ ਹੈ) ਵੀ ਬਰਾਬਰ ਅਤੇ ਕਾਫ਼ੀ ਛੋਟੇ ਖਪਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

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

ਅਤੇ ਹੁਣ ਸਾਡੇ ਕੋਲ ਇੱਕ ਦੁਖਾਂਤ ਹੈ. ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਇੱਕ ਲੰਮਾ ਭੁੱਲ ਗਿਆ ਲੈਣ-ਦੇਣ ਹੈ. ਕਾਰਨ ਆਮ ਤੌਰ 'ਤੇ ਸਾਰੇ ਮਾਮੂਲੀ ਹੁੰਦੇ ਹਨ:

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

ਅਜਿਹੀਆਂ ਗੱਲਾਂ ਕਿੱਥੇ ਲੈ ਜਾਂਦੀਆਂ ਹਨ?

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

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

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

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

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

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

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

ਖਾਸ ਤੌਰ 'ਤੇ, ਖਾਤਿਆਂ ਵਾਲੀ ਟੈਸਟ ਪਲੇਟ ਦੇ ਅਨੁਸਾਰ, ਜਿੱਥੇ ਅਸੀਂ ਬਕਾਇਆ ਬਦਲਦੇ ਹਾਂ: ਇੱਕ ਬੇਨਤੀ ਲਈ ਜਵਾਬ ਸਮਾਂ ਆਮ ਵਾਂਗ ਜਾਪਦਾ ਹੈ। ਪਰ ਅਸਲ ਵਿੱਚ ਇਹ ਡੇਢ ਗੁਣਾ ਵੱਧ ਹੈ।

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

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

ਅਤੇ ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਉੱਥੇ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਜੇਕਰ ਤੁਸੀਂ ਪਿਛਲੀ ਰਿਪੋਰਟ 'ਤੇ ਨਹੀਂ ਸੀ, ਤਾਂ ਆਓ ਹੁਣ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਸਿਧਾਂਤ ਪ੍ਰਾਪਤ ਕਰੀਏ। ਅੰਦਰੂਨੀ ਪ੍ਰਕਿਰਿਆ ਬਾਰੇ ਸਿਧਾਂਤ। ਕਾਰ ਵੈਕਿਊਮ ਕਿਉਂ ਹੈ ਅਤੇ ਇਹ ਕੀ ਕਰਦਾ ਹੈ?

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

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

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

ਹਾਦਸੇ ਦੌਰਾਨ ਕੀ ਹੋਇਆ? ਉੱਥੇ ਇਹ ਪ੍ਰਕਿਰਿਆ ਕਿਵੇਂ ਹੋਈ?

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

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

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

ਅਤੇ ਜਦੋਂ ਅਸੀਂ ਇੱਕ ਪੁੱਛਗਿੱਛ ਨੂੰ ਚਲਾਉਂਦੇ ਹਾਂ, ਤਾਂ ਡਾਟਾਬੇਸ ਨੂੰ ਸਾਰੀਆਂ ਲਾਈਨਾਂ ਵਿੱਚੋਂ ਲੰਘਣਾ ਪੈਂਦਾ ਹੈ: ਲਾਲ ਅਤੇ ਹਰੇ ਦੋਵੇਂ, ਲੋੜੀਂਦੀ ਲਾਈਨ ਲੱਭਣ ਲਈ। ਅਤੇ ਬੇਕਾਰ ਡੇਟਾ ਦੇ ਨਾਲ ਇੱਕ ਟੇਬਲ ਨੂੰ ਫੁੱਲਣ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ "ਬਲੋਟ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਸਾਡੀ ਡਿਸਕ ਸਪੇਸ ਨੂੰ ਵੀ ਖਾ ਜਾਂਦਾ ਹੈ। ਯਾਦ ਰੱਖੋ, ਇਹ 2 ਐਮਬੀ ਸੀ, ਇਹ 300 ਐਮਬੀ ਬਣ ਗਿਆ? ਹੁਣ ਮੈਗਾਬਾਈਟ ਨੂੰ ਗੀਗਾਬਾਈਟ ਵਿੱਚ ਬਦਲੋ ਅਤੇ ਤੁਸੀਂ ਜਲਦੀ ਹੀ ਆਪਣੇ ਸਾਰੇ ਡਿਸਕ ਸਰੋਤ ਗੁਆ ਦੇਵੋਗੇ।

ਸਾਡੇ ਲਈ ਕੀ ਨਤੀਜੇ ਹੋ ਸਕਦੇ ਹਨ?

• ਮੇਰੇ ਉਦਾਹਰਣ ਵਿੱਚ, ਸਾਰਣੀ ਅਤੇ ਸੂਚਕਾਂਕ 150 ਗੁਣਾ ਵਧਿਆ ਹੈ. ਸਾਡੇ ਕੁਝ ਕਲਾਇੰਟਾਂ ਦੇ ਹੋਰ ਘਾਤਕ ਕੇਸ ਹੋਏ ਹਨ ਜਦੋਂ ਉਹਨਾਂ ਨੇ ਬਸ ਡਿਸਕ ਸਪੇਸ ਖਤਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਹੈ।
• ਟੇਬਲ ਦਾ ਆਕਾਰ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕਦੇ ਨਹੀਂ ਘਟੇਗਾ. ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ ਆਟੋਵੈਕਿਊਮ ਟੇਬਲ ਦੀ ਪੂਛ ਨੂੰ ਕੱਟ ਸਕਦਾ ਹੈ ਜੇਕਰ ਸਿਰਫ਼ ਡੈੱਡ ਲਾਈਨਾਂ ਹਨ। ਪਰ ਕਿਉਂਕਿ ਇੱਥੇ ਲਗਾਤਾਰ ਰੋਟੇਸ਼ਨ ਹੈ, ਇੱਕ ਹਰੇ ਲਾਈਨ ਅੰਤ ਵਿੱਚ ਜੰਮ ਸਕਦੀ ਹੈ ਅਤੇ ਅੱਪਡੇਟ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਬਾਕੀ ਸਾਰੀਆਂ ਪਲੇਟ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਕਿਤੇ ਲਿਖੀਆਂ ਜਾਣਗੀਆਂ। ਪਰ ਇਹ ਅਜਿਹੀ ਅਸੰਭਵ ਘਟਨਾ ਹੈ ਕਿ ਤੁਹਾਡੀ ਟੇਬਲ ਖੁਦ ਹੀ ਆਕਾਰ ਵਿੱਚ ਸੁੰਗੜ ਜਾਵੇਗੀ, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਇਸਦੀ ਉਮੀਦ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ।
• ਡੇਟਾਬੇਸ ਨੂੰ ਬੇਕਾਰ ਲਾਈਨਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਦੁਆਰਾ ਛਾਂਟਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਅਤੇ ਅਸੀਂ ਡਿਸਕ ਸਰੋਤਾਂ ਨੂੰ ਬਰਬਾਦ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਪ੍ਰੋਸੈਸਰ ਸਰੋਤਾਂ ਅਤੇ ਬਿਜਲੀ ਨੂੰ ਬਰਬਾਦ ਕਰਦੇ ਹਾਂ.
• ਅਤੇ ਇਹ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਜੇਕਰ ਸ਼ੁਰੂ ਵਿੱਚ ਅਸੀਂ ਬੇਨਤੀ 'ਤੇ 10 ਮਿਲੀਸਕਿੰਟ, ਸਾਡੇ ਕੋਡ 'ਤੇ 10 ਮਿਲੀਸਕਿੰਟ ਖਰਚ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਕਰੈਸ਼ ਦੇ ਦੌਰਾਨ ਅਸੀਂ ਬੇਨਤੀ 'ਤੇ ਇੱਕ ਸਕਿੰਟ ਅਤੇ ਕੋਡ' ਤੇ 10 ਮਿਲੀਸਕਿੰਟ ਖਰਚ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ, ਭਾਵ ਇੱਕ ਆਰਡਰ. ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਤੀਬਰਤਾ ਘਟੀ ਹੈ. ਅਤੇ ਜਦੋਂ ਦੁਰਘਟਨਾ ਦਾ ਹੱਲ ਹੋ ਗਿਆ, ਅਸੀਂ ਇੱਕ ਬੇਨਤੀ 'ਤੇ 20 ਮਿਲੀਸਕਿੰਟ, ਇੱਕ ਕੋਡ 'ਤੇ 10 ਮਿਲੀਸਕਿੰਟ ਖਰਚ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਅਜੇ ਵੀ ਉਤਪਾਦਕਤਾ ਵਿੱਚ ਡੇਢ ਗੁਣਾ ਘੱਟ ਗਏ ਹਾਂ. ਅਤੇ ਇਹ ਸਭ ਇੱਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੇ ਕਾਰਨ ਹੈ ਜੋ ਫ੍ਰੀਜ਼ ਹੋ ਗਿਆ ਹੈ, ਸ਼ਾਇਦ ਸਾਡੀ ਗਲਤੀ ਦੁਆਰਾ.
• ਅਤੇ ਸਵਾਲ: “ਅਸੀਂ ਸਭ ਕੁਝ ਵਾਪਸ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਾਂ?” ਤਾਂ ਜੋ ਸਾਡੇ ਨਾਲ ਸਭ ਕੁਝ ਠੀਕ ਰਹੇ ਅਤੇ ਬੇਨਤੀਆਂ ਦੁਰਘਟਨਾ ਤੋਂ ਪਹਿਲਾਂ ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਜਾਣ।

ਇਸ ਮੰਤਵ ਲਈ ਕੰਮ ਦਾ ਇੱਕ ਖਾਸ ਚੱਕਰ ਹੈ ਜੋ ਕੀਤਾ ਜਾਂਦਾ ਹੈ.

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

ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਟੇਬਲ ਲੱਭ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹਨਾਂ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸਦੇ ਲਈ ਪਹਿਲਾਂ ਹੀ ਟੂਲ ਮੌਜੂਦ ਹਨ। ਸਾਡੀ ਕੰਪਨੀ ਵਿੱਚ ਅਸੀਂ ਤਿੰਨ ਟੂਲ ਵਰਤਦੇ ਹਾਂ। ਪਹਿਲਾ ਬਿਲਟ-ਇਨ ਵੈਕਿਊਮ ਫੁਲ ਹੈ। ਉਹ ਬੇਰਹਿਮ, ਕਠੋਰ ਅਤੇ ਬੇਰਹਿਮ ਹੈ, ਪਰ ਕਈ ਵਾਰ ਉਹ ਬਹੁਤ ਉਪਯੋਗੀ ਹੁੰਦਾ ਹੈ। Pg_repack и pgcompacttable - ਇਹ ਟੇਬਲਾਂ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਨ ਲਈ ਤੀਜੀ-ਧਿਰ ਦੀਆਂ ਉਪਯੋਗਤਾਵਾਂ ਹਨ। ਅਤੇ ਉਹ ਡੇਟਾਬੇਸ ਨੂੰ ਵਧੇਰੇ ਧਿਆਨ ਨਾਲ ਵਰਤਦੇ ਹਨ.

ਉਹ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਕਿ ਤੁਹਾਡੇ ਲਈ ਵਧੇਰੇ ਸੁਵਿਧਾਜਨਕ ਕੀ ਹੈ। ਪਰ ਮੈਂ ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਅੰਤ ਵਿੱਚ ਦੱਸਾਂਗਾ. ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਤਿੰਨ ਸੰਦ ਹਨ. ਚੁਣਨ ਲਈ ਬਹੁਤ ਸਾਰੇ ਹਨ.

ਜਦੋਂ ਅਸੀਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਠੀਕ ਕਰ ਲੈਂਦੇ ਹਾਂ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾ ਲੈਂਦੇ ਹਾਂ ਕਿ ਸਭ ਕੁਝ ਠੀਕ ਹੈ, ਸਾਨੂੰ ਇਹ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਭਵਿੱਖ ਵਿੱਚ ਇਸ ਸਥਿਤੀ ਨੂੰ ਕਿਵੇਂ ਰੋਕਿਆ ਜਾਵੇ:

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

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

ਸਾਰਣੀ ਦਾ ਆਕਾਰ ਤੁਰੰਤ ਕੁਝ ਮੈਗਾਬਾਈਟ ਦੀ ਆਪਣੀ ਆਮ ਓਪਰੇਟਿੰਗ ਸਥਿਤੀ ਵਿੱਚ ਵਾਪਸ ਆ ਗਿਆ। ਇਸ ਨੇ ਸਰਵਰ ਲਈ ਔਸਤ ਜਵਾਬ ਸਮੇਂ ਨੂੰ ਬਹੁਤ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕੀਤਾ।

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

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

ਦੂਜੀ ਕਹਾਣੀ, ਜਿਸ ਵਿੱਚ ਅਸੀਂ ਲੋਡ ਨੂੰ ਵੰਡਦੇ ਹਾਂ ਅਤੇ ਸਰਵਰ ਸਰੋਤਾਂ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰਦੇ ਹਾਂ

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

ਅਤੇ ਇਹ ਸਥਿਤੀ ਕੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ? ਖਾਸ ਤੌਰ 'ਤੇ ਇਹਨਾਂ ਗ੍ਰਾਫਾਂ 'ਤੇ, ਮੈਂ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੀ ਮਿਆਦ ਲਈ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਤੋਂ ਲੈਣ-ਦੇਣ ਦੀ ਮਿਆਦ ਵੀ ਜੋੜੀ ਹੈ। ਬਾਕੀ ਸਾਰੇ ਗ੍ਰਾਫ਼ ਸਿਰਫ਼ ਮਾਸਟਰ ਸਰਵਰ ਦਾ ਹਵਾਲਾ ਦਿੰਦੇ ਹਨ।

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

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

ਜਦੋਂ ਤੱਕ ਇਹ ਰਿਪੋਰਟਾਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਨਾਲ ਟਕਰਾਅ ਦੇ ਕਾਰਨ ਵਾਪਸ ਆਉਣਾ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਦੀਆਂ ਉਦੋਂ ਤੱਕ ਸਭ ਕੁਝ ਠੀਕ ਹੈ। ਅਤੇ ਉਹ ਨਿਯਮਤ ਅੰਤਰਾਲਾਂ 'ਤੇ ਵਾਪਸ ਫਾਇਰ ਕਰਦੇ ਹਨ।

ਅਸੀਂ ਔਨਲਾਈਨ ਜਾਂਦੇ ਹਾਂ ਅਤੇ ਪੜ੍ਹਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ ਕਿ ਅਜਿਹਾ ਕਿਉਂ ਹੋ ਰਿਹਾ ਹੈ। ਅਤੇ ਅਸੀਂ ਇੱਕ ਹੱਲ ਲੱਭਦੇ ਹਾਂ.

ਪਹਿਲਾ ਹੱਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਲੇਟੈਂਸੀ ਨੂੰ ਵਧਾਉਣਾ ਹੈ। ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਸਾਡੀ ਰਿਪੋਰਟ 3 ਘੰਟੇ ਚੱਲਦੀ ਹੈ। ਅਸੀਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇਰੀ ਨੂੰ 3 ਘੰਟੇ ਤੱਕ ਸੈੱਟ ਕੀਤਾ ਹੈ। ਅਸੀਂ ਸਭ ਕੁਝ ਲਾਂਚ ਕਰ ਰਹੇ ਹਾਂ, ਪਰ ਸਾਨੂੰ ਹਾਲੇ ਵੀ ਕਈ ਵਾਰ ਰੱਦ ਕੀਤੇ ਜਾਣ ਦੀਆਂ ਰਿਪੋਰਟਾਂ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਆਉਂਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ।

ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਸਭ ਕੁਝ ਸੰਪੂਰਨ ਹੋਵੇ। ਅਸੀਂ ਹੋਰ ਚੜ੍ਹਦੇ ਹਾਂ। ਅਤੇ ਸਾਨੂੰ ਇੰਟਰਨੈੱਟ 'ਤੇ ਇੱਕ ਵਧੀਆ ਸੈਟਿੰਗ ਮਿਲੀ - hot_standby_feedback। ਚਲੋ ਇਸਨੂੰ ਚਾਲੂ ਕਰੀਏ। Hot_standby_feedback ਸਾਨੂੰ ਮਾਸਟਰ 'ਤੇ ਆਟੋਵੈਕਿਊਮ ਨੂੰ ਰੋਕਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਅਸੀਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਵਿਵਾਦਾਂ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੁਟਕਾਰਾ ਪਾ ਲੈਂਦੇ ਹਾਂ। ਅਤੇ ਰਿਪੋਰਟਾਂ ਦੇ ਨਾਲ ਸਾਡੇ ਲਈ ਸਭ ਕੁਝ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ।

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

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

ਇਹ ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦੇਵੇਗਾ ਜੇਕਰ ਅਸੀਂ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਮੈਂ ਪਹਿਲਾਂ ਕਿਸ ਬਾਰੇ ਗੱਲ ਕਰ ਰਿਹਾ ਸੀ?

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

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

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

ਟੈਸਟ ਕੀਤੇ ਟੈਬਲੇਟ ਦੇ ਅਨੁਸਾਰ, ਜਿੱਥੇ ਅਸੀਂ ਖਾਤੇ ਦੇ ਬਕਾਏ ਨੂੰ ਅਪਡੇਟ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਬਿਲਕੁਲ ਉਹੀ ਤਸਵੀਰ ਦੇਖਦੇ ਹਾਂ। ਔਸਤ ਖਾਤਾ ਅੱਪਡੇਟ ਸਮਾਂ ਵੀ ਹੌਲੀ-ਹੌਲੀ ਆਮ ਹੋ ਰਿਹਾ ਹੈ। ਪ੍ਰੋਸੈਸਰ ਦੁਆਰਾ ਖਪਤ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਸਰੋਤ ਵੀ ਘਟੇ ਹਨ। ਅਤੇ ਪ੍ਰਤੀ ਸਕਿੰਟ ਲੈਣ-ਦੇਣ ਦੀ ਗਿਣਤੀ ਆਮ ਵਾਂਗ ਵਾਪਸ ਆਉਂਦੀ ਹੈ। ਪਰ ਅਸੀਂ ਦੁਬਾਰਾ ਆਮ ਵਾਂਗ ਵਾਪਸ ਆ ਗਏ ਹਾਂ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਹਾਦਸੇ ਤੋਂ ਪਹਿਲਾਂ ਸੀ.

ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ, ਸਾਨੂੰ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਕਮੀ ਮਿਲਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਪਹਿਲੇ ਕੇਸ ਵਿੱਚ, ਡੇਢ ਤੋਂ ਦੋ ਗੁਣਾ ਤੱਕ, ਅਤੇ ਕਈ ਵਾਰ ਹੋਰ ਵੀ।

ਜਾਪਦਾ ਹੈ ਕਿ ਅਸੀਂ ਸਭ ਕੁਝ ਸਹੀ ਕੀਤਾ ਹੈ। ਲੋਡ ਵੰਡੋ. ਸਾਜ਼-ਸਾਮਾਨ ਵਿਹਲਾ ਨਹੀਂ ਹੈ। ਅਸੀਂ ਆਪਣੇ ਮਨ ਅਨੁਸਾਰ ਬੇਨਤੀਆਂ ਵੰਡੀਆਂ, ਪਰ ਫਿਰ ਵੀ ਸਭ ਕੁਝ ਮਾੜਾ ਹੋ ਗਿਆ।

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

ਅਸੀਂ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਨਤੀਜਿਆਂ ਨੂੰ ਖਤਮ ਕਰਦੇ ਹਾਂ:

• ਸਾਨੂੰ ਫੁੱਲੇ ਹੋਏ ਟੇਬਲ ਮਿਲਦੇ ਹਨ।
• ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਸਭ ਤੋਂ ਸੁਵਿਧਾਜਨਕ ਟੂਲ ਨਾਲ ਸੰਕੁਚਿਤ ਕਰਦੇ ਹਾਂ ਜੋ ਸਾਡੇ ਲਈ ਅਨੁਕੂਲ ਹੈ।

ਦੂਜੀ ਕਹਾਣੀ ਇੱਥੇ ਖਤਮ ਹੁੰਦੀ ਹੈ। ਆਓ ਤੀਜੀ ਕਹਾਣੀ ਵੱਲ ਵਧੀਏ।

ਸਾਡੇ ਲਈ ਵੀ ਕਾਫ਼ੀ ਆਮ ਹੈ ਜਿਸ ਵਿੱਚ ਅਸੀਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕਰਦੇ ਹਾਂ।

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

ਇੱਥੇ ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਪੇਸ਼ ਕੀਤੇ ਅਪਡੇਟ ਦੇ ਨਾਲ ਮਾਈਗ੍ਰੇਸ਼ਨ ਹੈ। ਕਿਉਂਕਿ ਇਹ ਮੇਰੇ ਖਾਤੇ ਦੇ ਲੈਣ-ਦੇਣ ਹਨ, ਪਲੇਟ 15 GB ਸੀ। ਅਤੇ ਕਿਉਂਕਿ ਅਸੀਂ ਹਰ ਲਾਈਨ ਨੂੰ ਅਪਡੇਟ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਅਪਡੇਟ ਦੇ ਨਾਲ ਸਾਰਣੀ ਦੇ ਆਕਾਰ ਨੂੰ ਦੁੱਗਣਾ ਕਰ ਦਿੱਤਾ ਹੈ, ਕਿਉਂਕਿ ਅਸੀਂ ਹਰ ਲਾਈਨ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਿਆ ਹੈ।

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

ਅਸੀਂ ਪਰਵਾਸ ਕੀਤਾ ਅਤੇ ਦੁਬਾਰਾ ਸਮੱਸਿਆਵਾਂ ਆਈਆਂ।

ਪਰਵਾਸ ਸਫਲ ਰਿਹਾ, ਪਰ:

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

ਅਤੇ ਇਹ ਫਿਰ ਬਲੋਟ ਹੈ, ਜੋ ਦੁਬਾਰਾ ਸਾਡੀ ਜ਼ਿੰਦਗੀ ਨੂੰ ਬਰਬਾਦ ਕਰ ਦਿੰਦਾ ਹੈ।

ਇੱਥੇ ਮੈਂ ਇਹ ਦਰਸਾਉਂਦਾ ਹਾਂ ਕਿ ਸਾਰਣੀ, ਪਿਛਲੇ ਦੋ ਕੇਸਾਂ ਵਾਂਗ, ਇਸਦੇ ਪਿਛਲੇ ਆਕਾਰਾਂ ਵਿੱਚ ਵਾਪਸ ਨਹੀਂ ਜਾ ਰਹੀ ਹੈ। ਔਸਤ ਸਰਵਰ ਲੋਡ ਕਾਫ਼ੀ ਜਾਪਦਾ ਹੈ।

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

ਅਤੇ ਇੱਥੇ ਮੁੱਖ ਗੱਲ ਇਹ ਸਮਝਣਾ ਹੈ ਕਿ ਅਜਿਹੇ ਪ੍ਰਵਾਸ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕਿਵੇਂ ਕਰਨਾ ਹੈ. ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਅਸੀਂ ਇਹ ਪ੍ਰਵਾਸ ਕਾਫ਼ੀ ਨਿਰੰਤਰਤਾ ਨਾਲ ਕਰਦੇ ਹਾਂ।

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

ਅਤੇ ਉਸੇ ਸਮੇਂ ਸਾਨੂੰ ਇੱਕ ਫੁੱਲ ਨਹੀਂ ਮਿਲੇਗਾ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਦੁੱਖ ਨਹੀਂ ਹੋਵੇਗਾ.

ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤੀਜੀ ਕਹਾਣੀ ਖਤਮ ਹੁੰਦੀ ਹੈ।

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat_approx.sql

ਅਤੇ ਹੁਣ ਉਹਨਾਂ ਸਾਧਨਾਂ ਬਾਰੇ ਥੋੜਾ ਹੋਰ ਵੇਰਵੇ ਜਿਹਨਾਂ ਦਾ ਮੈਂ ਪਹਿਲੀ ਕਹਾਣੀ ਵਿੱਚ ਜ਼ਿਕਰ ਕੀਤਾ ਹੈ.

ਬਲੋਟ ਦੀ ਖੋਜ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਐਕਸਟੈਂਸ਼ਨ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ pgstattuple.

ਤਾਂ ਜੋ ਤੁਹਾਨੂੰ ਸਵਾਲਾਂ ਦੇ ਨਾਲ ਆਉਣ ਦੀ ਲੋੜ ਨਾ ਪਵੇ, ਅਸੀਂ ਇਹਨਾਂ ਸਵਾਲਾਂ ਨੂੰ ਆਪਣੇ ਕੰਮ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਲਿਖ ਚੁੱਕੇ ਹਾਂ। ਤੁਸੀਂ ਇਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ। ਇੱਥੇ ਦੋ ਬੇਨਤੀਆਂ ਹਨ।

• ਪਹਿਲੇ ਨੂੰ ਕੰਮ ਕਰਨ ਵਿੱਚ ਕਾਫ਼ੀ ਸਮਾਂ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਤੁਹਾਨੂੰ ਸਾਰਣੀ ਤੋਂ ਸਹੀ ਬਲੋਟ ਮੁੱਲ ਦਿਖਾਏਗਾ।
• ਦੂਸਰਾ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਬਹੁਤ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਮੁਲਾਂਕਣ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਕਿ ਕੀ ਸਾਰਣੀ ਦੇ ਅਨੁਸਾਰ ਬਲੋਟ ਹੈ ਜਾਂ ਨਹੀਂ. ਅਤੇ ਤੁਹਾਨੂੰ ਇਹ ਵੀ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਬਲੋਟ ਹਮੇਸ਼ਾ ਪੋਸਟਗ੍ਰੇਸ ਟੇਬਲ ਵਿੱਚ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ. ਇਹ ਇਸਦੇ MVCC ਮਾਡਲ ਦੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ।
• ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਟੇਬਲ ਲਈ 20% ਬਲੋਟ ਆਮ ਹੁੰਦਾ ਹੈ। ਭਾਵ, ਤੁਹਾਨੂੰ ਚਿੰਤਾ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ ਅਤੇ ਇਸ ਸਾਰਣੀ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ.

ਅਸੀਂ ਇਹ ਪਤਾ ਲਗਾਇਆ ਹੈ ਕਿ ਬੇਕਾਰ ਡੇਟਾ ਨਾਲ ਸੁੱਜੀਆਂ ਹੋਈਆਂ ਟੇਬਲਾਂ ਦੀ ਪਛਾਣ ਕਿਵੇਂ ਕੀਤੀ ਜਾਵੇ।

ਹੁਣ ਬਲੌਟ ਨੂੰ ਠੀਕ ਕਰਨ ਦੇ ਤਰੀਕੇ ਬਾਰੇ:

• ਜੇਕਰ ਸਾਡੇ ਕੋਲ ਇੱਕ ਛੋਟੀ ਟੈਬਲੇਟ ਅਤੇ ਚੰਗੀ ਡਿਸਕ ਹੈ, ਯਾਨੀ ਕਿ ਇੱਕ ਗੀਗਾਬਾਈਟ ਤੱਕ ਦੀ ਟੈਬਲੇਟ ਤੇ, ਵੈਕਿਊਮ ਫੁਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਕਾਫ਼ੀ ਸੰਭਵ ਹੈ। ਉਹ ਤੁਹਾਡੇ ਤੋਂ ਕੁਝ ਸਕਿੰਟਾਂ ਲਈ ਮੇਜ਼ 'ਤੇ ਇਕ ਵਿਸ਼ੇਸ਼ ਲਾਕ ਲਵੇਗਾ ਅਤੇ ਠੀਕ ਹੈ, ਪਰ ਉਹ ਸਭ ਕੁਝ ਜਲਦੀ ਅਤੇ ਕਠੋਰਤਾ ਨਾਲ ਕਰੇਗਾ। ਵੈਕਿਊਮ ਫੁਲ ਕੀ ਕਰਦਾ ਹੈ? ਇਹ ਟੇਬਲ 'ਤੇ ਇੱਕ ਨਿਵੇਕਲਾ ਲਾਕ ਲੈਂਦਾ ਹੈ ਅਤੇ ਪੁਰਾਣੀਆਂ ਟੇਬਲਾਂ ਤੋਂ ਨਵੀਂ ਸਾਰਣੀ ਵਿੱਚ ਲਾਈਵ ਕਤਾਰਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਦਾ ਹੈ। ਅਤੇ ਅੰਤ ਵਿੱਚ ਉਹ ਉਹਨਾਂ ਦੀ ਥਾਂ ਲੈਂਦਾ ਹੈ. ਇਹ ਪੁਰਾਣੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਮਿਟਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਪੁਰਾਣੀਆਂ ਨੂੰ ਨਵੀਂਆਂ ਨਾਲ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਪਰ ਇਸ ਦੇ ਕੰਮ ਦੀ ਮਿਆਦ ਲਈ, ਇਸ ਨੂੰ ਮੇਜ਼ 'ਤੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਲਾਕ ਲੱਗਦਾ ਹੈ. ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸ ਸਾਰਣੀ ਨਾਲ ਕੁਝ ਨਹੀਂ ਕਰ ਸਕਦੇ: ਨਾ ਤਾਂ ਇਸ ਨੂੰ ਲਿਖੋ, ਨਾ ਹੀ ਇਸ ਵਿੱਚ ਪੜ੍ਹੋ, ਨਾ ਹੀ ਇਸ ਨੂੰ ਸੋਧੋ। ਅਤੇ VACUUM FULL ਨੂੰ ਡਾਟਾ ਲਿਖਣ ਲਈ ਵਾਧੂ ਡਿਸਕ ਸਪੇਸ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
• ਅਗਲਾ ਟੂਲ pg_repack. ਇਸਦੇ ਸਿਧਾਂਤ ਵਿੱਚ, ਇਹ ਵੈਕਿਊਮ ਫੁਲ ਦੇ ਸਮਾਨ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਪੁਰਾਣੀਆਂ ਫਾਈਲਾਂ ਤੋਂ ਨਵੀਆਂ ਫਾਈਲਾਂ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਮੁੜ ਲਿਖਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸਾਰਣੀ ਵਿੱਚ ਬਦਲਦਾ ਹੈ. ਪਰ ਉਸੇ ਸਮੇਂ, ਇਹ ਆਪਣੇ ਕੰਮ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਟੇਬਲ 'ਤੇ ਇੱਕ ਨਿਵੇਕਲਾ ਲਾਕ ਨਹੀਂ ਲੈਂਦਾ, ਪਰ ਇਸਨੂੰ ਸਿਰਫ ਉਸੇ ਸਮੇਂ ਲੈਂਦਾ ਹੈ ਜਦੋਂ ਇਸ ਕੋਲ ਫਾਈਲਾਂ ਨੂੰ ਬਦਲਣ ਲਈ ਪਹਿਲਾਂ ਹੀ ਤਿਆਰ ਡੇਟਾ ਹੁੰਦਾ ਹੈ. ਇਸ ਦੀਆਂ ਡਿਸਕ ਸਰੋਤ ਲੋੜਾਂ ਵੈਕਿਊਮ ਫੁਲ ਦੇ ਸਮਾਨ ਹਨ। ਤੁਹਾਨੂੰ ਵਾਧੂ ਡਿਸਕ ਸਪੇਸ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਇਹ ਕਈ ਵਾਰ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਟੈਰਾਬਾਈਟ ਟੇਬਲ ਹਨ। ਅਤੇ ਇਹ ਕਾਫ਼ੀ ਪ੍ਰੋਸੈਸਰ-ਭੁੱਖਿਆ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਰਗਰਮੀ ਨਾਲ I/O ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ।
• ਤੀਜੀ ਸਹੂਲਤ ਹੈ pgcompacttable. ਇਹ ਸਾਧਨਾਂ ਨਾਲ ਵਧੇਰੇ ਸਾਵਧਾਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਥੋੜ੍ਹਾ ਵੱਖਰੇ ਸਿਧਾਂਤਾਂ ਦੇ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦਾ ਹੈ। pgcompacttable ਦਾ ਮੁੱਖ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ ਇਹ ਸਾਰਣੀ ਵਿੱਚ ਅੱਪਡੇਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਾਰੀਆਂ ਲਾਈਵ ਕਤਾਰਾਂ ਨੂੰ ਸਾਰਣੀ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਭੇਜਦਾ ਹੈ। ਅਤੇ ਫਿਰ ਇਹ ਇਸ ਟੇਬਲ ਉੱਤੇ ਇੱਕ ਵੈਕਿਊਮ ਚਲਾਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਕੋਲ ਸ਼ੁਰੂ ਵਿੱਚ ਲਾਈਵ ਕਤਾਰਾਂ ਹਨ ਅਤੇ ਅੰਤ ਵਿੱਚ ਮਰੀਆਂ ਕਤਾਰਾਂ ਹਨ। ਅਤੇ ਵੈਕਿਊਮ ਆਪਣੇ ਆਪ ਹੀ ਇਸ ਪੂਛ ਨੂੰ ਕੱਟ ਦਿੰਦਾ ਹੈ, ਯਾਨੀ ਇਸ ਨੂੰ ਜ਼ਿਆਦਾ ਵਾਧੂ ਡਿਸਕ ਸਪੇਸ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ। ਅਤੇ ਉਸੇ ਸਮੇਂ, ਇਹ ਅਜੇ ਵੀ ਸਰੋਤਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਨਿਚੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ.

ਔਜ਼ਾਰਾਂ ਨਾਲ ਸਭ ਕੁਝ।

ਜੇਕਰ ਤੁਹਾਨੂੰ ਬਲੋਟ ਵਿਸ਼ੇ ਨੂੰ ਹੋਰ ਅੰਦਰ ਤੱਕ ਜਾਣ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਦਿਲਚਸਪ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਇੱਥੇ ਕੁਝ ਉਪਯੋਗੀ ਲਿੰਕ ਹਨ:

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres - ਇਹ ਮੇਰੇ ਸਾਥੀ ਦੀ ਇੱਕ ਰਿਪੋਰਟ ਹੈ. ਇਹ ਆਮ ਹੈ ਕਿ ਪੋਸਟਗ੍ਰੇਸ ਦੀ ਸਪੇਸ ਇਸਦੇ ਕੰਮ ਅਤੇ ਜੀਵਨ ਦੌਰਾਨ ਕਿੱਥੇ ਜਾਂਦੀ ਹੈ. ਅਤੇ ਬਲੋਟ ਬਾਰੇ ਡੇਟਾਬੇਸ ਪ੍ਰਸ਼ਾਸਕਾਂ ਲਈ ਇੱਕ ਬਹੁਤ ਵੱਡਾ ਅਤੇ ਵਿਸਤ੍ਰਿਤ ਤਕਨੀਕੀ ਟੁਕੜਾ ਹੈ.
• https://github.com/dataegret/pg-utils - ਇਹ ਸਾਡੀ ਰਿਪੋਜ਼ਟਰੀ ਲਈ ਇੱਕ ਲਿੰਕ ਹੈ, ਜਿੱਥੇ ਅਸੀਂ ਡੇਟਾਬੇਸ ਦੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਉਪਯੋਗੀ ਸਕ੍ਰਿਪਟਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਸਟੋਰ ਕਰਦੇ ਹਾਂ। ਉੱਥੇ ਤੁਸੀਂ ਬਲੋਟ ਦੀ ਖੋਜ ਕਰਨ ਲਈ ਸਕ੍ਰਿਪਟਾਂ ਲੱਭ ਸਕਦੇ ਹੋ।
• ਤੀਜਾ и ਚੌਥਾ ਟੂਲਸ ਦੇ ਲਿੰਕ ਜੋ ਤੁਹਾਨੂੰ ਸੰਕੇਤਾਂ ਨੂੰ ਸੁੰਗੜਨ ਵਿੱਚ ਮਦਦ ਕਰਨਗੇ।
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html - ਇਹ ਮੇਰੇ ਸਹਿਕਰਮੀ ਦੀ ਇੱਕ ਪੋਸਟ ਹੈ। ਉੱਥੇ ਉਹ ਪ੍ਰਸ਼ਾਸਕਾਂ ਦੇ ਨੇੜੇ ਦੇ ਪੱਧਰ 'ਤੇ ਬਹੁਤ ਗੰਭੀਰਤਾ ਨਾਲ ਅਤੇ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਬਲੋਟ ਦਾ ਵਿਸਥਾਰ ਨਾਲ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦਾ ਹੈ।

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

ਤੁਹਾਡੇ ਸਵਾਲ

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

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਇਹ ਤੁਹਾਡੀ ਕੰਪਨੀ ਦੇ ਪ੍ਰਸ਼ਾਸਕਾਂ ਲਈ ਇੱਕ ਕੰਮ ਹੈ, ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ DBA ਲਈ.

ਮੈਂ ਇੱਕ ਪ੍ਰਸ਼ਾਸਕ ਹਾਂ।

PostgreSQL ਵਿੱਚ pg_stat_activity ਨਾਮਕ ਇੱਕ ਦ੍ਰਿਸ਼ ਹੈ ਜੋ ਡੰਗਿੰਗ ਸਵਾਲਾਂ ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ। ਅਤੇ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਇਹ ਉੱਥੇ ਕਿੰਨਾ ਚਿਰ ਲਟਕਦਾ ਹੈ.

ਕੀ ਮੈਨੂੰ ਹਰ 5 ਮਿੰਟ ਵਿੱਚ ਅੰਦਰ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਦੇਖਣਾ ਪਵੇਗਾ?

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

ਕੀ ਅਜਿਹਾ ਹੋਣ ਦੇ ਕੋਈ ਸਪੱਸ਼ਟ ਕਾਰਨ ਹਨ?

ਮੈਂ ਕੁਝ ਸੂਚੀਬੱਧ ਕੀਤੇ ਹਨ. ਹੋਰ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਉਦਾਹਰਣਾਂ। ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਲਈ ਗੱਲਬਾਤ ਹੋ ਸਕਦੀ ਹੈ.

ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਮੈਂ pg_repack ਉਪਯੋਗਤਾ ਬਾਰੇ ਸਪੱਸ਼ਟ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ. ਜੇ ਉਹ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਲਾਕ ਨਹੀਂ ਕਰਦੀ, ਤਾਂ...

ਉਹ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਲਾਕ ਕਰਦੀ ਹੈ।

... ਫਿਰ ਮੈਂ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਡਾਟਾ ਗੁਆ ਸਕਦਾ ਹਾਂ। ਕੀ ਮੇਰੀ ਅਰਜ਼ੀ ਨੂੰ ਇਸ ਸਮੇਂ ਦੌਰਾਨ ਕੁਝ ਵੀ ਰਿਕਾਰਡ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

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

ਭਾਵ, ਉਹ ਅਸਲ ਵਿੱਚ ਅੰਤ ਵਿੱਚ ਇਹ ਕਰਦਾ ਹੈ?

ਅੰਤ ਵਿੱਚ, ਉਹ ਇਹਨਾਂ ਫਾਈਲਾਂ ਨੂੰ ਸਵੈਪ ਕਰਨ ਲਈ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਲਾਕ ਲੈਂਦਾ ਹੈ।

ਕੀ ਇਹ ਵੈਕਿਊਮ ਫੁਲ ਨਾਲੋਂ ਤੇਜ਼ ਹੋਵੇਗਾ?

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

ਸਤ ਸ੍ਰੀ ਅਕਾਲ! ਤੁਸੀਂ ਕਾਰ ਵੈਕਿਊਮ ਦੇ ਸੰਚਾਲਨ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਸੀ। ਲਾਲ, ਪੀਲੇ ਅਤੇ ਹਰੇ ਰਿਕਾਰਡਿੰਗ ਸੈੱਲਾਂ ਵਾਲਾ ਇੱਕ ਗ੍ਰਾਫ਼ ਸੀ। ਯਾਨੀ, ਪੀਲੇ - ਉਸਨੇ ਉਹਨਾਂ ਨੂੰ ਮਿਟਾਏ ਗਏ ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ. ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ, ਉਹਨਾਂ ਵਿੱਚ ਕੁਝ ਨਵਾਂ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ?

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

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

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

ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਕੀ ਮਿਆਦ ਨੂੰ ਸੀਮਿਤ ਕਰਨ ਲਈ ਸਟੇਟਮੈਂਟ ਟਾਈਮਆਉਟ ਸਵਾਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸਵੀਕਾਰਯੋਗ ਹੈ?

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

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

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

ਭਾਵ, ਇਹ ਅਪਡੇਟ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ?

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

ਸਤ ਸ੍ਰੀ ਅਕਾਲ! ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਚਲੋ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਸਾਡੇ ਕੋਲ ਇੱਕ ਡੇਟਾਬੇਸ ਹੈ ਜੋ ਸੋਜ ਅਤੇ ਸੋਜ ਹੈ ਅਤੇ ਫਿਰ ਸਰਵਰ 'ਤੇ ਸਪੇਸ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ. ਕੀ ਇਸ ਸਥਿਤੀ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਕੋਈ ਸਾਧਨ ਹਨ?

ਸਰਵਰ 'ਤੇ ਸਪੇਸ ਦੀ ਸਹੀ ਢੰਗ ਨਾਲ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, DBA ਚਾਹ ਲਈ ਗਿਆ, ਇੱਕ ਰਿਜੋਰਟ ਵਿੱਚ ਸੀ, ਆਦਿ।

ਜਦੋਂ ਇੱਕ ਫਾਈਲ ਸਿਸਟਮ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ, ਘੱਟੋ ਘੱਟ ਕਿਸੇ ਕਿਸਮ ਦੀ ਬੈਕਅਪ ਸਪੇਸ ਬਣਾਈ ਜਾਂਦੀ ਹੈ ਜਿੱਥੇ ਡੇਟਾ ਨਹੀਂ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ।

ਕੀ ਜੇ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਜ਼ੀਰੋ ਤੋਂ ਹੇਠਾਂ ਹੈ?

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

ਕੀ ਕੋਈ ਹੋਰ ਸਾਧਨ ਹਨ?

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

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

ਉਨ੍ਹਾਂ ਨੂੰ ਵੀ ਪੈਕ ਕਰਦੇ ਹਨ।

ਪਰ ਵੈਕਿਊਮ ਸੂਚਕਾਂਕ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦਾ?

ਕੁਝ ਇੱਕ ਸੂਚਕਾਂਕ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, pg_rapack, pgcompacttable. ਵੈਕਿਊਮ ਸੂਚਕਾਂਕ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਵੈਕਿਊਮ ਫੁਲ ਨਾਲ ਹਰ ਚੀਜ਼ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਨ ਦਾ ਵਿਚਾਰ ਹੈ, ਭਾਵ ਇਹ ਹਰ ਕਿਸੇ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ।

ਅਤੇ ਦੂਜਾ ਸਵਾਲ. ਮੈਨੂੰ ਸਮਝ ਨਹੀਂ ਆਉਂਦੀ ਕਿ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ 'ਤੇ ਰਿਪੋਰਟਾਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ 'ਤੇ ਇੰਨੀ ਜ਼ਿਆਦਾ ਕਿਉਂ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਮੈਨੂੰ ਜਾਪਦਾ ਸੀ ਕਿ ਰਿਪੋਰਟਾਂ ਪੜ੍ਹੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਨਕਲ ਲਿਖੀ ਜਾਂਦੀ ਹੈ.

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

ਐਂਡਰੀ, ਮੇਰੇ ਕੋਲ ਇੱਕ ਸਵਾਲ ਹੈ। ਇਹ ਸ਼ਾਨਦਾਰ ਗ੍ਰਾਫ਼ ਜੋ ਤੁਸੀਂ ਪੇਸ਼ਕਾਰੀ ਦੌਰਾਨ ਦਿਖਾਇਆ, ਕੀ ਇਹ ਤੁਹਾਡੀ ਕਿਸੇ ਕਿਸਮ ਦੀ ਉਪਯੋਗਤਾ ਦੇ ਕੰਮ ਦਾ ਨਤੀਜਾ ਹਨ? ਗ੍ਰਾਫ਼ ਕਿਵੇਂ ਬਣਾਏ ਗਏ ਸਨ?

ਇਹ ਇੱਕ ਸੇਵਾ ਹੈ ਓਕਮੀਟਰ.

ਕੀ ਇਹ ਵਪਾਰਕ ਉਤਪਾਦ ਹੈ?

ਹਾਂ। ਇਹ ਇੱਕ ਵਪਾਰਕ ਉਤਪਾਦ ਹੈ.

ਸਰੋਤ: www.habr.com