PostgreSQL ਨਿਗਰਾਨੀ ਦੀਆਂ ਬੁਨਿਆਦੀ ਗੱਲਾਂ। ਅਲੈਕਸੀ ਲੇਸੋਵਸਕੀ

ਮੈਂ ਤੁਹਾਨੂੰ ਸੁਝਾਅ ਦਿੰਦਾ ਹਾਂ ਕਿ ਤੁਸੀਂ ਡੇਟਾ ਐਗਰੇਟ "ਪੋਸਟਗਰੇਐਸਕਯੂਐਲ ਮਾਨੀਟਰਿੰਗ ਦੇ ਬੁਨਿਆਦੀ ਤੱਤ" ਤੋਂ ਅਲੈਕਸੀ ਲੇਸੋਵਸਕੀ ਦੁਆਰਾ ਰਿਪੋਰਟ ਦੀ ਪ੍ਰਤੀਲਿਪੀ ਨੂੰ ਪੜ੍ਹੋ।

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

ਮੇਰਾ ਨਾਮ ਅਲੈਕਸੀ ਲੇਸੋਵਸਕੀ ਹੈ, ਮੈਂ ਡੇਟਾ ਐਗਰੇਟ ਕੰਪਨੀ ਦੀ ਨੁਮਾਇੰਦਗੀ ਕਰਦਾ ਹਾਂ।

ਆਪਣੇ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ. ਮੈਂ ਇੱਕ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਵਜੋਂ ਬਹੁਤ ਸਮਾਂ ਪਹਿਲਾਂ ਸ਼ੁਰੂ ਕੀਤਾ ਸੀ।

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

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

ਹੁਣ ਮੈਂ PostgreSQL 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਹਾਂ। ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਇਕ ਹੋਰ ਚੀਜ਼ ਲਿਖ ਰਿਹਾ ਹਾਂ ਜੋ ਤੁਹਾਨੂੰ PostgreSQL ਅੰਕੜਿਆਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ. ਇਸ ਨੂੰ ਕਿਹਾ ਗਿਆ ਹੈ pgCenter (ਹੈਬਰੇ ਉੱਤੇ ਲੇਖ - ਤੰਤੂਆਂ ਅਤੇ ਤਣਾਅ ਦੇ ਬਿਨਾਂ ਪੋਸਟ-ਗਰੈਸ ਅੰਕੜੇ).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਦੀ ਸੰਖਿਆ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਲਈ, ਅਸੀਂ ਦੁਬਾਰਾ pg_stat_database ਦ੍ਰਿਸ਼ ਦਾ ਹਵਾਲਾ ਦੇ ਸਕਦੇ ਹਾਂ। ਅਸੀਂ ਪ੍ਰਤੀਬੱਧਤਾਵਾਂ ਦੀ ਸੰਖਿਆ ਅਤੇ ਰੋਲਬੈਕ ਦੀ ਸੰਖਿਆ ਨੂੰ ਜੋੜ ਸਕਦੇ ਹਾਂ ਅਤੇ ਪ੍ਰਤੀ ਸਕਿੰਟ ਲੈਣ-ਦੇਣ ਦੀ ਸੰਖਿਆ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਾਂ।

ਕੀ ਹਰ ਕੋਈ ਸਮਝਦਾ ਹੈ ਕਿ ਇੱਕ ਲੈਣ-ਦੇਣ ਵਿੱਚ ਕਈ ਬੇਨਤੀਆਂ ਫਿੱਟ ਹੋ ਸਕਦੀਆਂ ਹਨ? ਇਸ ਲਈ TPS ਅਤੇ QPS ਥੋੜੇ ਵੱਖਰੇ ਹਨ।

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

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

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

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

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

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

PostgreSQL ਬਾਰੇ ਇਕ ਹੋਰ ਗੱਲ ਇਹ ਹੈ ਕਿ PostgreSQL ਲੰਬੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਤੋਂ ਬਹੁਤ ਬਿਮਾਰ ਹੈ. ਖ਼ਾਸਕਰ ਉਨ੍ਹਾਂ ਲੈਣ-ਦੇਣ ਤੋਂ ਜੋ ਲੰਬੇ ਸਮੇਂ ਲਈ ਲਟਕਦੇ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਕੁਝ ਨਹੀਂ ਕਰਦੇ। ਇਹ ਅਖੌਤੀ ਸਟੇਟ ਆਈਡਲ-ਇਨ-ਲੈਣ-ਦੇਣ ਹੈ। ਅਜਿਹਾ ਲੈਣ-ਦੇਣ ਤਾਲੇ ਰੱਖਦਾ ਹੈ ਅਤੇ ਵੈਕਿਊਮ ਨੂੰ ਕੰਮ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ, ਟੇਬਲ ਸੁੱਜ ਜਾਂਦੇ ਹਨ ਅਤੇ ਆਕਾਰ ਵਿੱਚ ਵਧਦੇ ਹਨ. ਅਤੇ ਇਹਨਾਂ ਟੇਬਲਾਂ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲੇ ਸਵਾਲ ਹੌਲੀ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਨ, ਕਿਉਂਕਿ ਤੁਹਾਨੂੰ ਮੈਮੋਰੀ ਤੋਂ ਡਿਸਕ ਅਤੇ ਬੈਕ ਤੱਕ ਕਤਾਰਾਂ ਦੇ ਸਾਰੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ ਨੂੰ ਢਾਲਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਲਈ, ਸਮਾਂ, ਸਭ ਤੋਂ ਲੰਬੇ ਲੈਣ-ਦੇਣ ਦੀ ਮਿਆਦ, ਸਭ ਤੋਂ ਲੰਬੇ ਵੈਕਿਊਮ ਬੇਨਤੀਆਂ ਦੀ ਵੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਅਤੇ ਜੇਕਰ ਅਸੀਂ ਕੁਝ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਦੇਖਦੇ ਹਾਂ ਜੋ ਬਹੁਤ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਚੱਲ ਰਹੀਆਂ ਹਨ, ਪਹਿਲਾਂ ਹੀ ਇੱਕ OLTP ਲੋਡ ਲਈ 10-20-30 ਮਿੰਟਾਂ ਤੋਂ ਵੱਧ, ਤਾਂ ਸਾਨੂੰ ਉਹਨਾਂ ਵੱਲ ਧਿਆਨ ਦੇਣ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਜ਼ਬਰਦਸਤੀ ਖਤਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਉਹ ਨਹੀਂ ਬੁਲਾਏ ਜਾਂਦੇ ਹਨ ਅਤੇ ਇੰਨੇ ਲੰਬੇ ਸਮੇਂ ਲਈ ਲਟਕਦੇ ਨਹੀਂ ਹਨ. ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਵਰਕਲੋਡ ਲਈ, 10-20-30 ਮਿੰਟ ਆਮ ਹੁੰਦੇ ਹਨ; ਲੰਬੇ ਵੀ ਹੁੰਦੇ ਹਨ।

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

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

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

ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਕਲਾਇੰਟ ਕਨੈਕਟ ਹੁੰਦਾ ਹੈ, ਇਹ ਕੁਨੈਕਸ਼ਨ ਰੱਖਦਾ ਹੈ, ਪਰ ਕੁਝ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਬੇਕਾਰ ਅਵਸਥਾ ਵਿੱਚ ਹੈ।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ਅਤੇ ਹੁਣ ਤੁਹਾਡੇ ਲਈ ਇੱਕ ਛੋਟਾ ਸਵਾਲ. ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੇ ਡੇਟਾਬੇਸ ਸਰਵਰ 'ਤੇ ਲੋਡ ਦੇਖਦੇ ਹੋ ਤਾਂ ਕਿਹੜਾ ਸਵਾਲ ਪੈਦਾ ਹੁੰਦਾ ਹੈ? ਤੁਹਾਡਾ ਅਗਲਾ ਸਵਾਲ ਕੀ ਹੈ?

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

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

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

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

ਤੁਸੀਂ ਸਭ ਤੋਂ ਲੰਬੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰ ਸਕਦੇ ਹੋ, ਯਾਨੀ ਉਹ ਸਵਾਲ ਜਿਨ੍ਹਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਲੰਬਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ। ਉਹ ਪ੍ਰੋਸੈਸਰ 'ਤੇ ਚੱਲਦੇ ਹਨ, ਉਹ I/O ਦੀ ਖਪਤ ਕਰਦੇ ਹਨ। ਅਸੀਂ ਕੁੱਲ_ਸਮਾਂ, ਮੱਧ_ਸਮਾਂ, blk_write_time ਅਤੇ blk_read_time ਖੇਤਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸਦਾ ਮੁਲਾਂਕਣ ਵੀ ਕਰ ਸਕਦੇ ਹਾਂ।

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

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

ਅਤੇ ਤੁਸੀਂ ਉਹਨਾਂ ਸਵਾਲਾਂ ਦੀ ਨਿਗਰਾਨੀ ਵੀ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਅਸਥਾਈ ਫਾਈਲਾਂ ਜਾਂ ਅਸਥਾਈ ਟੇਬਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।

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

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

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

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

ਇਸ ਦੇ ਅਨੁਸਾਰ, pg_stat_bgwriter ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਖੇਤਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਅਸੀਂ ਚੈਕਪੁਆਇੰਟਾਂ ਦੀ ਗਿਣਤੀ ਦੀ ਨਿਗਰਾਨੀ ਕਰ ਸਕਦੇ ਹਾਂ ਜੋ ਹੋਣਗੀਆਂ। ਅਤੇ ਜੇ ਸਾਡੇ ਕੋਲ ਇੱਕ ਨਿਸ਼ਚਤ ਸਮੇਂ (10-15-20 ਮਿੰਟਾਂ ਵਿੱਚ, ਅੱਧੇ ਘੰਟੇ ਵਿੱਚ), ਉਦਾਹਰਣ ਵਜੋਂ, 3-4-5 ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਚੌਕੀਆਂ ਹਨ, ਤਾਂ ਇਹ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਸਮੱਸਿਆ ਹੋ ਸਕਦੀ ਹੈ. ਅਤੇ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਹੀ ਡੇਟਾਬੇਸ ਵਿੱਚ ਵੇਖਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਸੰਰਚਨਾ ਵਿੱਚ ਵੇਖਣਾ, ਚੈਕਪੁਆਇੰਟਾਂ ਦੀ ਅਜਿਹੀ ਬਹੁਤਾਤ ਦਾ ਕਾਰਨ ਕੀ ਹੈ. ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਕੋਈ ਵੱਡੀ ਰਿਕਾਰਡਿੰਗ ਚੱਲ ਰਹੀ ਹੋਵੇ। ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਵਰਕਲੋਡ ਦਾ ਮੁਲਾਂਕਣ ਕਰ ਸਕਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਵਰਕਲੋਡ ਗ੍ਰਾਫ ਸ਼ਾਮਲ ਕਰ ਚੁੱਕੇ ਹਾਂ। ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਚੈਕਪੁਆਇੰਟ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਟਵੀਕ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾ ਸਕਦੇ ਹਾਂ ਕਿ ਉਹ ਪੁੱਛਗਿੱਛ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਹੁਤ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦੇ ਹਨ।

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

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

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

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

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

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

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

ਸੰਸਕਰਣ 10 ਵਿੱਚ, ਇਸ ਫੰਕਸ਼ਨ ਦਾ ਨਾਮ pg_wal_lsn_diff() ਰੱਖਿਆ ਗਿਆ ਸੀ। ਆਮ ਤੌਰ 'ਤੇ, ਸਾਰੇ ਫੰਕਸ਼ਨਾਂ, ਦ੍ਰਿਸ਼ਾਂ ਅਤੇ ਉਪਯੋਗਤਾਵਾਂ ਵਿੱਚ ਜਿੱਥੇ ਸ਼ਬਦ "xlog" ਪ੍ਰਗਟ ਹੁੰਦਾ ਹੈ, ਇਸਨੂੰ "wal" ਮੁੱਲ ਨਾਲ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਸੀ। ਇਹ ਦ੍ਰਿਸ਼ਾਂ ਅਤੇ ਫੰਕਸ਼ਨਾਂ ਦੋਵਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਇਹ ਅਜਿਹੀ ਨਵੀਨਤਾ ਹੈ।

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

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

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

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

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

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

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

ਅਤੇ ਕੁਝ ਮੁੱਖ ਨੁਕਤੇ:

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

ਜੇ ਤੁਸੀਂ ਇਸ ਵਿਸ਼ੇ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਹਨਾਂ ਲਿੰਕਾਂ ਦੀ ਪਾਲਣਾ ਕਰ ਸਕਦੇ ਹੋ.
http://bit.do/stats_collector - ਇਹ ਅੰਕੜਾ ਕੁਲੈਕਟਰ ਤੋਂ ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼ ਹੈ। ਇੱਥੇ ਸਾਰੇ ਅੰਕੜਾ ਦ੍ਰਿਸ਼ਾਂ ਦਾ ਵੇਰਵਾ ਅਤੇ ਸਾਰੇ ਖੇਤਰਾਂ ਦਾ ਵਰਣਨ ਹੈ। ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਪੜ੍ਹ, ਸਮਝ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰ ਸਕਦੇ ਹੋ। ਅਤੇ ਉਹਨਾਂ ਦੇ ਅਧਾਰ ਤੇ, ਆਪਣੇ ਗ੍ਰਾਫ ਬਣਾਓ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਆਪਣੀ ਨਿਗਰਾਨੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ.

ਉਦਾਹਰਨ ਬੇਨਤੀਆਂ:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

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

ਤੁਹਾਡੇ ਸਵਾਲ

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

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

PS1 ਜੇਕਰ ਤੁਸੀਂ postgres_exporter ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਕਿਹੜਾ ਡੈਸ਼ਬੋਰਡ ਵਰਤ ਰਹੇ ਹੋ? ਉਹਨਾਂ ਵਿੱਚੋਂ ਕਈ ਹਨ। ਉਹ ਪਹਿਲਾਂ ਹੀ ਪੁਰਾਣੇ ਹਨ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਭਾਈਚਾਰਾ ਇੱਕ ਅੱਪਡੇਟ ਕੀਤਾ ਟੈਮਪਲੇਟ ਬਣਾਏਗਾ?

PS2 ਹਟਾਇਆ ਗਿਆ pganalyze ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਮਲਕੀਅਤ SaaS ਪੇਸ਼ਕਸ਼ ਹੈ ਜੋ ਪ੍ਰਦਰਸ਼ਨ ਨਿਗਰਾਨੀ ਅਤੇ ਆਟੋਮੇਟਿਡ ਟਿਊਨਿੰਗ ਸੁਝਾਵਾਂ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੈ।

ਸਿਰਫ਼ ਰਜਿਸਟਰਡ ਉਪਭੋਗਤਾ ਹੀ ਸਰਵੇਖਣ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਹਨ। ਸਾਈਨ - ਇਨ, ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ.

ਤੁਸੀਂ ਕਿਸ ਸਵੈ-ਹੋਸਟਡ ਪੋਸਟਗਰੇਸਕਿੱਲ ਨਿਗਰਾਨੀ (ਡੈਸ਼ਬੋਰਡ ਦੇ ਨਾਲ) ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਮੰਨਦੇ ਹੋ?

• 30,0%ਅਲੈਕਸੀ ਲੇਸੋਵਸਕੀ ਜਾਂ ਜ਼ਬਬਿਕਸ 4.4 ਜਾਂ libzbxpgsql + zabbix libzbxpgsql + zabbix3 ਤੋਂ ਜ਼ੈਬਿਕਸ + ਜੋੜ

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalyze ਇੱਕ ਮਲਕੀਅਤ SaaS ਹੈ - ਮੈਂ ਇਸਨੂੰ ਮਿਟਾ ਨਹੀਂ ਸਕਦਾ 1

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

10 ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਵੋਟ ਕੀਤਾ। 26 ਉਪਭੋਗਤਾ ਬਚੇ ਹੋਏ ਹਨ।

ਸਰੋਤ: www.habr.com