PostgreSQL ਅੰਦਰੂਨੀ ਅੰਕੜਿਆਂ ਵਿੱਚ ਡੂੰਘੀ ਗੋਤਾਖੋਰੀ ਕਰੋ। ਅਲੈਕਸੀ ਲੇਸੋਵਸਕੀ

ਅਲੈਕਸੀ ਲੇਸੋਵਸਕੀ ਦੁਆਰਾ 2015 ਦੀ ਰਿਪੋਰਟ ਦਾ ਟ੍ਰਾਂਸਕ੍ਰਿਪਸ਼ਨ "ਪੋਸਟਗਰੇਐਸਕਯੂਐਲ ਅੰਦਰੂਨੀ ਅੰਕੜਿਆਂ ਵਿੱਚ ਡੂੰਘੀ ਡੁਬਕੀ"

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

PostgreSQL DBMS ਇੱਕ ਵਿਸ਼ਾਲ ਮਕੈਨਿਜ਼ਮ ਹੈ, ਅਤੇ ਇਸ ਵਿਧੀ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਉਪ-ਪ੍ਰਣਾਲੀਆਂ ਸ਼ਾਮਲ ਹਨ, ਜਿਨ੍ਹਾਂ ਦਾ ਤਾਲਮੇਲ ਕੰਮ DBMS ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਸਿੱਧਾ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਓਪਰੇਸ਼ਨ ਦੌਰਾਨ, ਭਾਗਾਂ ਦੇ ਸੰਚਾਲਨ ਬਾਰੇ ਅੰਕੜੇ ਅਤੇ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਤੁਹਾਨੂੰ PostgreSQL ਦੀ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਉਪਾਅ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਹਾਲਾਂਕਿ, ਇਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀ ਜਾਣਕਾਰੀ ਹੈ ਅਤੇ ਇਹ ਇੱਕ ਸਰਲ ਰੂਪ ਵਿੱਚ ਪੇਸ਼ ਕੀਤੀ ਗਈ ਹੈ. ਇਸ ਜਾਣਕਾਰੀ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨਾ ਅਤੇ ਇਸਦੀ ਵਿਆਖਿਆ ਕਰਨਾ ਕਈ ਵਾਰ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਗੈਰ-ਮਾਮੂਲੀ ਕੰਮ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਸਾਧਨਾਂ ਅਤੇ ਉਪਯੋਗਤਾਵਾਂ ਦਾ "ਚਿੜੀਆਘਰ" ਇੱਕ ਉੱਨਤ DBA ਨੂੰ ਵੀ ਆਸਾਨੀ ਨਾਲ ਉਲਝਾ ਸਕਦਾ ਹੈ।

ਨਮਸਕਾਰ ਮੇਰਾ ਨਾਮ ਅਲੇਕਸੀ ਹੈ। ਜਿਵੇਂ ਕਿ ਇਲਿਆ ਨੇ ਕਿਹਾ, ਮੈਂ PostgreSQL ਅੰਕੜਿਆਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ.

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

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

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

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

ਮੈਂ ਤੁਹਾਨੂੰ ਦਿਖਾਉਣਾ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਅੰਕੜਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਲਾਭਦਾਇਕ ਹੈ। ਇਹ ਜ਼ਰੂਰੀ ਹੈ. ਨਿਡਰ ਹੋ ਕੇ ਇਸ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਸਾਨੂੰ ਸਿਰਫ਼ ਸਧਾਰਨ SQL ਅਤੇ SQL ਦੇ ਬੁਨਿਆਦੀ ਗਿਆਨ ਦੀ ਲੋੜ ਹੈ।

ਅਤੇ ਅਸੀਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ ਕਿ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਕਿਹੜੇ ਅੰਕੜੇ ਚੁਣਨੇ ਹਨ।

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

ਅਸੀਂ CPU ਲੋਡ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹਾਂ top, ਅਸੀਂ ਕੁਝ ਸਿਸਟਮ ਉਪਯੋਗਤਾਵਾਂ ਦੁਆਰਾ ਮੈਮੋਰੀ ਉਪਯੋਗਤਾ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹਾਂ, ਪਰ ਅਸੀਂ PostgreSQL ਦੇ ਅੰਦਰ ਵੇਖਣ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵਾਂਗੇ। ਇਸਦੇ ਲਈ ਸਾਨੂੰ ਹੋਰ ਸਾਧਨਾਂ ਦੀ ਲੋੜ ਹੈ।

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

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

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

ਅੰਕੜਿਆਂ ਨਾਲ ਕੀ ਸਮੱਸਿਆਵਾਂ ਹਨ?

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

ਇਸ ਤੋਂ ਕੀ ਨਿਕਲਦਾ ਹੈ? ਅੰਕੜਿਆਂ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਲੈਣ ਦੇ ਯੋਗ ਹੋਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਤਾਂ ਜੋ ਪ੍ਰੋਗਰਾਮਾਂ 'ਤੇ ਨਿਰਭਰ ਨਾ ਹੋਵੋ, ਜਾਂ ਕਿਸੇ ਤਰ੍ਹਾਂ ਇਹਨਾਂ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਖੁਦ ਸੁਧਾਰੋ: ਆਪਣਾ ਲਾਭ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕੁਝ ਫੰਕਸ਼ਨ ਸ਼ਾਮਲ ਕਰੋ।

ਅਤੇ ਤੁਹਾਨੂੰ SQL ਦੇ ਬੁਨਿਆਦੀ ਗਿਆਨ ਦੀ ਲੋੜ ਹੈ. ਅੰਕੜਿਆਂ ਤੋਂ ਕੁਝ ਡਾਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ SQL ਸਵਾਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਭਾਵ ਤੁਹਾਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਕਿਵੇਂ ਸਿਲੈਕਟ, ਜੁਆਇਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

ਅੰਕੜੇ ਸਾਨੂੰ ਕਈ ਗੱਲਾਂ ਦੱਸਦੇ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ।

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

ਅੰਕੜਿਆਂ ਦੇ ਸਰੋਤ ਇਸ ਤਰ੍ਹਾਂ ਪੇਸ਼ ਕੀਤੇ ਗਏ ਹਨ:

• ਸ਼ੇਅਰਡ ਮੈਮੋਰੀ (ਸ਼ੇਅਰਡ ਬਫਰ) ਵਿੱਚ ਸਥਿਰ ਡੇਟਾ ਨੂੰ ਰੱਖਣ ਲਈ ਇੱਕ ਖੰਡ ਹੈ, ਉੱਥੇ ਉਹ ਕਾਊਂਟਰ ਵੀ ਹਨ ਜੋ ਲਗਾਤਾਰ ਵਧਦੇ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਕੁਝ ਘਟਨਾਵਾਂ ਵਾਪਰਦੀਆਂ ਹਨ, ਜਾਂ ਡੇਟਾਬੇਸ ਦੇ ਸੰਚਾਲਨ ਵਿੱਚ ਕੁਝ ਪਲ ਪੈਦਾ ਹੁੰਦੇ ਹਨ।
• ਇਹ ਸਾਰੇ ਕਾਊਂਟਰ ਉਪਭੋਗਤਾ ਲਈ ਉਪਲਬਧ ਨਹੀਂ ਹਨ ਅਤੇ ਪ੍ਰਬੰਧਕ ਲਈ ਵੀ ਉਪਲਬਧ ਨਹੀਂ ਹਨ। ਇਹ ਨੀਵੇਂ ਪੱਧਰ ਦੀਆਂ ਗੱਲਾਂ ਹਨ। ਉਹਨਾਂ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਲਈ, PostgreSQL SQL ਫੰਕਸ਼ਨਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਇੰਟਰਫੇਸ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਇਹਨਾਂ ਫੰਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਚੋਣਵੇਂ ਚੋਣ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ ਕਿਸੇ ਕਿਸਮ ਦੀ ਮੈਟ੍ਰਿਕ (ਜਾਂ ਮੈਟ੍ਰਿਕਸ ਦਾ ਸੈੱਟ) ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਾਂ।
• ਹਾਲਾਂਕਿ, ਇਹਨਾਂ ਫੰਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹਮੇਸ਼ਾ ਸੁਵਿਧਾਜਨਕ ਨਹੀਂ ਹੁੰਦਾ ਹੈ, ਇਸਲਈ ਫੰਕਸ਼ਨ ਵਿਯੂਜ਼ (VIEWs) ਲਈ ਆਧਾਰ ਹੁੰਦੇ ਹਨ। ਇਹ ਵਰਚੁਅਲ ਟੇਬਲ ਹਨ ਜੋ ਕਿਸੇ ਖਾਸ ਉਪ-ਸਿਸਟਮ 'ਤੇ ਅੰਕੜੇ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ, ਜਾਂ ਡੇਟਾਬੇਸ ਵਿੱਚ ਘਟਨਾਵਾਂ ਦੇ ਕੁਝ ਸੈੱਟਾਂ 'ਤੇ।
• ਇਹ ਬਿਲਟ-ਇਨ ਵਿਯੂਜ਼ (VIEWs) ਅੰਕੜਿਆਂ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਮੁੱਖ ਉਪਭੋਗਤਾ ਇੰਟਰਫੇਸ ਹਨ। ਉਹ ਬਿਨਾਂ ਕਿਸੇ ਵਾਧੂ ਸੈਟਿੰਗ ਦੇ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਉਪਲਬਧ ਹਨ, ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਤੁਰੰਤ ਵਰਤ ਸਕਦੇ ਹੋ, ਦੇਖ ਸਕਦੇ ਹੋ, ਉੱਥੋਂ ਜਾਣਕਾਰੀ ਲੈ ਸਕਦੇ ਹੋ। ਅਤੇ ਯੋਗਦਾਨ ਵੀ ਹਨ। ਯੋਗਦਾਨ ਅਧਿਕਾਰਤ ਹਨ। ਤੁਸੀਂ postgresql-contrib ਪੈਕੇਜ (ਉਦਾਹਰਨ ਲਈ, postgresql94-contrib) ਨੂੰ ਇੰਸਟਾਲ ਕਰ ਸਕਦੇ ਹੋ, ਸੰਰਚਨਾ ਵਿੱਚ ਲੋੜੀਂਦੇ ਮੋਡੀਊਲ ਨੂੰ ਲੋਡ ਕਰ ਸਕਦੇ ਹੋ, ਇਸਦੇ ਲਈ ਮਾਪਦੰਡ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹੋ, PostgreSQL ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਵਰਤ ਸਕਦੇ ਹੋ। (ਨੋਟ। ਵੰਡ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਯੋਗਦਾਨ ਦੇ ਤਾਜ਼ਾ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਪੈਕੇਜ ਮੁੱਖ ਪੈਕੇਜ ਦਾ ਹਿੱਸਾ ਹੈ).
• ਅਤੇ ਅਣਅਧਿਕਾਰਤ ਯੋਗਦਾਨ ਹਨ. ਉਹਨਾਂ ਨੂੰ ਮਿਆਰੀ PostgreSQL ਵੰਡ ਨਾਲ ਸਪਲਾਈ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਉਹਨਾਂ ਨੂੰ ਜਾਂ ਤਾਂ ਕੰਪਾਇਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਵਜੋਂ ਸਥਾਪਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਵਿਕਲਪ ਬਹੁਤ ਵੱਖਰੇ ਹੋ ਸਕਦੇ ਹਨ, ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਇਸ ਗੈਰ-ਅਧਿਕਾਰਤ ਯੋਗਦਾਨ ਦਾ ਵਿਕਾਸਕਾਰ ਕੀ ਲੈ ਕੇ ਆਇਆ ਹੈ।

ਇਹ ਸਲਾਈਡ ਉਹਨਾਂ ਸਾਰੇ ਦ੍ਰਿਸ਼ਾਂ (VIEWs) ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਦਿਖਾਉਂਦੀ ਹੈ ਜੋ PostgreSQL 9.4 ਵਿੱਚ ਉਪਲਬਧ ਹਨ। ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਦੇਖ ਸਕਦੇ ਹਾਂ, ਉਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਹਨ. ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਪਹਿਲੀ ਵਾਰ ਇਸਦਾ ਅਨੁਭਵ ਕਰ ਰਹੇ ਹੋ ਤਾਂ ਉਲਝਣ ਵਿੱਚ ਪੈਣਾ ਬਹੁਤ ਆਸਾਨ ਹੈ।

ਹਾਲਾਂਕਿ, ਜੇ ਅਸੀਂ ਪਿਛਲੀ ਤਸਵੀਰ ਲੈਂਦੇ ਹਾਂ Как тратится время на PostgreSQL ਅਤੇ ਇਸ ਸੂਚੀ ਦੇ ਅਨੁਕੂਲ, ਸਾਨੂੰ ਇਹ ਤਸਵੀਰ ਮਿਲਦੀ ਹੈ। ਹਰੇਕ ਦ੍ਰਿਸ਼ (VIEWs), ਜਾਂ ਹਰੇਕ ਫੰਕਸ਼ਨ, ਜਦੋਂ ਸਾਡੇ ਕੋਲ PostgreSQL ਚੱਲ ਰਿਹਾ ਹੋਵੇ ਤਾਂ ਅਸੀਂ ਢੁਕਵੇਂ ਅੰਕੜੇ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕਿਸੇ ਇੱਕ ਮਕਸਦ ਜਾਂ ਦੂਜੇ ਲਈ ਵਰਤ ਸਕਦੇ ਹਾਂ। ਅਤੇ ਅਸੀਂ ਸਬ-ਸਿਸਟਮ ਦੇ ਸੰਚਾਲਨ ਬਾਰੇ ਪਹਿਲਾਂ ਹੀ ਕੁਝ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਾਂ।

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

ਅਸੀਂ ਉੱਥੋਂ ਕੀ ਲੈ ਸਕਦੇ ਹਾਂ? ਆਉ ਸਭ ਤੋਂ ਸਧਾਰਨ ਚੀਜ਼ਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ.

select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;

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

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

select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;

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

ਅਸੀਂ ਇਸ ਬੇਨਤੀ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਾਂ। ਇਹ SQL ਪਰੈਟੀ ਸਧਾਰਨ ਹੈ. ਅਤੇ ਅਸੀਂ ਇਸ ਡੇਟਾ ਨੂੰ ਆਪਣੇ ਲਈ ਦੇਖ ਸਕਦੇ ਹਾਂ।

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

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

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

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

pg_stat_bgwriter - ਇਹ ਦ੍ਰਿਸ਼ ਦੋ PostgreSQL ਪਿਛੋਕੜ ਉਪ-ਸਿਸਟਮ ਦੇ ਸੰਚਾਲਨ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ: checkpointer и background writer.

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

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

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

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

ਅਤੇ ਚੈੱਕਪੁਆਇੰਟ ਨੂੰ ਅਨੁਕੂਲ ਕਰਨ ਲਈ ਤਿੰਨ ਮਾਪਦੰਡ ਹਨ:

• сheckpoint_segments.

• сheckpoint_timeout.

• сheckpoint_competion_target.

ਉਹ ਤੁਹਾਨੂੰ ਕੰਟਰੋਲ ਪੁਆਇੰਟ ਦੇ ਸੰਚਾਲਨ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ. ਪਰ ਮੈਂ ਉਨ੍ਹਾਂ ਉੱਤੇ ਨਹੀਂ ਵਸਾਂਗਾ। ਉਨ੍ਹਾਂ ਦਾ ਪ੍ਰਭਾਵ ਇੱਕ ਵੱਖਰਾ ਮੁੱਦਾ ਹੈ।

ਚੇਤਾਵਨੀ: ਰਿਪੋਰਟ ਵਿੱਚ ਵਿਚਾਰਿਆ ਗਿਆ ਸੰਸਕਰਣ 9.4 ਹੁਣ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ। PostgreSQL ਦੇ ਆਧੁਨਿਕ ਸੰਸਕਰਣਾਂ ਵਿੱਚ, ਪੈਰਾਮੀਟਰ checkpoint_segments ਪੈਰਾਮੀਟਰਾਂ ਦੁਆਰਾ ਬਦਲਿਆ ਗਿਆ ਹੈ min_wal_size и max_wal_size.

ਅਗਲਾ ਉਪ-ਸਿਸਟਮ ਪਿਛੋਕੜ ਲੇਖਕ ਹੈ - background writer. ਉਹ ਕੀ ਕਰ ਰਿਹਾ ਹੈ? ਇਹ ਇੱਕ ਬੇਅੰਤ ਲੂਪ ਵਿੱਚ ਨਿਰੰਤਰ ਚੱਲਦਾ ਹੈ. ਇਹ ਸ਼ੇਅਰਡ ਬਫਰਾਂ ਵਿੱਚ ਪੰਨਿਆਂ ਨੂੰ ਸਕੈਨ ਕਰਦਾ ਹੈ ਅਤੇ ਗੰਦੇ ਪੰਨਿਆਂ ਨੂੰ ਡਿਸਕ ਤੇ ਫਲੱਸ਼ ਕਰਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਇਹ ਚੈਕਪੁਆਇੰਟਰ ਨੂੰ ਚੈਕਪੁਆਇੰਟਿੰਗ ਦੌਰਾਨ ਘੱਟ ਕੰਮ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

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

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

ਚੇਤਾਵਨੀ: _ ਨਿਮਨਲਿਖਤ ਟੈਕਸਟ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨਾਲ ਜੁੜੇ ਅੰਕੜਿਆਂ ਦੇ ਵਿਚਾਰਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਪੋਸਟਗ੍ਰੇਸ 10 ਵਿੱਚ ਜ਼ਿਆਦਾਤਰ ਦ੍ਰਿਸ਼ ਅਤੇ ਫੰਕਸ਼ਨ ਦੇ ਨਾਮ ਬਦਲ ਦਿੱਤੇ ਗਏ ਹਨ। ਨਾਮ ਬਦਲਣ ਦਾ ਸਾਰ ਬਦਲਣਾ ਸੀ। xlog 'ਤੇ wal и location 'ਤੇ lsn ਫੰਕਸ਼ਨ/ਦ੍ਰਿਸ਼ ਨਾਮ, ਆਦਿ ਵਿੱਚ ਖਾਸ ਉਦਾਹਰਨ, ਫੰਕਸ਼ਨ pg_xlog_location_diff() ਦਾ ਨਾਮ ਦਿੱਤਾ ਗਿਆ ਸੀ pg_wal_lsn_diff()._

ਸਾਡੇ ਇੱਥੇ ਵੀ ਬਹੁਤ ਕੁਝ ਹੈ। ਪਰ ਸਾਨੂੰ ਸਿਰਫ਼ ਸਥਾਨ ਨਾਲ ਸਬੰਧਤ ਚੀਜ਼ਾਂ ਦੀ ਲੋੜ ਹੈ।

ਜੇ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਸਾਰੀਆਂ ਕਦਰਾਂ-ਕੀਮਤਾਂ ਬਰਾਬਰ ਹਨ, ਤਾਂ ਇਹ ਆਦਰਸ਼ ਹੈ ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਮਾਸਟਰ ਤੋਂ ਪਿੱਛੇ ਨਹੀਂ ਰਹਿੰਦੀ।

ਇੱਥੇ ਇਹ ਹੈਕਸਾਡੈਸੀਮਲ ਸਥਿਤੀ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਵਿੱਚ ਸਥਿਤੀ ਹੈ। ਇਹ ਲਗਾਤਾਰ ਵਧਦਾ ਹੈ ਜੇਕਰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਕੁਝ ਗਤੀਵਿਧੀ ਹੁੰਦੀ ਹੈ: ਸੰਮਿਲਿਤ ਕਰਨਾ, ਮਿਟਾਉਣਾ, ਆਦਿ.

сколько записано xlog в байтах
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
лаг репликации в байтах
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
лаг репликации в секундах
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());

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

ਦੇਰੀ ਦੇ ਤਿੰਨ ਕਾਰਨ ਹਨ:

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

ਅਤੇ ਇੱਥੇ ਤਿੰਨ ਸਵਾਲ ਹਨ ਜੋ ਸਾਨੂੰ ਅੰਕੜਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ। ਅਸੀਂ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਵਿੱਚ ਕਿੰਨਾ ਰਿਕਾਰਡ ਹੈ। ਅਜਿਹਾ ਫੰਕਸ਼ਨ ਹੈ pg_xlog_location_diff ਅਤੇ ਅਸੀਂ ਬਾਈਟਸ ਅਤੇ ਸਕਿੰਟਾਂ ਵਿੱਚ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਪਛੜ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦੇ ਹਾਂ। ਅਸੀਂ ਇਸਦੇ ਲਈ ਇਸ ਦ੍ਰਿਸ਼ (VIEWs) ਤੋਂ ਮੁੱਲ ਦੀ ਵਰਤੋਂ ਵੀ ਕਰਦੇ ਹਾਂ।

ਨੋਟ: pg_xlog_location ਦੀ ਬਜਾਏdiff() ਫੰਕਸ਼ਨ, ਤੁਸੀਂ ਘਟਾਓ ਓਪਰੇਟਰ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇੱਕ ਸਥਾਨ ਨੂੰ ਦੂਜੀ ਤੋਂ ਘਟਾ ਸਕਦੇ ਹੋ। ਆਰਾਮਦਾਇਕ.

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

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

select
relname,
pg_size_pretty(pg_relation_size(relname::regclass)) as size,
seq_scan, seq_tup_read,
seq_scan / seq_tup_read as seq_tup_avg
from pg_stat_user_tables
where seq_tup_read > 0 order by 3,4 desc limit 5;

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

ਹਾਲਾਂਕਿ, ਇੱਕ ਦੂਜੀ ਮੈਟ੍ਰਿਕ ਹੈ - seq_tup_read. ਇਹ ਕ੍ਰਮਵਾਰ ਸਕੈਨ ਤੋਂ ਵਾਪਸ ਆਈਆਂ ਕਤਾਰਾਂ ਦੀ ਗਿਣਤੀ ਹੈ। ਜੇਕਰ ਔਸਤ ਸੰਖਿਆ 1, 000, 10, 000 ਤੋਂ ਵੱਧ ਹੈ, ਤਾਂ ਇਹ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਇੱਕ ਸੂਚਕ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕਿਤੇ ਇੱਕ ਸੂਚਕਾਂਕ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ ਤਾਂ ਜੋ ਐਕਸੈਸ ਨੂੰ ਸੂਚਕਾਂਕ ਦੁਆਰਾ ਕੀਤਾ ਜਾ ਸਕੇ, ਜਾਂ ਅਜਿਹੇ ਕ੍ਰਮਵਾਰ ਸਕੈਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰਨਾ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਜੋ ਅਜਿਹਾ ਨਹੀਂ ਹੁੰਦਾ।

ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਨ - ਮੰਨ ਲਓ ਕਿ ਇੱਕ ਵੱਡੀ OFFSET ਅਤੇ LIMIT ਵਾਲੀ ਬੇਨਤੀ ਇਸਦੀ ਕੀਮਤ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਸਾਰਣੀ ਵਿੱਚ 100 ਕਤਾਰਾਂ ਨੂੰ ਸਕੈਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ 000 ਲੋੜੀਂਦੀਆਂ ਕਤਾਰਾਂ ਲਈਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਪਿਛਲੀਆਂ ਸਕੈਨ ਕੀਤੀਆਂ ਕਤਾਰਾਂ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਵੀ ਮਾੜਾ ਮਾਮਲਾ ਹੈ। ਅਤੇ ਅਜਿਹੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਅਤੇ ਇੱਥੇ ਇੱਕ ਸਧਾਰਨ SQL ਪੁੱਛਗਿੱਛ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ ਅਤੇ ਪ੍ਰਾਪਤ ਕੀਤੇ ਨੰਬਰਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰ ਸਕਦੇ ਹੋ।

select
relname,
pg_size_pretty(pg_total_relation_size(relname::regclass)) as
full_size,
pg_size_pretty(pg_relation_size(relname::regclass)) as
table_size,
pg_size_pretty(pg_total_relation_size(relname::regclass) -
pg_relation_size(relname::regclass)) as index_size
from pg_stat_user_tables
order by pg_total_relation_size(relname::regclass) desc limit 10;

ਇਸ ਸਾਰਣੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਤੇ ਵਾਧੂ ਫੰਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਟੇਬਲ ਦੇ ਆਕਾਰ ਵੀ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ pg_total_relation_size(), pg_relation_size().

ਆਮ ਤੌਰ 'ਤੇ, ਇੱਥੇ ਮੈਟਾਕਮਾਂਡ ਹਨ dt и di, ਜਿਸਨੂੰ ਤੁਸੀਂ PSQL ਵਿੱਚ ਵਰਤ ਸਕਦੇ ਹੋ ਅਤੇ ਸਾਰਣੀ ਅਤੇ ਸੂਚਕਾਂਕ ਦੇ ਆਕਾਰ ਵੀ ਦੇਖ ਸਕਦੇ ਹੋ।

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

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

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

select
s.relname,
pg_size_pretty(pg_relation_size(relid)),
coalesce(n_tup_ins,0) + 2 * coalesce(n_tup_upd,0) -
coalesce(n_tup_hot_upd,0) + coalesce(n_tup_del,0) AS total_writes,
(coalesce(n_tup_hot_upd,0)::float * 100 / (case when n_tup_upd > 0
then n_tup_upd else 1 end)::float)::numeric(10,2) AS hot_rate,
(select v[1] FROM regexp_matches(reloptions::text,E'fillfactor=(\d+)') as
r(v) limit 1) AS fillfactor
from pg_stat_all_tables s
join pg_class c ON c.oid=relid
order by total_writes desc limit 50;

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

ਅਤੇ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਹੈ n_tup_hot_upd ਵੱਡਾ, ਇਹ ਬਹੁਤ ਵਧੀਆ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹਲਕੇ ਅਪਡੇਟਸ ਪ੍ਰਚਲਿਤ ਹਨ ਅਤੇ ਇਹ ਸਾਡੇ ਲਈ ਸਰੋਤਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਸਸਤਾ ਹੈ ਅਤੇ ਸਭ ਕੁਝ ਠੀਕ ਹੈ।

ALTER TABLE table_name SET (fillfactor = 70);

ਵਾਲੀਅਮ ਨੂੰ ਕਿਵੇਂ ਵਧਾਉਣਾ ਹੈ hot updateov? ਅਸੀਂ ਵਰਤ ਸਕਦੇ ਹਾਂ fillfactor. ਇਹ INSERTs ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਸਾਰਣੀ ਵਿੱਚ ਇੱਕ ਪੰਨਾ ਭਰਨ ਵੇਲੇ ਰਾਖਵੀਂ ਖਾਲੀ ਥਾਂ ਦਾ ਆਕਾਰ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਸੰਮਿਲਨ ਟੇਬਲ ਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਉਹ ਪੰਨੇ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਭਰ ਦਿੰਦੇ ਹਨ, ਇਸ ਵਿੱਚ ਖਾਲੀ ਥਾਂ ਨਾ ਛੱਡੋ। ਫਿਰ ਇੱਕ ਨਵਾਂ ਪੰਨਾ ਉਜਾਗਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ. ਡਾਟਾ ਦੁਬਾਰਾ ਭਰਿਆ ਜਾਂਦਾ ਹੈ. ਅਤੇ ਇਹ ਡਿਫੌਲਟ ਵਿਵਹਾਰ ਹੈ, ਫਿਲਫੈਕਟਰ = 100%.

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

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

ਆਟੋਵੈਕਿਊਮ ਕਤਾਰ। ਆਟੋਵੈਕਿਊਮ ਅਜਿਹਾ ਸਬ-ਸਿਸਟਮ ਹੈ ਜਿਸ ਲਈ PostgreSQL ਵਿੱਚ ਬਹੁਤ ਘੱਟ ਅੰਕੜੇ ਹਨ। ਅਸੀਂ ਸਿਰਫ਼ pg_stat_activity ਵਿੱਚ ਟੇਬਲ ਵਿੱਚ ਦੇਖ ਸਕਦੇ ਹਾਂ ਕਿ ਇਸ ਸਮੇਂ ਸਾਡੇ ਕੋਲ ਕਿੰਨੇ ਵੈਕਿਊਮ ਹਨ। ਹਾਲਾਂਕਿ, ਇਹ ਸਮਝਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ ਕਿ ਜਾਂਦੇ ਸਮੇਂ ਕਤਾਰ ਵਿੱਚ ਕਿੰਨੇ ਟੇਬਲ ਹਨ।

ਨੋਟ: _ Postgres 10 ਤੋਂ ਬਾਅਦ, ਵੈਕਿਊਮ ਵੈਕਿਊਮ ਨੂੰ ਟਰੈਕ ਕਰਨ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਬਹੁਤ ਸੁਧਾਰ ਹੋਇਆ ਹੈ - pg_stat_progress ਝਲਕ ਦਿਖਾਈ ਦਿੱਤੀ ਹੈਵੈਕਿਊਮ, ਜੋ ਆਟੋਵੈਕਿਊਮ ਨਿਗਰਾਨੀ ਦੇ ਮੁੱਦੇ ਨੂੰ ਬਹੁਤ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ।

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

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

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

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

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

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

pg_stat_all_indexes ਸੂਚਕਾਂਕ 'ਤੇ ਅੰਕੜੇ ਹਨ। ਉਹ ਵੱਡੀ ਨਹੀਂ ਹੈ। ਅਤੇ ਅਸੀਂ ਇਸ ਤੋਂ ਸੂਚਕਾਂਕ ਦੀ ਵਰਤੋਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਾਂ। ਅਤੇ ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਕੋਲ ਕਿਹੜੇ ਸੂਚਕਾਂਕ ਵਾਧੂ ਹਨ.

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

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

ਦੋ ਲਿੰਕ:

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

http://www.databasesoup.com/2014/05/new-finding-unused-indexes-query.html

ਨਾ ਵਰਤੇ ਸੂਚਕਾਂਕ ਨੂੰ ਕਿਵੇਂ ਵੇਖਣਾ ਹੈ ਇਸ ਲਈ ਇਹ ਵਧੇਰੇ ਉੱਨਤ ਪੁੱਛਗਿੱਛ ਉਦਾਹਰਨਾਂ ਹਨ।

ਦੂਜਾ ਲਿੰਕ ਇੱਕ ਦਿਲਚਸਪ ਸਵਾਲ ਹੈ. ਇਸ ਵਿੱਚ ਇੱਕ ਬਹੁਤ ਹੀ ਗੈਰ-ਮਾਮੂਲੀ ਤਰਕ ਹੈ। ਮੈਂ ਸਮੀਖਿਆ ਲਈ ਇਸਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ.

ਸੂਚਕਾਂਕ ਦੁਆਰਾ ਹੋਰ ਕੀ ਸੰਖੇਪ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ?

• ਨਾ ਵਰਤੇ ਸੂਚਕਾਂਕ ਮਾੜੇ ਹਨ।

• ਉਹ ਥਾਂ ਲੈਂਦੇ ਹਨ।

• ਅੱਪਡੇਟ ਕਾਰਵਾਈਆਂ ਨੂੰ ਹੌਲੀ ਕਰੋ।

• ਵੈਕਿਊਮ ਲਈ ਵਾਧੂ ਕੰਮ.

ਜੇਕਰ ਅਸੀਂ ਨਾ ਵਰਤੇ ਸੂਚਕਾਂਕ ਨੂੰ ਹਟਾਉਂਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਸਿਰਫ਼ ਡਾਟਾਬੇਸ ਨੂੰ ਬਿਹਤਰ ਬਣਾਵਾਂਗੇ।

ਅਗਲਾ ਦ੍ਰਿਸ਼ ਹੈ pg_stat_activity. ਇਹ ਉਪਯੋਗਤਾ ਦਾ ਐਨਾਲਾਗ ਹੈ ps, ਸਿਰਫ਼ PostgreSQL ਵਿੱਚ। ਜੇ ps'ਓਮ ਤੁਸੀਂ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਦੇਖਦੇ ਹੋ, ਫਿਰ pg_stat_activity ਤੁਹਾਨੂੰ PostgreSQL ਦੇ ਅੰਦਰ ਗਤੀਵਿਧੀ ਦਿਖਾਏਗਾ।

ਅਸੀਂ ਉੱਥੋਂ ਕੀ ਲੈ ਸਕਦੇ ਹਾਂ?

select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;

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

select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;

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

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

select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;

ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ: ਅਜਿਹੀ ਬੇਨਤੀ ਨਾਲ, ਅਸੀਂ ਲੰਬੀਆਂ ਬੇਨਤੀਆਂ ਅਤੇ ਲੈਣ-ਦੇਣ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹਾਂ। ਅਸੀਂ ਫੰਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ clock_timestamp() ਕੰਮ ਕਰਨ ਦਾ ਸਮਾਂ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ. ਲੰਬੀਆਂ ਬੇਨਤੀਆਂ ਜੋ ਸਾਨੂੰ ਮਿਲੀਆਂ, ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਯਾਦ ਰੱਖ ਸਕਦੇ ਹਾਂ, ਉਹਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹਾਂ explain, ਯੋਜਨਾਵਾਂ ਨੂੰ ਦੇਖੋ ਅਤੇ ਕਿਸੇ ਤਰ੍ਹਾਂ ਅਨੁਕੂਲ ਬਣਾਓ। ਅਸੀਂ ਮੌਜੂਦਾ ਲੰਬੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਸ਼ੂਟ ਕਰਦੇ ਹਾਂ ਅਤੇ ਰਹਿੰਦੇ ਹਾਂ.

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

ਮਾੜੇ ਲੈਣ-ਦੇਣ ਲੈਣ-ਦੇਣ ਵਿੱਚ ਵਿਹਲੇ ਹਨ ਅਤੇ ਲੈਣ-ਦੇਣ ਵਿੱਚ ਵਿਹਲੇ ਹਨ (ਅਧੂਰੇ) ਲੈਣ-ਦੇਣ।

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

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

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

ਜੇ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਉਹਨਾਂ ਵਿੱਚੋਂ 5-10-20 ਤੋਂ ਵੱਧ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਚਿੰਤਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨਾਲ ਕੁਝ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ.

ਇੱਥੇ ਅਸੀਂ ਗਣਨਾ ਦੇ ਸਮੇਂ ਲਈ ਵੀ ਵਰਤਦੇ ਹਾਂ clock_timestamp(). ਅਸੀਂ ਲੈਣ-ਦੇਣ ਨੂੰ ਸ਼ੂਟ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਂਦੇ ਹਾਂ.

ਜਿਵੇਂ ਕਿ ਮੈਂ ਉੱਪਰ ਕਿਹਾ ਹੈ, ਤਾਲੇ ਉਦੋਂ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਦੋ ਜਾਂ ਵੱਧ ਲੈਣ-ਦੇਣ ਇੱਕ ਜਾਂ ਸਰੋਤਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਲਈ ਮੁਕਾਬਲਾ ਕਰਦੇ ਹਨ। ਇਸਦੇ ਲਈ ਸਾਡੇ ਕੋਲ ਇੱਕ ਖੇਤਰ ਹੈ waiting ਬੂਲੀਅਨ ਮੁੱਲ ਦੇ ਨਾਲ true ਜ false.

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

ਚੇਤਾਵਨੀ: _ Postgres 9.6 ਤੋਂ ਸ਼ੁਰੂ, ਖੇਤਰ waiting ਹਟਾਇਆ ਗਿਆ ਅਤੇ ਦੋ ਹੋਰ ਜਾਣਕਾਰੀ ਵਾਲੇ ਖੇਤਰਾਂ ਨਾਲ ਬਦਲਿਆ ਗਿਆ wait_event_type и wait_event._

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

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

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/c4_06_show_locked_queries.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_95.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_96.sql

http://big-elephants.com/2013-09/exploring-query-locks-in-postgres/

ਅਤੇ ਇੱਥੇ ਦੋ ਸਵਾਲ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਲਾਕ ਟਰੈਕ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ। ਅਸੀਂ ਦ੍ਰਿਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ pg_locks, ਜੋ ਤੁਹਾਨੂੰ ਭਾਰੀ ਤਾਲੇ ਨੂੰ ਟਰੈਕ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਅਤੇ ਪਹਿਲਾ ਲਿੰਕ ਖੁਦ ਬੇਨਤੀ ਟੈਕਸਟ ਹੈ. ਇਹ ਕਾਫ਼ੀ ਲੰਬਾ ਹੈ।

ਅਤੇ ਦੂਜਾ ਲਿੰਕ ਲਾਕ 'ਤੇ ਇੱਕ ਲੇਖ ਹੈ. ਇਹ ਪੜ੍ਹਨਾ ਲਾਭਦਾਇਕ ਹੈ, ਇਹ ਬਹੁਤ ਦਿਲਚਸਪ ਹੈ.

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

ਇਸ ਤਰ੍ਹਾਂ ਅਸੀਂ ਇਹ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹਾਂ ਕਿ ਕਿਸ ਨੇ ਕਿਸ ਨੂੰ ਬੰਦ ਕੀਤਾ ਹੈ, ਕਿਸ ਨੇ ਕਿਸ ਨੂੰ ਫੜਿਆ ਹੈ, ਅਤੇ ਅਸੀਂ ਇਸ ਨਾਲ ਅੱਗੇ ਨਜਿੱਠ ਸਕਦੇ ਹਾਂ।

ਅਗਲਾ ਮੋਡੀਊਲ ਹੈ pg_stat_statements. ਜਿਵੇਂ ਮੈਂ ਕਿਹਾ, ਇਹ ਇੱਕ ਮੋਡੀਊਲ ਹੈ। ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਸੰਰਚਨਾ ਵਿੱਚ ਇਸਦੀ ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਲੋਡ ਕਰਨ, PostgreSQL ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨ, ਮੋਡੀਊਲ (ਇੱਕ ਕਮਾਂਡ ਨਾਲ) ਸਥਾਪਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਫਿਰ ਸਾਡੇ ਕੋਲ ਇੱਕ ਨਵਾਂ ਦ੍ਰਿਸ਼ ਹੋਵੇਗਾ।

Cреднее время запроса в милисекундах
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;

Самые активно пишущие (в shared_buffers) запросы
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;

ਅਸੀਂ ਉੱਥੋਂ ਕੀ ਲੈ ਸਕਦੇ ਹਾਂ? ਜੇ ਅਸੀਂ ਸਧਾਰਨ ਚੀਜ਼ਾਂ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਔਸਤ ਪੁੱਛਗਿੱਛ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮਾਂ ਲੈ ਸਕਦੇ ਹਾਂ। ਸਮਾਂ ਵਧ ਰਿਹਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ PostgreSQL ਹੌਲੀ ਹੌਲੀ ਜਵਾਬ ਦੇ ਰਿਹਾ ਹੈ ਅਤੇ ਕੁਝ ਕਰਨ ਦੀ ਲੋੜ ਹੈ.

ਅਸੀਂ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਸਰਗਰਮ ਲਿਖਤੀ ਲੈਣ-ਦੇਣ ਦੇਖ ਸਕਦੇ ਹਾਂ ਜੋ ਸਾਂਝੇ ਬਫਰਾਂ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਬਦਲਦੇ ਹਨ। ਦੇਖੋ ਕਿ ਕੌਣ ਉੱਥੇ ਡਾਟਾ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ ਜਾਂ ਡਿਲੀਟ ਕਰਦਾ ਹੈ।

ਅਤੇ ਅਸੀਂ ਇਹਨਾਂ ਬੇਨਤੀਆਂ ਲਈ ਵੱਖ-ਵੱਖ ਅੰਕੜਿਆਂ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹਾਂ।

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

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

ਅਸੀਂ ਕੀ ਕਰ ਰਹੇ ਹਾਂ? ਅਸੀਂ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਲਈ ਸਮੁੱਚੇ ਅੰਕੜਿਆਂ ਦੀ ਗਣਨਾ ਕਰਦੇ ਹਾਂ। ਫਿਰ, ਹਰੇਕ ਪੁੱਛਗਿੱਛ ਲਈ, ਅਸੀਂ ਇਸ ਸਮੁੱਚੇ ਅੰਕੜਿਆਂ ਵਿੱਚ ਇਸਦੇ ਵਿਅਕਤੀਗਤ ਯੋਗਦਾਨ ਨੂੰ ਗਿਣਦੇ ਹਾਂ।

ਅਤੇ ਅਸੀਂ ਕੀ ਦੇਖ ਸਕਦੇ ਹਾਂ? ਅਸੀਂ ਹੋਰ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਪਿੱਠਭੂਮੀ ਦੇ ਵਿਰੁੱਧ ਇੱਕ ਖਾਸ ਕਿਸਮ ਦੀਆਂ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਦਾ ਕੁੱਲ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮਾਂ ਦੇਖ ਸਕਦੇ ਹਾਂ। ਅਸੀਂ ਸਮੁੱਚੀ ਤਸਵੀਰ ਦੇ ਸਬੰਧ ਵਿੱਚ CPU ਅਤੇ I/O ਵਰਤੋਂ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹਾਂ। ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਇਹਨਾਂ ਬੇਨਤੀਆਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ. ਅਸੀਂ ਇਸ ਰਿਪੋਰਟ ਦੇ ਅਧਾਰ 'ਤੇ ਚੋਟੀ ਦੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਬਣਾ ਰਹੇ ਹਾਂ ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਇਸ ਬਾਰੇ ਸੋਚਣ ਲਈ ਭੋਜਨ ਪ੍ਰਾਪਤ ਕਰ ਰਹੇ ਹਾਂ ਕਿ ਕੀ ਅਨੁਕੂਲਿਤ ਕਰਨਾ ਹੈ।

ਪਰਦੇ ਪਿੱਛੇ ਸਾਡੇ ਕੋਲ ਕੀ ਹੈ? ਅਜੇ ਵੀ ਕੁਝ ਬੇਨਤੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਮੈਂ ਵਿਚਾਰ ਨਹੀਂ ਕੀਤਾ, ਕਿਉਂਕਿ ਸਮਾਂ ਸੀਮਤ ਹੈ।

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

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

ਅਗਲਾ ਮੋਡੀਊਲ ਹੈ pgfincore. ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ ਸਿਸਟਮ ਕਾਲ ਦੁਆਰਾ ਹੇਠਲੇ-ਪੱਧਰੀ ਟੇਬਲ ਓਪਰੇਸ਼ਨ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ mincore(), ਭਾਵ ਇਹ ਤੁਹਾਨੂੰ ਟੇਬਲ ਨੂੰ ਸਾਂਝੇ ਬਫਰਾਂ ਵਿੱਚ ਲੋਡ ਕਰਨ, ਜਾਂ ਇਸਨੂੰ ਅਨਲੋਡ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਅਤੇ ਇਹ, ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਨਾਲ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਪੇਜ ਕੈਸ਼ ਦਾ ਮੁਆਇਨਾ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਯਾਨੀ ਕਿ, ਸ਼ੇਅਰਡ ਬਫਰਾਂ ਵਿੱਚ, ਪੇਜ ਕੈਸ਼ ਵਿੱਚ ਟੇਬਲ ਕਿੰਨਾ ਕੁ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ ਟੇਬਲ ਉੱਤੇ ਲੋਡ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।

ਅਗਲਾ ਮੋਡੀਊਲ ਹੈ pg_stat_kcache. ਇਹ ਸਿਸਟਮ ਕਾਲ ਦੀ ਵੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ getrusage(). ਅਤੇ ਇਹ ਬੇਨਤੀ ਨੂੰ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਇਸਨੂੰ ਚਲਾਉਂਦਾ ਹੈ. ਅਤੇ ਪ੍ਰਾਪਤ ਕੀਤੇ ਅੰਕੜਿਆਂ ਵਿੱਚ, ਇਹ ਸਾਨੂੰ ਇਹ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਕਿ ਸਾਡੀ ਬੇਨਤੀ ਨੇ ਡਿਸਕ I / O 'ਤੇ ਕਿੰਨਾ ਖਰਚ ਕੀਤਾ, ਅਰਥਾਤ, ਫਾਈਲ ਸਿਸਟਮ ਨਾਲ ਓਪਰੇਸ਼ਨ ਅਤੇ ਪ੍ਰੋਸੈਸਰ ਦੀ ਵਰਤੋਂ ਨੂੰ ਵੇਖਦਾ ਹੈ. ਹਾਲਾਂਕਿ, ਮੋਡੀਊਲ ਜਵਾਨ ਹੈ (khe-khe) ਅਤੇ ਇਸਦੇ ਕੰਮ ਲਈ ਇਸਨੂੰ PostgreSQL 9.4 ਅਤੇ pg_stat_statements ਦੀ ਲੋੜ ਹੈ, ਜਿਸਦਾ ਮੈਂ ਪਹਿਲਾਂ ਜ਼ਿਕਰ ਕੀਤਾ ਹੈ।

• ਅੰਕੜਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਯੋਗਤਾ ਲਾਭਦਾਇਕ ਹੈ. ਤੁਹਾਨੂੰ ਤੀਜੀ ਧਿਰ ਦੇ ਸੌਫਟਵੇਅਰ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਦੇਖ ਸਕਦੇ ਹੋ, ਕੁਝ ਕਰ ਸਕਦੇ ਹੋ, ਪ੍ਰਦਰਸ਼ਨ ਕਰ ਸਕਦੇ ਹੋ।

• ਅੰਕੜਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਆਸਾਨ ਹੈ, ਇਹ ਸਧਾਰਨ SQL ਹੈ। ਤੁਸੀਂ ਇੱਕ ਬੇਨਤੀ ਇਕੱਠੀ ਕੀਤੀ, ਇਸਨੂੰ ਕੰਪਾਇਲ ਕੀਤਾ, ਇਸਨੂੰ ਭੇਜਿਆ, ਇਸਨੂੰ ਦੇਖਿਆ.

• ਅੰਕੜੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੇ ਕੋਈ ਸਵਾਲ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਅੰਕੜਿਆਂ ਵੱਲ ਮੁੜਦੇ ਹੋ - ਦੇਖੋ, ਸਿੱਟੇ ਕੱਢੋ, ਨਤੀਜਿਆਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੋ।

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

ਹਵਾਲੇ

ਵੈਧ ਲਿੰਕ ਜੋ ਲੇਖ ਵਿੱਚ ਪਾਏ ਗਏ ਸਨ, ਜਿਨ੍ਹਾਂ ਦੇ ਅਧਾਰ ਤੇ, ਰਿਪੋਰਟ ਵਿੱਚ ਸਨ।

ਲੇਖਕ ਹੋਰ ਲਿਖੋ
https://dataegret.com/news-blog (eng)

ਅੰਕੜਾ ਕੁਲੈਕਟਰ
https://www.postgresql.org/docs/current/monitoring-stats.html

ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਨ ਫੰਕਸ਼ਨ
https://www.postgresql.org/docs/current/functions-admin.html

ਯੋਗਦਾਨ ਮਾਡਿਊਲ
https://www.postgresql.org/docs/current/pgstatstatements.html
https://www.postgresql.org/docs/current/pgstattuple.html
https://www.postgresql.org/docs/current/pgbuffercache.html
https://github.com/klando/pgfincore
https://github.com/dalibo/pg_stat_kcache

SQL ਉਪਯੋਗਤਾਵਾਂ ਅਤੇ sql ਕੋਡ ਦੀਆਂ ਉਦਾਹਰਣਾਂ
https://github.com/dataegret/pg-utils

ਤੁਹਾਡੇ ਧਿਆਨ ਲਈ ਸਭ ਦਾ ਧੰਨਵਾਦ!

ਸਰੋਤ: www.habr.com