ਬ੍ਰੈਂਡਨ ਗ੍ਰੇਗ ਦੀਆਂ ਪ੍ਰਦਰਸ਼ਨ ਵਿਧੀਆਂ — ਲੇਟੈਂਸੀ ਅਤੇ ਪ੍ਰੋਫਾਈਲਿੰਗ ਲਈ

ਬ੍ਰੈਂਡਨ ਗ੍ਰੇਗ ਦਾ ਢੰਗ ਕਿਵੇਂ ਅਨੁਮਾਨ ਘਟਾਉਂਦਾ ਹੈ

Brendan Gregg ਸਿਸਟਮ ਪ੍ਰਦਰਸ਼ਨ ਵਿਚ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ালী ਆਵਾਜ਼ਾਂ ਵਿਚੋਂ ਇੱਕ ਹਨ, ਖਾਸ ਕਰਕੇ Linux ਤੋਂ ਸਬੰਧਿਤ ਮਾਹੌਲ ਵਿੱਚ। ਉਸਨੇ ਪ੍ਰਚਲਿਤ ਕਿਤਾਬਾਂ ਲਿਖੀਆਂ ਹਨ, ਪ੍ਰਯੋਗਕ ਟੂਲ ਬਣਾਏ ਹਨ, ਅਤੇ—ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਣ—ਅਸਲ ਪ੍ਰੋਡਕਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਸਾਫ਼ ਵਿਧੀਆਂ ਸਾਂਝੀਆਂ ਕੀਤੀਆਂ ਹਨ। ਟੀਮਾਂ ਉਸਦਾ ਅੰਦਾਜ਼ ਇਸ ਲਈ ਅਪਨਾਉਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਇਹ ਦਬਾਅ ਹੇਠ ਕੰਮ ਕਰਦਾ ਹੈ: ਜਦੋਂ ਲੇਟੈਂਸੀ ਵਧਦੀ ਹੈ ਅਤੇ ਹਰ ਕੋਈ ਜਵਾਬ ਚਾਹੁੰਦਾ ਹੈ, ਤੁਹਾਨੂੰ “ਸ਼ਾਇਦ ਇਹ X ਹੈ” ਤੋਂ “ਇਹ ਪੱਕਾ Y ਹੈ” ਤੇ ਘੱਟ ਡਰਾਮੇ ਨਾਲ ਆਉਣ ਦਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ।

“ਪ੍ਰਦਰਸ਼ਨ ਵਿਧੀ” ਦਾ ਅਸਲ ਮਤਲਬ ਕੀ ਹੈ

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

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

• ਸਮੱਸਿਆ ਨੂੰ ਕਿਸੇ ਖਾਸ ਸਰੋਤ, ਸੇਵਾ ਜਾਂ ਕੋਡ ਪਾਥ ਤੱਕ ਘਟਾਉਂਦੀ ਹੈ
• ਖਟਕੇ ਦੇ ਸਮੇ ਦੇ ਓਹਲੇ ਸਮੇਂ-ਖਿੜਕੀ ਵਿਚ ਜੋ ਕੁਝ ਹੋ ਰਿਹਾ ਹੈ ਉਸਦੀ ਮਾਪ ਕਰਦੀ ਹੈ
• ਬਦਲਾਅ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਬੂਤ ਨਾਲ ਬੋਤਲਨੇਕ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ

ਆਮ ਨਾਕਾਮੀ ਦਾ ਤਰੀਕਾ: ਮਾਪਣ ਤੋਂ ਪਹਿਲਾਂ ਠੀਕ ਕਰਨਾ

ਕਈ ਲੇਟੈਂਸੀ ਜਾਂਚ ਪਹਿਲੇ ਪੰਜ ਮਿੰਟਾਂ ਵਿੱਚ ਗਲਤ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਲੋਕ ਸਿੱਧਾ ਫਿਕਸ ਕਰਨ ਲਈ ਕੂਦ ਪੈਂਦੇ ਹਨ: “CPU ਵਧਾਓ,” “ਸੇਵਾ ਰੀਸਟਾਰਟ ਕਰੋ,” “ਕੈਸ਼ ਵਧਾਓ,” “GC ਟਿਊਨ ਕਰੋ,” “ਜ਼ਰੂਰ ਨੈਟਵਰਕ ਹੈ।” ਕਈ ਵਾਰੀ ਏਹ ਕਾਰਵਾਈਆਂ ਮਦਦ ਕਰਦੀਆਂ ਹਨ—ਅਕਸਰ ਇਹ ਸਿਗਨਲ ਨੂੰ ਲੁਕਾਉਂਦੀਆਂ ਹਨ, ਸਮਾਂ ਖ਼ਰਚ ਕਰਦੀਆਂ ਹਨ, ਜਾਂ ਨਵੇਂ ਖਤਰੇ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ।

Gregg ਦੀਆਂ ਵਿਧੀਆਂ ਤੁਹਾਨੂੰ “ਸੋਲੂਸ਼ਨ” ਨੂੰ ਰੋਕਣ ਲਈ ਦਬਾਉਂਦੀਆਂ ਹਨ ਜ਼ਦ ਤੱਕ ਤੁਸੀਂ ਸਧਾਰਨ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੇ: ਕੀ ਸੈਚੁਰੇਟ ਹੈ? ਕੀ ਐਰਰ ਹੋ ਰਹੇ ਹਨ? ਕੀ ਸੁਧਾਰ ਹੋਇਆ—ਥਰੂਪੁੱਟ, ਕਤਾਰ, ਜਾਂ ਇਕੱਲੀ ਪਰਚਾਲਨ?

ਇਹ ਗਾਈਡ ਤੁਹਾਨੂੰ ਕੀ ਕਰਨਾ ਸਿਖਾਏਗੀ

ਇਹ ਗਾਈਡ ਤੁਹਾਨੂੰ ਦਾਇਰਾ ਘਟਾਉਣ, ਸਹੀ संकेत ਮਾਪਣ, ਅਤੇ ਓਪਟਿਮਾਈਜ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬੋਤਲਨੇਕ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ। ਮਕਸਦ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਲੇਟੈਂਸੀ ਅਤੇ ਪ੍ਰੋਫਾਈਲਿੰਗ ਸਮੱਸਿਆਵਾਂ ਦੀ ਜਾਂਚ ਲਈ ਇਕ ਬਣਤਰਵਾਰ ਵਰਕਫਲੋ ਹੈ ਤਾਂ ਜੋ ਨਤੀਜੇ ਕਿਸੇ ਕਿਸਮੇ ਦੀ ਲੱਕ ਨਹੀਂ ਹੋਣ।

ਲੇਟੈਂਸੀ ਬੁਨਿਆਦੀ ਗੱਲਾਂ: ਟਿਊਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਮਾਪਣਾ ਚਾਹੀਦਾ ਹੈ

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

ਥਰੂਪੁੱਟ, ਲੇਟੈਂਸੀ, ਅਤੇ ਐਰਰ ਇਕੱਠੇ ਹਰਕਤ ਕਰਦੇ ਹਨ

ਇਹ ਤਿੰਨ ਸੰਕੇਤ ਐਕਠੇ ਜੁੜੇ ਹੋਏ ਹਨ:

• Throughput (ਰਿਕਵੇਸਟ/ਸੈਕਿੰਡ) ਵਧਣ ਨਾਲ ਕਤਾਰ ਵਧ ਸਕਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਲੇਟੈਂਸੀ ਵਧਦੀ ਹੈ।
• Errors ਦੇ ਨਾਲ ਪ੍ਰेਖਿਆਤ ਲੇਟੈਂਸੀ ਘਟ ਸਕਦੀ ਹੈ (ਤੇਜ਼ ਫੇਲਿਅਰ) ਜਾਂ ਵਧ ਸਕਦੀ ਹੈ (ਰੀਟ੍ਰਾਈਜ਼ ਅਤੇ ਟਾਈਮਆਊਟ)।
• ਥਰੂਪੁੱਟ ਨੂੰ ਸੀਮਿਤ ਕਰਨਾ (ਰੇਟ ਲਿਮਿਟ, ਬੈਕਪ੍ਰੈਸ਼ਰ) ਟੇਲ ਲੇਟੈਂਸੀ ਨੂੰ ਸੁਧਾਰ ਸਕਦਾ ਹੈ ਪਰ ਕਦਾਚਿਤ ਘੱਟ ਰਿਕਵੇਸਟਾਂ ਸਫਲ ਹੋਣ ਦਿੰਦਾ ਹੈ।

ਟਿਊਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਕੋ ਸਮੇਂ ਦੀ ਖਿੜਕੀ ਲਈ ਤਿੰਨੋ ਮਾਪੋ। ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਲੇਟੈਂਸੀ ਨੂੰ "ਥੱਲੇ ਲਿਆਣ" ਲਈ ਕੰਮ ਘਟਾ ਕੇ ਜਾਂ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਫੇਲ ਕਰ ਕੇ ਮੁੱਦਾ ਹੱਲ ਕਰਨ ਦੇ ਜਿਹੇ ਨਤੀਜੇ ਕੱਢ ਸਕਦੇ ਹੋ।

ਔਸਤਾਂ ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ: ਪਰਸੈਂਟਾਈਲ ਤੇ ਟੇਲ ਲੇਟੈਂਸੀ

ਔਸਤ ਲੇਟੈਂਸੀ ਉਹ ਸਪਾਈਕਸ ਛੁਪਾ ਦਿੰਦਾ ਹੈ ਜੋ ਯੂਜ਼ਰ ਯਾਦ ਰੱਖਦੇ ਹਨ। ਇੱਕ ਸੇਵਾ ਜਿਸਦੀ ਔਸਤ 50 ms ਹੋ ਸਕਦੀ ਹੈ ਪਰ ਵਾਰੀ-ਵਾਰੀ 2 s ਦੇ ਸਟਾਲ ਹੋ ਸਕਦੇ ਹਨ।

ਪਰਸੈਂਟਾਈਲ ਨਾਪੋ:

• p50: ਆਮ ਯੂਜ਼ਰ ਅਨੁਭਵ
• p95/p99: ਟੇਲ ਲੇਟੈਂਸੀ (ਜਿੱਥੇ ਜ਼ਿਆਦਾਤਰ ਘਟਨਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ)

ਲੇਟੈਂਸੀ ਦਾ ਆਕਾਰ ਵੀ ਦੇਖੋ: ਜੇ p50 ਸਥਿਰ ਹੈ ਪਰ p99 ਵਧ ਰਿਹਾ ਹੈ ਤਾਂ ਅਕਸਰ ਇਹ ਅੰਤਰਾਇਕ ਸਟਾਲ (ਜਿਵੇਂ ਲਾਕ ਕਂਟੈਂਸ਼ਨ, I/O ਹਿਕਪਸ, stop-the-world ਪੌਜ਼) ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਨਾ ਕਿ ਆਮ ਸੁਸਤਤਾ ਨੂੰ।

ਲੇਟੈਂਸੀ ਬਜਟ: ਸਮਾਂ ਕਿੱਥੇ ਲੱਗ ਸਕਦਾ ਹੈ

ਲੇਟੈਂਸੀ ਬਜਟ ਇੱਕ ਸਧਾਰਨ ਗਿਣਤੀ ਮਾਡਲ ਹੈ: "ਜੇ ਰਿਕਵੇਸਟ 300 ms ਵਿੱਚ ਖਤਮ ਹੋਣੀ ਹੈ, ਤਾਂ ਸਮਾਂ ਕਿੱਥੇ ਬਿਤਾਇਆ ਜਾ ਸਕਦਾ ਹੈ?" ਇਸਨੂੰ ਖੰਡਾਂ ਵਿੱਚ ਵੰਡੋ ਜਿਵੇਂ:

• ਤੁਹਾਡੀ ਸੇਵਾ ਵਿੱਚ ਲੱਗਣ ਵਾਲਾ ਸਮਾਂ (ਕੰਪਿਊਟ + ਉਡੀਕ)
• ਡਾਉਨਸਟਰੀਮ ਸੇਵਾਵਾਂ ਵਿੱਚ ਲੱਗਣ ਵਾਲਾ ਸਮਾਂ
• ਡੇਟਾਬੇਸ/ਕੈਸ਼ ਵਿੱਚ ਲੱਗਣ ਵਾਲਾ ਸਮਾਂ
• ਨੈਟਵਰਕ ਟ੍ਰਾਂਜ਼ਿਟ ਅਤੇ TLS
• ਕਤਾਰ ਵਿੱਚ ਲੱਗਣ ਵਾਲਾ ਸਮਾਂ (ਥ੍ਰੈਡ, ਕਨੈਕਸ਼ਨ ਪੂਲ, ਲੋਡ ਬੈਲੰਸਰ)

ਇਹ ਬਜਟ ਪਹਿਲੀ ਮਾਪਣ ਕਾਰਜ ਨੂੰ ਰੂਪ ਦਿੰਦਾ ਹੈ: ਪSpike ਦੌਰਾਨ ਕਿਸ ਬਕਟ ਨੇ ਵਧਿਆ, ਫਿਰ ਉਸ ਖੇਤਰ ਦੀ ਜਾਂਚ ਕਰੋ ਨਾ ਕਿ ਅੰਧੇਰੇ ਵਿੱਚ ਟਿਊਨ ਕਰੋ।

ਇੱਕ ਸਾਫ਼ ਸਵਾਲ ਅਤੇ ਦਾਇਰਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

ਜੇ "ਸਿਸਟਮ ਧੀਮਾ ਹੈ" ਵਰਗਾ ਵੇਰਵਾ ਹੋਵੇ ਤਾਂ ਲੇਟੈਂਸੀ ਕੰਮ ਘੁੰਮੇਗਾ। Gregg ਦੀਆਂ ਵਿਧੀਆਂ ਪਹਿਲਾਂ ਹੀ ਕਦਮ ਖਿੱਚਦੀਆਂ ਹਨ: ਮੁੱਦੇ ਨੂੰ ਇੱਕ ਖਾਸ, ਟੈਸਟ ਕਰਨ ਯੋਗ ਸਵਾਲ ਵਿੱਚ ਬਦਲੋ।

ਇਹ ਪਤਾ ਕਰੋ ਕਿ "ਧੀਮਾ" ਕਾਹਦਾ ਮਤਲਬ ਹੈ (ਅਤੇ ਕਿਸ ਲਈ)

ਕਿਸੇ ਵੀ ਟੂਲ ਨੂੰ ਛੇੜਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋ ਵਾਕ ਲਿਖੋ:

• ਕੀ ਧੀਮਾ ਹੈ? (ਪੇਜ ਲੋਡ, API ਐਂਡਪੌਇੰਟ, ਬੈਚ ਜ਼ੌਬ, ਲੌਗਿਨ, ਚੈੱਕਆਊਟ, ਇੱਕ ਖਾਸ SQL ਕੁਐਰੀ)
• ਕਿੱਥੇ ਇਹ ਧੀਮਾ ਨਜ਼ਰ ਆ ਰਿਹਾ ਹੈ? (ਗਾਹਕ ਬ੍ਰਾਊਜ਼ਰ, ਮੋਬਾਈਲ ਐਪ, ਇੱਕ ਖੇਤਰ, ਇੱਕ ਪੌਡ, ਇੱਕ ਹੋਸਟ, ਇਕ ਅੰਦਰੂਨੀ ਸੇਵਾ)

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

ਸਮੇਂ ਦੀ ਖਿੜਕੀ ਅਤੇ ਦਾਇਰਾ ਚੁਣੋ

ਉਸ ਸ਼ਿਕਾਇਤ ਨਾਲ ਮਿਲਦੀ ਇੱਕ ਖਿੜਕੀ ਚੁਣੋ ਅਤੇ ਜੇ ਸੰਭਵ ਹੋਵੇ ਇੱਕ “ਚੰਗੇ” ਮੁਕਾਬਲੇ ਯੁਗ ਸ਼ਾਮਿਲ ਕਰੋ।

ਆਪਣੀ ਜਾਂਚ ਦਾ ਦਾਇਰਾ ਵਿਵਰਣ ਕਰੋ:

• ਹੋਸਟ ਵਰਸਸ ਸੇਵਾ ਵਰਸਸ ਐਂਡਪੌਇੰਟ: “ਇੱਕ Kubernetes ਨੋਡ” ਇੱਕ API ਰੂਟ ਤੋਂ ਵੱਖ ਹੈ।
• ਕਿਹੜਾ ਟ੍ਰੈਫਿਕ ਸਲਾਈਸ: ਖੇਤਰ, ਗਾਹਕ ਟੀਅਰ, ਸਿਰਫ ਐਰਰ ਕਰ ਰਹੀਆਂ ਰਿਕਵੇਸਟਾਂ, ਜਾਂ ਸਾਰੀਆਂ ਰਿਕਵੇਸਟਾਂ।
• ਕਿਹੜਾ ਸੰਕੇਤ ਸੂਚਿਤ ਕਰ ਰਿਹਾ ਹੈ: p95 ਲੇਟੈਂਸੀ, ਟਾਈਮਆਊਟ, ਕਤਾਰ ਡੈਪ्थ, ਜਾਂ ਯੂਜ਼ਰ ਟਾਈਮਿੰਗ।

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

ਹਾਲੀਆ ਬਦਲਾਅਾਂ ਨੂੰ ਪਰਿਕਲਪਨ ਬਣਾ ਕੇ ਰੱਖੋ, ਜਵਾਬ ਨਾਂ ਸਮਝੋ

ਡਿਪਲੌਇਜ਼, ਕන්ਫਿਗ ਬਦਲਾਅ, ਟ੍ਰੈਫਿਕ ਵਿੱਚ ਬਦਲਾਅ, ਅਤੇ ਇੰਫਰਾ ਘਟਨਾਵਾਂ ਨੂੰ ਨੋਟ ਕਰੋ—ਪਰ ਕਾਰਨਤਾ ਨ ਮਨੋ। ਉਨ੍ਹਾਂ ਨੂੰ "ਜੇ X, ਤਾਂ ਅਸੀਂ Y ਦੀ ਉਮੀਦ ਕਰਾਂਗੇ" ਵਜੋਂ ਲਿਖੋ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਪੁਸ਼ਟੀ ਜਾਂ ਅਸਵੀਕਾਰ ਕਰ ਸਕੋ।

ਇੱਕ ਹਲਕੀ-ਫੁਲਕੀ ਜਾਂਚ ਲੌਗ ਰੱਖੋ

ਇੱਕ ਛੋਟਾ ਲੌਗ ਟੀਮ-ਵਿੱਚ ਦੁਹਰਾਵਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ ਹਥੌੜਾ-ਹਥੌੜੀਆਂ ਨੂੰ ਹੌਲੀ ਕਰਦਾ ਹੈ।

Time | Question | Scope | Data checked | Result | Next step

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

USE ਵਿਧੀ: ਸਰੋਤ ਬੋਤਲਨੇਕਾਂ ਦੀ ਤੇਜ਼ ਜਾਂਚ

USE ਵਿਧੀ (Utilization, Saturation, Errors) Gregg ਦੀ ਤੇਜ਼ ਚੈਕਲਿਸਟ ਹੈ ਜੋ “ਚਾਰ ਵੱਡੇ” ਸਰੋਤਾਂ—CPU, ਮੈਮੋਰੀ, ਡਿਸਕ (ਸਟੋਰੇਜ), ਅਤੇ ਨੈਟਵਰਕ—ਦਾ ਸਕੈਨ ਕਰਦੀ ਹੈ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਅਨੁਮਾਨ ਰੋਕ ਕੇ ਸਮੱਸਿਆ ਨੂੰ ਹੋਰ ਨਜ਼ਦੀਕ ਲਿਆ ਸਕੋ।

ਇਹ ਕੀ ਹੈ: ਹਰ ਸਰੋਤ ਲਈ ਇੱਕ ਚੈਕਲਿਸਟ

ਦਸ਼ ਹੋਰ ਡੈਸ਼ਬੋਰਡਾਂ 'ਤੇ ਘੂਰਣ ਦੀ ਬਜਾਏ, ਹਰੇਕ ਸਰੋਤ ਲਈ ਇਕੋ ਤਿੰਨ ਸਵਾਲ ਪੁੱਛੋ:

• Utilization: ਇਹ ਵਰਤਮਾਨ ਵਿੱਚ ਕਿੰਨਾ ਬਿਜੀ ਹੈ?
• Saturation: ਕੀ ਕੰਮ ਕਤਾਰ ਵਿੱਚ ਰੁਕ ਰਹੇ ਹਨ (ਕਤਾਰਾਂ, ਉਡੀਕ ਸਮਾਂ), ਭਾਵੇਂ ਉਪਯੋਗਤਾ ਪੂਰੀ ਨਾ ਹੋਵੇ?
• Errors: ਕੀ ਇਹ ਫੇਲ ਹੋ ਰਿਹਾ ਹੈ ਜਾਂ ਰੀਟ੍ਰਾਈ ਕਰ ਰਿਹਾ ਹੈ ਜੋ ਦੇਰੀ ਪੈਦਾ ਕਰਦਾ ਹੈ?

ਨਿਯਮਤ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰਨ ਤੇ, ਇਹ ਇੱਕ ਤੇਜ਼ ਇਨਵੈਂਟਰੀ ਬਣ ਜਾਂਦੀ ਹੈ ਕਿ ਕਿੱਥੇ “ਦਬਾਵ” ਮੌਜੂਦ ਹੈ।

ਅਮਲ ਵਿੱਚ ਇਹ ਕਿਵੇਂ ਵਰਤੇ

CPU ਲਈ, utilization CPU ਬਿਜੀ % ਹੈ, saturation ਰਨ-ਕਿਊ ਤੇ ਦਬਾਅ ਜਾਂ ਥ੍ਰੈਡਾਂ ਦੇ ਚਲਣ ਦੀ ਉਡੀਕ ਵਜੋਂ ਦਿਖਦੀ ਹੈ, ਅਤੇ errors ਵਿੱਚ ਕੰਟੇਨਰਾਂ ਵਿੱਚ ਥਰੌਟਲਿੰਗ ਜਾਂ ਬੁਰੇ ਇੰਟਰਪੱਟ ਸ਼ਾਮਿਲ ਹੋ ਸਕਦੇ ਹਨ।

ਮੈਮੋਰੀ ਲਈ, utilization ਵਰਤੀ ਮੈਮੋਰੀ ਹੈ, saturation paging ਜਾਂ ਬਾਰ-ਬਾਰ GC ਵਜੋਂ ਆ ਸਕਦੀ ਹੈ, ਅਤੇ errors ਅਲੋਕੇਸ਼ਨ ਫੇਲਚ, OOM ਇਵੈਂਟਾਂ ਹੋ ਸਕਦੇ ਹਨ।

ਡਿਸਕ ਲਈ, utilization ਡਿਵਾਈਸ ਬਿਜੀ ਸਮਾਂ ਹੈ, saturation ਕਤਾਰ ਡੈਪਥ ਅਤੇ ਰੀਡ/ਰਾਈਟ ਉਡੀਕ ਹੈ, ਅਤੇ errors I/O ਤਰੁਟੀਆਂ ਜਾਂ ਟਾਈਮਆਊਟ ਹਨ।

ਨੈਟਵਰਕ ਲਈ, utilization throughput ਹੈ, saturation ਡ੍ਰਾਪ/ਕਤਾਰ/ਲੇਟੈਂਸੀ ਹੈ, ਅਤੇ errors ਰੀ-ਟ੍ਰਾਂਸਮਿਟ, ਰੀਸੈਟ, ਜਾਂ ਪੈਕਟ ਲਾਸ ਹਨ।

ਲੇਟੈਂਸੀ ਇਨਸੀਡੈਂਟ ਦੌਰਾਨ ਸਭ ਤੋਂ ਲਾਭਦਾਇਕ ਸੰਕੇਤ

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

USE ਸੇਵਾ ਮੈਟਰਿਕਸ ਦੀ ਤ Ergänzung ਹੈ (ਇਸਦੀ ਥਾਂ ਨਹੀਂ)

ਸੇਵਾ-ਸਤਹ ਮੈਟਰਿਕਸ (ਜਿਵੇਂ ਰਿਕਵੇਸਟ ਲੇਟੈਂਸੀ ਅਤੇ ਐਰਰ ਰੇਟ) ਤੁਹਾਨੂੰ ਪ੍ਰਭਾਵ ਦਸਦੇ ਹਨ। USE ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਅਗਲੇ ਕਿੱਥੇ ਵੇਖਣਾ ਹੈ, ਇਹ ਦਰਸਾਉਂਦੇ ਹੋਏ ਕਿ ਕਿਹੜਾ ਸਰੋਤ ਦਬਾਅ ਵਿੱਚ ਹੈ।

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਲੂਪ ਹੈ:

1. ਯੂਜ਼ਰ ਪ੍ਰਭਾਵ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ (Duration/Errors)
2. USE ਇਨਵੈਂਟਰੀ ਚਲਾਓ
3. ਗਹਿਰਾਈ ਵਾਲੇ ਟੂਲਾਂ (ਪ੍ਰੋਫਾਈਲ, ਟਰੇਸ, ਕਰਨਲ ਸਟੈਟ) ਨਾਲ ਸੰਦੇਹਜਨਕ ਸਰੋਤ ਵਿੱਚ ਜ਼ੂਮ ਕਰੋ

RED ਵਿਧੀ: ਸੇਵਾ-ਪਹਿਲਾਂ ਸੰਕੇਤ ਜੋ ਪ੍ਰਭਾਵ ਦਿਖਾਉਂਦੇ ਹਨ

RED ਵਿਧੀ ਤੁਹਾਨੂੰ ਹੋਸਟ ਗ੍ਰਾਫਾਂ ਵਿੱਚ ਡੁਬਕੀ ਲਗਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਯੂਜ਼ਰ ਅਨੁਭਵ ਨਾਲ ਜੋੜੀ ਰੱਖਦੀ ਹੈ。

• Rate: ਤੁਹਾਡੀ ਸੇਵਾ ਜਾਂ ਐਂਡਪੌਇੰਟ ਕਿੰਨੇ ਰਿਕਵੇਸਟ/ਸੈਕਿੰਡ ਹੰਢਾ ਰਹੀ ਹੈ
• Errors: ਕਿੰਨੀਆਂ ਰਿਕਵੇਸਟ ਫੇਲ ਹੋ ਰਹੀਆਂ ਹਨ (ਅਤੇ ਤੁਹਾਡੇ ਐਪ ਲਈ ਫੇਲ ਕੀ ਮਤਲਬ ਹੈ)
• Duration: ਸਫਲ ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਲੱਗਣ ਵਾਲਾ ਸਮਾਂ (ਔਸਤਾਂ ਨਹੀ, ਪਰਸੈਂਟਾਈਲਾਂ ਵਜੋਂ ਟਰੈਕ ਕਰੋ)

RED ਤੁਹਾਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦੇਣ ਵਿੱਚ ਕਿਵੇਂ ਮਦਦ ਕਰਦਾ ਹੈ

RED ਤੁਹਾਨੂੰ "ਦਿਲਚਸਪ" ਸਿਸਟਮ ਮੈਟ੍ਰਿਕਸ ਦੇ ਪਿੱਛੇ ਨਹੀਂ ਭੱਜਣ ਦਿੰਦਾ ਜੋ ਯੂਜ਼ਰਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦੇ। ਇਹ ਸੰਕੁਚਿਤ ਲੂਪ ਤਿਆਰ ਕਰਦਾ ਹੈ: ਕਿਹੜਾ ਐਂਡਪੌਇੰਟ ਧੀਮਾ ਹੈ, ਕਿਸ ਗਾਹਕ ਲਈ, ਅਤੇ ਕਦੋਂ ਤੋਂ? ਜੇ Duration ਸਿਰਫ਼ ਇੱਕ ਰੂਟ 'ਤੇ spike ਕਰ ਰਿਹਾ ਹੈ ਜਦਕਿ ਕੁੱਲ CPU ਸਥਿਰ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਇੱਕ ਤੇਜ਼ ਸ਼ੁਰੂਆਤ ਹੈ।

ਇਕ ਲਾਭਦਾਇਕ ਆਦੀਅਤ: RED ਨੂੰ ਸੇਵਾ ਅਤੇ ਟੌਪ ਐਂਡਪੌਇੰਟ ਦੁਆਰਾ ਤੋੜ ਕੇ ਰੱਖੋ। ਇਹ ਵੱਡੀ ਖਰਾਬੀ ਨੂੰ ਲੋਕੇਲ ਰਿਗਰੇਸ਼ਨ ਤੋਂ ਵੱਖ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।

RED ਲੱਛਣਾਂ ਨੂੰ USE ਚੈੱਕ ਨਾਲ ਨਕਸ਼ਾਬੱਧ ਕਰੋ

RED ਦੱਸਦਾ ਹੈ ਕਿੱਥੇ ਦਰਦ ਹੈ। USE ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ ਇਹ ਪਰਖਣ ਵਿੱਚ ਕਿਹੜਾ ਸਰੋਤ ਜ਼ਿੰਮੇਵਾਰ ਹੈ।

ਉਦਾਹਰਨਾਂ:

• Duration ਉੱਪਰ + Rate ਸਥਿਰ → saturation/ਕਤਾਰ ਦੀ ਜਾਂਚ ਕਰੋ: CPU ਰਨ ਕਿਊ, ਸਟੋਰੇਜ ਲੇਟੈਂਸੀ, DB ਕੁਨੈਕਸ਼ਨ ਪੂਲ।
• Errors ਉੱਪਰ + Duration ਉੱਪਰ → ਟਾਈਮਆਊਟ ਅਤੇ ਰੀਟ੍ਰਾਈ ਦੀ ਜਾਂਚ ਕਰੋ: ਓਵਰਲੋਡਡ ਡਾਉਨਸਟਰੀਮ, ਥ੍ਰੈਡ ਪੂਲ, ਨੈਟਵਰਕ ਡ੍ਰਾਪਸ।
• Rate ਉੱਪਰ + Duration ਉੱਪਰ → ਸਮਰੱਥਾ ਸੀਮਾਵਾਂ ਦੀ ਜਾਂਚ: CPU ਉਪਯੋਗਤਾ, ਲੋਡ ਬੈਲੰਸਰ ਵਿਹਿਵਾਰ, ਆਟੋਸਕੇਲਿੰਗ ਦੇ ਦੇਰੀ।

ਇੱਕ ਨਿਊਨਤਮ “ਕੀ ਬਦਲਿਆ?” ਡੈਸ਼ਬੋਰਡ

ਲੇਆਉਟ ਸਧਾਰਨ ਰੱਖੋ:

1. RED ਓਵਰਵਿਊ: Rate, Errors, ਅਤੇ ਸੇਵਾ ਲਈ p50/p95/p99 Duration。
2. ਟੌਪ ਐਂਡਪੌਇੰਟ: ਹਰ ਐਂਡਪੌਇੰਟ ਲਈ ਉਹੀ RED ਸੰਕੇਤ, ਟ੍ਰੈਫਿਕ ਜਾਂ ਸਭ ਤੋਂ ਖ਼ਰਾਬ p95 ਅਨੁਸਾਰ ਸਾਰਟ ਕੀਤੇ।
3. ਡਿਪੈਂਡੈਂਸੀਜ਼: ਮੁੱਖ ਡਾਊਨਸਟਰੀਮਾਂ ਲਈ RED-ਸਟਾਈਲ ਪੈਨਲ (DB, cache, ਬਾਹਰੀ APIs)。
4. ਇੱਕ ਕੋਰਲੇਸ਼ਨ ਰੋ: ਕਈ ਸਿਸਟਮ ਮੈਟ੍ਰਿਕਸ (CPU, ਮੈਮੋਰੀ ਪ੍ਰੈਸ਼ਰ, ਡਿਸਕ I/O ਲੇਟੈਂਸੀ, ਨੈਟਵਰਕ ਰੀ-ਟ੍ਰਾਂਸਮਿਟਸ) ताकि ਸੇਵਾ ਵਿਊ ਤੋਂ ਰੂਟ ਕਾਰਨ ਤੱਕ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਜਾਇਆ ਜਾ ਸਕੇ。

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

ਤਰਜੀਹ: ਅਗਲਾ ਸਭ ਤੋਂ ਵਧੀਆ ਸਵਾਲ ਚੁਣੋ

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

ਬੋਤਲਨੇਕਾਂ ਲਈ 80/20 ਨਿਯਮ

ਅਕਸਰ ਲੇਟੈਂਸੀ ਸਮੱਸਿਆਵਾਂ ਇੱਕ ਮੁੱਖ ਲਾਗਤ (ਜਾਂ ਛੋਟੀ ਜੋੜੀ) ਦੁਆਰਾ доминиਟ ਹੁੰਦੀਆਂ ਹਨ: ਇੱਕ ਗਰਮ ਲਾਕ, ਇੱਕ ਧੀਮਾ ਡਿਪੈਂਡੈਂਸੀ, ਇੱਕ ਓਵਰਲੋਡਡ ਡਿਸਕ, ਇੱਕ GC ਪੌਜ਼ ਪੈਟਰਨ। ਤਰਜੀਹ ਦਾ ਮਤਲਬ ਹੈ ਉਸ ਮੁੱਖ ਲਾਗਤ ਦੀ ਖੋਜ ਪਹਿਲਾਂ ਕਰੋ, ਕਿਉਂਕਿ ਕਈ ਥਾਂ ਤੋਂ 5% ਘਟਾਉਣਾ ਆਮ ਤੌਰ ਤੇ ਯੂਜ਼ਰ-ਦਿੱਖਦੇ ਲੇਟੈਂਸੀ ਨੂੰ ਮਹੱਤਵਪੂਰਣ ਤੌਰ 'ਤੇ ਬਦਲਦਾ ਨਹੀਂ।

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਟੈਸਟ: “ਕੀ ਕੁਝ ਵੱਡੇ ਹਿੱਸੇ ਨੂੰ ਸਮਝਾ ਸਕਦਾ ਹੈ ਜੋ ਅਸੀਂ ਦੇਖ ਰਹੇ ਲੇਟੈਂਸੀ ਤਬਦੀਲੀ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਹੈ?” ਜੇ ਕੋਈ ਪਰਿਕਲਪਨਾ ਕੇਵਲ ਇੱਕ ਛੋਟਾ ਹਿੱਸਾ ਸਮਝਾ ਸਕਦੀ ਹੈ, ਤਾਂ ਉਹ ਘੱਟ ਪ੍ਰਾਥਮਿਕਤਾ ਵਾਲੀ ਹੈ।

###ਟਾਪ-ਡਾਊਨ vs ਬਾਟਮ-ਅਪ: ਕਿੱਥੇ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ

ਟਾਪ-ਡਾਊਨ ਵਰਤੋਂ ਕਰੋ ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਪੁੱਛ ਰਹੇ ਹੋ "ਕੀ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵਿਤ ਹਨ?" ਐਂਡਪੌਇੰਟ (RED-ਸਟਾਈਲ ਸੰਕੇਤ) ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ: ਲੇਟੈਂਸੀ, ਥਰੂਪੁੱਟ, ਐਰਰ। ਇਹ ਤੁਹਾਨੂੰ ਅਹਿਸਾਸ ਕਰਵਾਏਗਾ ਕਿ ਤੁਸੀਂ ਕਿਸ ਰਸਤੇ ਨੂੰ ਓਪਟਿਮਾਈਜ਼ ਕਰ ਰਹੇ ਹੋ।

ਬਾਟਮ-ਅਪ ਵਰਤੋਂ ਕਰੋ ਜਦੋਂ ਹੋਸਟ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਬਿਮਾਰ ਹੋ (USE ਨਿਸ਼ਾਨ): CPU ਸੈਚੁਰੇਸ਼ਨ, ਰਨਵੇਅ ਮੈਮੋਰੀ ਪ੍ਰੈਸ਼ਰ, I/O ਵੇਟ। ਜੇ ਇੱਕ ਨੋਡ ਪੱਗਡ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਐਂਡਪੌਇੰਟ ਪਰਸੈਂਟਾਈਲਾਂ 'ਤੇ ਘੂਰ ਕੇ ਵਕਤ ਖਰਾਬ ਕਰੋਗੇ ਬਿਨਾਂ ਪਤਾ ਲੱਗੇ ਕਿ ਸੀਮਾ ਕੀ ਹੈ।

ਥਰੈਸ਼ ਰੋਕਣ ਲਈ ਇੱਕ ਸਧਾਰਨ ਫੈਸਲਾ ਦਰੱਖਤ

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

• ਲੇਟੈਂਸੀ ਸਪਾਈਕ + ਐਰਰ ਸਪਾਈਕ → “ਕੀ ਇਹ ਡਿਪੈਂਡੈਂਸੀ ਹੈ ਜਾਂ ਸਮਰੱਥਾ ਘਟਨਾ?” (ਟਾਈਮਆਊਟ, ਕਨੈਕਸ਼ਨ ਪੂਲ ਖ਼ਤਮ ਹੋਣਾ, ਡਾਊਨਸਟਰੀਮ 5xx)
• ਲੇਟੈਂਸੀ ਸਪਾਈਕ + CPU ਸਪਾਈਕ → “CPU ਲਾਗੂ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਫਸਿਆ ਹੈ?” (on-CPU vs off-CPU ਸਮਾਂ)
• ਲੇਟੈਂਸੀ ਸਪਾਈਕ + ਉੱਚ I/O ਵੇਟ → “ਕਿਹੜਾ ਡਿਵਾਈਸ ਜਾਂ ਫਾਇਲਸਿਸਟਮ ਕਤਾਰ ਹੋ ਰਿਹਾ ਹੈ?”
• ਰੇਟ ਬਿਨਾਂ ਸਰੋਤ ਸਪਾਈਕ ਦੇ ਲੇਟੈਂਸੀ ਸਪਾਈਕ → “ਸਮਾਂ ਕਿੱਥੇ ਉਡੀਕ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ?” (ਲਾਕ, ਸ਼ੈਡਿਊਲਰ, ਨੈਟਵਰਕ, ਰਿਮੋਟ ਕਾਲ)

ਮੈਟ੍ਰਿਕ ਓਵਰਲੋਡ ਤੋਂ ਬਚੋ, ਵਿਵਸਥਿਤ ਰਹੋ

ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਛੋਟੇ ਸ਼ੁਰੂਆਤੀ ਸੰਕੇਤ ਸੈੱਟ ਤੱਕ ਸੀਮਤ ਰੱਖੋ, ਫਿਰ ਕੇਵਲ ਜਦੋਂ ਕੁਝ ਹਿਲਦਾ ਹੈ ਤਾਂ ਡ੍ਰਿਲ ਡਾਊਨ ਕਰੋ। ਜੇ ਤੁਹਾਨੂੰ ਫੋਕਸ ਰੱਖਣ ਲਈ ਚੈਕਲਿਸਟ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਆਪਣੇ ਕਦਮਾਂ ਨੂੰ ਇੱਕ ਰਨਬੁੱਕ ਦੀ ਤਰ੍ਹਾਂ ਲਿੰਕ ਕਰੋ ਜਿਵੇਂ /blog/performance-incident-workflow ਤਾਂ ਕਿ ਹਰ ਨਵੇਂ ਮੈਟ੍ਰਿਕ ਦਾ ਇੱਕ ਮਕਸਦ ਹੋਵੇ: ਇੱਕ ਖਾਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣਾ।

ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਪ੍ਰੋਫਾਈਲਿੰਗ ਬਿਨਾਂ ਸਿਸਟਮ ਡਾਊਨ ਕੀਤੇ

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

ਪ੍ਰੋਫਾਈਲਿੰਗ ਦਾ ਅਸਲ ਉੱਤਰ

ਪ੍ਰੋਫਾਈਲਿੰਗ ਇੱਕ “ਸਮਾਂ ਬਜਟ” ਟੂਲ ਹੈ। ਥਿਊਰੀਆਂ ਦੀ ਬਜਾਏ (“ਡੇਟਾਬੇਸ ਹੈ” vs “GC ਹੈ”), ਤੁਸੀਂ ਮਨ ਆਉਂਦੀਆਂ ਤੱਥ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ ਜਿਵੇਂ "CPU ਸੈਂਪਲਾਂ ਦਾ 45% JSON ਪարսਿੰਗ ਵਿੱਚ ਸੀ" ਜਾਂ "ਜ਼ਿਆਦਾਤਰ ਰਿਕਵੇਸਟ ਇੱਕ ਮਿਊਟੈਕਸ 'ਤੇ ਰੁਕੀ ਹੋਈ ਸੀ"। ਇਹ ਅਗਲੇ ਕਦਮ ਨੂੰ ਇੱਕ-ਦੋ ਸਪੱਸ਼ਟ ਫਿਕਸਾਂ ਤੱਕ ਸੀਮਤ ਕਰ ਦਿੰਦਾ ਹੈ।

ਆਮ ਕਿਸਮਾਂ ਜੋ ਤੁਸੀਂ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਵਰਤ ਸਕਦੇ ਹੋ

• CPU ਪ੍ਰੋਫਾਈਲਿੰਗ: ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕੋਡ on-CPU ਕਿੱਥੇ ਚੱਲ ਰਿਹਾ ਹੈ।
• Off-CPU (wait) ਪ੍ਰੋਫਾਈਲਿੰਗ: ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਥ੍ਰੈਡ ਕਿੱਥੇ ਬਲੌਕ ਹੋਏ ਹਨ (I/O ਉਡੀਕ, ਸ਼ੈਡਿਊਲਰ ਡਿਲੇ, sleep, ਨੈਟਵਰਕ, ਡਿਸਕ)।
• ਲਾਕ ਪ੍ਰੋਫਾਈਲਿੰਗ: ਕੰਟੈਂਸ਼ਨ ਦਿਖਾਉਂਦੀ ਹੈ—ਲਾਕਾਂ ਦੇ ਲਈ ਖੋਇਆ ਸਮਾਂ।

ਹਰੇਕ ਇੱਕ ਵੱਖਰਾ ਸਵਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਘੱਟ CPU ਹੋਣ ਦੇ ਨਾਲ ਵਧੇਰੀ ਲੇਟੈਂਸੀ ਆਮ ਤੌਰ 'ਤੇ off-CPU ਜਾਂ ਲਾਕ ਸਮੇਂ ਪਹਿਲਾ ਦਿਖਾਉਂਦਾ ਹੈ ਨਾ ਕਿ CPU ਹੌਟਸਪੌਟ।

ਸਦਾ-ਚੱਲਣਾ vs ਡਿਮਾਂਡ ਤੇ

• ਸਦਾ-ਚੱਲਣ ਵਾਲੀ ਪ੍ਰੋਫਾਈਲਿੰਗ (ਲੋ-ਓਵਰਹੈੱਡ) ਉਹ ਮਸਲੇ ਜੋ 3am 'ਤੇ ਹੋਏ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਪਿੱਛੇ ਮਾਰ ਸਕਦੇ ਹੋ।
• ਡਿਮਾਂਡ-ਅਧਾਰਿਤ ਪ੍ਰੋਫਾਈਲਿੰਗ ਟਾਰਗੇਟ ਕੀਤਾ ਕੈਪਚਰ ਹੈ ਸਪਾਈਕ ਦੌਰਾਨ। ਇਹ ਅਪਣਾਉਣਾ ਅਸਾਨ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਇਸਨੂੰ ਟਰਿਗਰ ਕਰਨ ਲਈ ਤਿਆਰ ਰਹਿਣਾ ਪੈਂਦਾ ਹੈ।

ਕਈ ਟੀਮਾਂ ਡਿਮਾਂਡ-ਅਧਾਰਿਤ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ, ਫਿਰ ਜਦੋਂ ਉਹ ਸੁਰੱਖਿਆ 'ਤੇ ਭਰੋਸਾ ਕਰ ਲੈਂਦੀਆਂ ਹਨ ਅਤੇ ਮੁੜ-ਰੁਝਾਨਾਂ ਵੇਖਦੀਆਂ ਹਨ ਤਾਂ ਸਦਾ-ਚੱਲਣ ਵਾਲੇ ਫੇਜ਼ 'ਤੇ ਚਲੇ ਜਾਂਦੀਆਂ ਹਨ।

ਸੁਰੱਖਿਆ: ਓਵਰਹੈੱਡ, ਸੈਂਪਲਿੰਗ, ਅਤੇ ਛੋਟੇ ਵਿੰਡੋ

ਪ੍ਰੋਡਕਸ਼ਨ-ਸੁਰੱਖਿਅਤ ਪ੍ਰੋਫਾਈਲਿੰਗ ਦਾ ਮਤਲਬ ਲਾਗਤ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨਾ ਹੈ। ਸੈਂਪਲਿੰਗ ਨੂੰ ਤਰਜੀਹ ਦਿਓ (ਹਰ ਇਵੈਂਟ ਨੂੰ ਨਾਂ ਟ੍ਰੇਸ ਕਰੋ), ਕੈਪਚਰ ਵਿੰਡੋ ਛੋਟੀ ਰੱਖੋ (ਉਦਾਹਰਨ ਲਈ 10–30 ਸੈਕਿੰਡ), ਅਤੇ ਪਹਿਲਾਂ ਕੈਨਰੀ 'ਤੇ ਓਵਰਹੈੱਡ ਮਾਪੋ। ਜੇ ਤੁਸੀਂ ਅਣਛੁਹੇ ਹੋ, ਘੱਟ-ਫ੍ਰੈਕਵੈਂਸੀ ਸੈਂਪਲਿੰਗ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਸਿਰਫ ਜਦੋਂ ਸਿਗਨਲ ਬਹੁਤ ਸ਼ੋਰ ਕਰੇ ਤਾਂ ਵਧਾਓ।

ਫਲੇਮ ਗ੍ਰਾਫ: ਇਸਨੂੰ ਕਿਵੇਂ ਪੜ੍ਹਨਾ ਹੈ ਅਤੇ ਗਲਤ ਨਤੀਜਿਆਂ ਤੋਂ ਬਚਨਾ

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

ਫਲੇਮ ਗ੍ਰਾਫ ਕੀ ਦਿਖਾਉਂਦੇ ਹਨ (ਅਤੇ ਕੀ ਨਹੀਂ)

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

ਇਹ ਸਿੱਧਾ ਡਿਸਕ, ਨੈਟਵਰਕ, ਸ਼ੈਡਿਊਲਰ ਦੇ ਵਿਲੰਬ, ਜਾਂ ਮਿਊਟੈਕਸ ਉੱਤੇ ਬਲੌਕ ਹੋਣ ਨੂੰ ਨਹੀਂ ਦਿਖਾਉਂਦੇ (ਉਹ off-CPU ਸਮਾਂ ਹੈ ਅਤੇ ਵੱਖਰੀ ਪ੍ਰੋਫ਼ਾਈਲਿੰਗ ਦੀ ਲੋੜ ਹੋਵੇਗੀ)। ਇਹ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ ਕਿ ਯੂਜ਼ਰ-ਦੇਖੀ ਲੇਟੈਂਸੀ ਲਈ ਇਹੀ ਕਾਰਨ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਇਸਨੂੰ ਖਾਸ ਲੱਛਣ ਨਾਲ ਜੋੜਦੇ ਨਹੀਂ।

ਚੌੜਾਈ ਅਤੇ ਸਟੈਕ ਗਹਿਰਾਈ ਪੜ੍ਹਨਾ

• ਚੌੜਾਈ: ਕਿੰਨੀ ਵਾਰੀ ਉਹ ਫਰੇਮ ਸੈਂਪਲਾਂ ਵਿੱਚ ਆਇਆ। ਵੱਡੀ ਚੌੜਾਈ ਆਮ ਤੌਰ 'ਤੇ “ਜ਼ਿਆਦਾ CPU ਸਮਾਂ” ਦੱਸਦੀ ਹੈ, ਪਰ ਸਿਰਫ਼ ਦਿੱਖੇ ਸਮੇਂ ਵਿਂਡੋ ਵਿਚ।
• ਸਟੈਕ ਡੈੱਪਥ: ਕਾਲ ਡੈੱਪਥ। ਡੀਪ ਸਟੈਕ ਆਪ ਵਿੱਚ ਖਰਾਬ ਨਹੀਂ ਹਨ; ਮਹੱਤਵਪੂਰਨ ਇਹ ਹੈ ਕਿ ਕਿਹੜੇ ਰਸਤੇ ਹਕ dominੇ ਹਨ ਅਤੇ ਕੀ ਉਹ ਤੁਹਾਡੇ ਕੰਮ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ।

ਆਮ ਫੰਦੇ ਜਿਨ੍ਹਾਂ ਤੋਂ ਬਚਣਾ

ਸਭ ਤੋਂ ਵੱਡੇ ਬਾਕਸ ਨੂੰ ਦੋਸ਼ੀ ਕਰਨ ਦਾ ਲਾਲਚ ਹੈ, ਪਰ ਪੁੱਛੋ: ਕੀ ਇਹ ਇੱਕ ਐਸਾ ਹੌਟਸਪੌਟ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਬਦਲ ਸਕਦੇ ਹੋ, ਜਾਂ ਸਿਰਫ "malloc, GC, ਜਾਂ ਲੌਗਿੰਗ" ਵਿੱਚ ਸਮਾਂ ਬਿਤਾਇਆ ਜਾ ਰਿਹਾ ਹੈ ਕਿਉਂਕਿ ਅਸਲ ਮੁੱਦਾ ਅੱਗੇ ਹੈ? JIT,Inlining, symbols ਦੀ ਘਾਟ ਵੀ ਸੰਦਰਭ ਗੁੰਮ ਕਰ ਸਕਦੀ ਹੈ ਜਿਸ ਨਾਲ ਕੋਈ ਬਾਕਸ ਦੋਸ਼ੀ ਦਿਖਾਈ ਦੇਵੇ ਪਰ ਅਸਲ ਪੈਣੇਸਰ ਹੋਰ ਹੋਵੇ।

ਫਲੇਮ ਗ੍ਰਾਫ ਨੂੰ ਇੱਕ ਖਾਸ ਸਵਾਲ ਨਾਲ ਜੋੜੋ

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

Off-CPU ਸਮਾਂ: ਲੇਟੈਂਸੀ ਦਾ ਓੁਹ ਛੁਪਿਆ ਸਰੋਤ

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

CPU% ਅਕੇਲਾ ਕਿਉਂ ਭਰਮ ਪੈਦਾ ਕਰਦਾ ਹੈ

CPU% ਇਹ ਜਵਾਬ ਦਿੰਦਾ ਹੈ "ਪ੍ਰੋਸੈਸਰ ਕਿੰਨਾ ਵਿਅਸਤ ਹੈ?" ਇਹ ਨਹੀਂ ਦੱਸਦਾ "ਮੇਰੀ ਰਿਕਵੇਸਟ ਦਾ ਸਮਾਂ ਕਿੱਥੇ ਗੁਜਰਿਆ?" ਰਿਕਵੇਸਟਾਂ ਤੁਰੰਤ ਰੋਕ ਜਾਂ ਸਕਦੀਆਂ ਹਨ ਜਦ ਥ੍ਰੈਡ ਉਡੀਕ ਕਰ ਰਹੇ ਹਨ, ਬਲੌਕ ਹਨ, ਜਾਂ ਸ਼ੈਡਿਊਲਰ ਦੁਆਰਾ ਪਾਰਕ ਕੀਤੇ ਗਏ ਹਨ।

ਮੁੱਖ ਧਾਰਣਾ: ਇੱਕ ਰਿਕਵੇਸਟ ਦਾ ਵॉल-ਕਲਾਕ ਸਮਾਂ ਦੋ ਹਿੱਸਿਆਂ ਵਿੱਚ ਹੁੰਦਾ ਹੈ: on-CPU ਕੰਮ ਅਤੇ off-CPU ਉਡੀਕ।

ਆਮ off-CPU ਦੋਸ਼ੀ

Off-CPU ਸਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਡਿਪੈਂਡੈਂਸੀਜ਼ ਅਤੇ ਕੰਟੈਂਸ਼ਨ ਦੇ ਪਿੱਛੇ ਛੁਪਿਆ ਹੁੰਦਾ ਹੈ:

• ਡਿਸਕ I/O: ਸਿੰਕਰੋਨ ਰੀਡ/ਰਾਈਟ, fsyncs, ਧੀਮਾ ਸਟੋਰੇਜ, ਪੇਜ ਕੈਸ਼ ਮਿਸ।
• ਨੈਟਵਰਕ ਉਡੀਕ: DNS ਲੁੱਕਅੱਪ, TCP ਰੀ-ਟ੍ਰਾਂਸਮਿਟਸ, ਓਵਰਲੋਡਡ ਅੱਪਸਟਰੀਮ ਸੇਵਾਵਾਂ।
• ਲਾਕ ਅਤੇ ਮਿਊਟੈਕਸ ਕੰਟੈਂਸ਼ਨ: ਥ੍ਰੈਡਾਂ ਦਾ ਲਾਕਾਂ 'ਤੇ ਰੁਕਣਾ।
• ਕਤਾਰਬੰਦੀ: ਥ੍ਰੈਡ ਪੂਲ, ਕਨੈਕਸ਼ਨ ਪੂਲ, ਜਾਂ ਅੰਦਰੂਨੀ ਵਰਕ ਕਤਾਰਾਂ ਵਿੱਚ ਉਡੀਕ।

ਦੇਖਣ ਯੋਗ ਲੱਛਣ

ਕੁਝ ਸੰਕੇਤ ਅਕਸਰ off-CPU ਬੋਤਲਨੇਕਾਂ ਨਾਲ ਸਮੰਬੰਧਿਤ ਹੁੰਦੇ ਹਨ:

• ਵਧਦੀ ਕਤਾਰ ਸਮਾਂ (ਰਿਕਵੇਸਟਾਂ ਜਿਨ੍ਹਾਂ ਨੇ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਉਡੀਕ ਕੀਤੀ)
• ਵਧਦੇ ** runnable threads ** (CPU ਲਈ ਹੋਰ ਮੁਕਾਬਲਾ)
• ਉੱਚ I/O wait ਅਤੇ ਲੰਮੇ ਡਿਸਕ/ਨੈਟਵਰਕ ਲੇਟੈਂਸੀ

ਇਹ ਸੰਕੇਤ ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਨ "ਅਸੀਂ ਉਡੀਕ ਕਰ ਰਹੇ ਹਾਂ," ਪਰ ਇਹ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਕਿਹੜੇ ਉੱਤੇ।

off-CPU ਪ੍ਰੋਫਾਈਲਿੰਗ ਕਿਵੇਂ ਦੱਸਦੀ ਹੈ "ਸਮਾਂ ਕਿੱਥੇ ਗਿਆ"

Off-CPU ਪ੍ਰੋਫਾਈਲਿੰਗ ਉਸ ਕਾਰਨ ਨੂੰ ਨਿਰਧਾਰਿਤ ਕਰਦੀ ਹੈ ਜਿਸ ਕਰਕੇ ਤੁਸੀਂ ਚੱਲ ਨਹੀਂ ਰਹੇ: syscalls ਵਿੱਚ ਬਲੌਕ, ਲਾਕਾਂ ਦੀ ਉਡੀਕ, sleep, ਜਾਂ descheduled ਹੋਣਾ। ਇਹ ਲੇਟੈਂਸੀ ਕੰਮ ਲਈ ਤਾਕਤਵਰ ਹੈ ਕਿਉਂਕਿ ਇਹ ਅਣਜਾਣ ਮੰਦੀਆਂ ਨੂੰ ਕਾਰਰੂਪ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ: "ਮਿਊਟੈਕਸ X 'ਤੇ ਰੁਕਿਆ", "disk read() 'ਤੇ ਉਡੀਕ", ਜਾਂ "upstream ਨਾਲ connect() 'ਚ ਫਸਿਆ"। ਜਿਵੇਂ ਹੀ ਤੁਸੀਂ ਉਡੀਕ ਨੂੰ ਨਾਮ ਦੇ ਸਕਦੇ ਹੋ, ਤੁਸੀਂ ਉਸਨੂੰ ਮਾਪ ਸਕਦੇ ਹੋ, ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਠੀਕ ਕਰ ਸਕਦੇ ਹੋ।

ਬੋਤਲਨੇਕ ਨੂੰ ਅਨੁਮਾਨ ਨਹੀਂ, ਸਬੂਤ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ

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

ਬੋਤਲਨੇਕ, ਹੌਟਸਪੌਟ, ਅਤੇ ਸ਼ੋਰ

ਇੱਕ ਬੋਤਲਨੇਕ ਉਹ ਸਰੋਤ ਜਾਂ ਕੰਪੋਨੈਂਟ ਹੈ ਜੋ ਵਰਤਮਾਨ ਵਿੱਚ throughput ਨੂੰ ਸੀਮਿਤ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਲੇਟੈਂਸੀ ਚਲਾਉਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਹਟਾ ਦਿੰਦੇ ਹੋ, ਯੂਜ਼ਰ ਸੁਧਾਰ ਦੇਖਦੇ ਹਨ।

ਇੱਕ ਹੌਟਸਪੌਟ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਸਮਾਂ ਬਿਤਾਇਆ ਜਾ ਰਿਹਾ ਹੈ (ਉਦਾਹਰਣ ਵਜੋਂ, ਪ੍ਰੋਫ਼ਾਈਲ ਵਿੱਚ ਇੱਕ ਫਂਕਸ਼ਨ ਜੋ ਅਕਸਰ ਦਿਖਾਈ ਦੇਂਦਾ ਹੈ)। ਹੌਟਸਪੌਟ ਅਸਲੇ ਬੋਤਲਨੇਕ ਹੋ ਸਕਦੇ ਹਨ—ਜਾਂ ਸਿਰਫ਼ ਵਰਕ ਜੋ ਧੀਮੇ ਰਸਤੇ ਤੇ ਪ੍ਰਭਾਵ ਨਹੀਂ ਪਾਂਦਾ।

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

ਤੁਲਨਾ ਅਤੇ ਨਿਯੰਤਰਿਤ ਬਦਲਾਅ ਨਾਲ ਸਾਬਿਤ ਕਰੋ

ਇੱਕ ਸਾਫ਼ ਪਹਿਲਾਂ ਸ്നੈਪਸ਼ਾਟ ਲਓ: ਯੂਜ਼ਰ-ਨੇ-ਦੇਖਿਆ ਮੁੱਦਾ (ਲੇਟੈਂਸੀ ਜਾਂ ਐਰਰ ਰੇਟ) ਅਤੇ ਮੁੱਖ ਸੰਦੇਹਜਨਕ ਸੰਕੇਤ (CPU ਸੈਚੁਰੇਸ਼ਨ, ਕਤਾਰ ਡੈਪਥ, ਡਿਸਕ I/O, ਲਾਕ ਕੰਟੈਂਸ਼ਨ ਆਦਿ)। ਫਿਰ ਇਕ ਨਿਯੰਤਰਿਤ ਬਦਲਾਅ ਲਗਾਓ ਜੋ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਸੰਦੇਹਜਨਕ ਕਾਰਨ 'ਤੇ ਅਸਰ ਕਰੇ।

ਕੁਝ ਕਾਰਨਾਤਮਕ ਟੈਸਟਾਂ ਦੇ ਉਦਾਹਰਨ:

• ਸੰਦੇਹਜਨਕ ਸਰੋਤ ਨੂੰ ਹੋਰ ਸਮਰੱਥਾ ਦਿਓ (ਇੱਕ ਹੋਰ ਵਰਕਰ, ਵਧੇਰੇ CPU ਸ਼ੇਅਰ, ਹੋਰ ਕੁਨੈਕਸ਼ਨ) ਅਤੇ ਦੇਖੋ ਕਿ ਲੇਟੈਂਸੀ ਸੁਧਰਦੀ ਹੈ ਕਿ ਨਹੀਂ।
• ਮੰਗ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਘਟਾਓ (ਇੱਕ ਸ਼ੋਰ ਕਰਨ ਵਾਲੇ ਐਂਡਪੌਇੰਟ ਨੂੰ ਸੀਮਿਤ ਕਰੋ, ਛੋਟਾ ਵਰਕਲੋਡ ਰੀਪਲੇ ਕਰੋ) ਅਤੇ ਦੇਖੋ ਕਿ ਸੰਦੇਹਜਨਕ ਸੀਮਾ ਢਿੱਲੀ ਪੈਂਦੀ ਹੈ ਕਿ ਨਹੀਂ।

ਕੋਰਲੇਸ਼ਨ ਇੱਕ ਇਸ਼ਾਰਾ ਹੈ, ਫੈਸਲਾ ਨਹੀਂ। ਜੇ "CPU ਲੇਟੈਂਸੀ ਨਾਲ ਵੱਧ ਹੁੰਦੀ ਹੈ", ਤਾਂ CPU ਉਪਲਬਧਤਾ ਵਿੱਚ ਬਦਲਾਅ ਕਰਕੇ ਜਾਂ CPU ਕੰਮ ਘਟਾ ਕੇ ਪੱਕਾ ਕਰੋ ਕਿ ਲੇਟੈਂਸੀ ਵੀ ਉਸਦੇ ਨਾਲ ਚਲਦੀ ਹੈ।

ਤੁਸੀਂ ਜੋ ਸਾਬਿਤ ਕੀਤਾ ਉਸਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰੋ

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

ਪ੍ਰਦਰਸ਼ਨ ਇਨਸੀਡੈਂਟਾਂ ਲਈ ਇੱਕ ਦੁਹਰਾਉਣਯੋਗ ਵਰਕਫਲੋ ਬਣਾਓ

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

ਇਨਸੀਡੈਂਟ ਲੂਪ: ਡੀਟੈਕਟ → ਟ੍ਰਾਇਜ → ਮੈਜ਼ਰ → ਫਿਕਸ

Detect: ਯੂਜ਼ਰ-ਦੇਖੇ ਲੇਟੈਂਸੀ ਅਤੇ ਐਰਰ ਰੇਟ 'ਤੇ ਅਲਰਟ ਕਰੋ, ਸਿਰਫ਼ CPU ਨਹੀਂ। ਜਦ p95/p99 ਲਗਾਤਾਰ ਥਰੈਸ਼ੋਲਡ ਲੰਘਦਾ ਹੈ ਤਾਂ ਪੇਜ ਕਰੋ।

Triage: ਤੁਰੰਤ ਤਿੰਨ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿਓ: ਕੀ ਧੀਮਾ ਹੈ, ਇਹ ਕਦੋਂ ਸ਼ੁਰੂ ਹੋਇਆ, ਅਤੇ ਕੌਣ ਪ੍ਰਭਾਵਿਤ ਹੈ? ਜੇ ਤੁਸੀਂ ਦਾਇਰਾ (ਸੇਵਾ, ਐਂਡਪੌਇੰਟ, ਖੇਤਰ, ਕੋਹੋਰਟ) ਨਾਮ ਨਹੀਂ ਲੈ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਓਪ੍ਟਿਮਾਈਜ਼ ਕਰਨ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹੋ।

Measure: ਉਹ ਸਬੂਤ ਇਕੱਠਾ ਕਰੋ ਜੋ ਬੋਤਲਨੇਕ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਸਮੇਂ-ਸੀਮਤ ਕੈਪਚਰ ਪਸੰਦ ਕਰੋ (ਉਦਾਹਰਨ, 60–180 ਸਕਿੰਟ) ਤਾਂ ਜੋ ਤੁਸੀਂ "ਖਰਾਬ" vs "ਚੰਗਾ" ਦੀ ਤੁਲਨਾ ਕਰ ਸਕੋ।

Fix: ਇਕ ਵਾਰੀ ਵਿੱਚ ਇੱਕ ਚੀਜ਼ ਬਦਲੋ, ਫਿਰ ਉਹੀ ਸੰਕੇਤ ਦੁਬਾਰਾ ਮਾਪੋ ਤਾਂ ਜੋ ਸੁਧਾਰ ਪੁਸ਼ਟੀ ਹੋਵੇ ਅਤੇ ਪਲੇਸਿਬੋ ਰਾਹ ਉਲਟਿਆ ਜਾ ਸਕੇ।

ਇੱਕ ਛੋਟੇ ਸੈੱਟ ਦੇ ਗ੍ਰਾਫ ਸਧਾਰਿਤ ਕਰੋ

ਇਨਸੀਡੈਂਟ ਦੌਰਾਨ ਸਾਰਿਆਂ ਵੱਲੋਂ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਸਾਂਝੇ ਡੈਸ਼ਬੋਰਡ ਰੱਖੋ। ਇਹ ਨਿਰੀਹ ਅਤੇ ਲਗਾਤਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

• ਲੇਟੈਂਸੀ: p50 / p95 / p99 (ਮੁੱਖ ਐਂਡਪੌਇੰਟ ਲਈ)
• RED ਸੰਕੇਤ: Rate, Errors, Duration (ਸੇਵਾ-ਪਹਿਲਾਂ ਵੇਖੋ)
• ਕੁਝ USE ਮੈਟਰਿਕ: CPU, ਡਿਸਕ, ਨੈੱਟਵਰਕ ਲਈ utilization, saturation, errors

ਮਕਸਦ ਸਭ ਕੁਝ ਗ੍ਰਾਫ ਕਰਨਾ ਨਹੀਂ; ਇਹ ਹੈ ਟਾਈਮ-ਟੂ-ਫ਼ਸਟ-ਫੈਕਟ ਘਟਾਉਣਾ।

ਮਹੱਤਵਪੂਰਨ ਐਂਡਪੌਇੰਟ ਲਈ “ਗੋਲਡਨ ਸਿਗਨਲ” ਤੈਅ ਕਰੋ

ਉਹ ਐਂਡਪੌਇੰਟ ਇੰਸਟ੍ਰੂਮੈਂਟ ਕਰੋ ਜੋ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹਨ (checkout, login, search), ਹਰ ਇੱਕ ਲਈ ਇਕੂ ਪ95 ਉਮੀਦ, ਵੱਧਤਮ ਐਰਰ ਰੇਟ, ਅਤੇ ਮੁੱਖ ਡਿਪੈਂਡੈਂਸੀ (DB, cache, ਤੀਜੀ-ਪੱਖ)।

ਇਨਸੀਡੈਂਟ ਦੌਰਾਨ ਕੀ ਕੈਪਚਰ ਕਰਨਾ ਹੈ ਤੈਅ ਕਰੋ

ਅਗਲੇ ਆਊਟੇਜ ਤੋਂ ਪਹਿਲਾਂ, ਇਕ ਕੈਪਚਰ ਕਿੱਟ 'ਤੇ ਸਹਿਮਤ ਹੋਵੋ:

• ਪ੍ਰੋਫਾਈਲ (CPU ਅਤੇ off-CPU), ਨਾਲ ਫਲੇਮ ਗ੍ਰਾਫ
• ਸਲੋ ਐਂਡਪੌਇੰਟਾਂ ਲਈ ਟਰੇਸ
• ਐਰਰ/ਟਾਈਮਆਊਟ ਲਈ ਲੌਗ (ਸੈਂਪਲ ਕੀਤੇ ਹੋਏ)

ਇਸਨੂੰ ਇੱਕ ਛੋਟੀ ਰਨਬੁੱਕ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਕਰੋ (ਉਦਾਹਰਣ, /runbooks/latency), ਜਿਸ ਵਿੱਚ ਲਿਖਿਆ ਹੋਵੇ ਕਿ ਕੌਣ ਕੈਪਚਰ ਚਲਾ ਸਕਦਾ ਹੈ ਅਤੇ ਆਰਟਿਫੈਕਟ ਕਿੱਥੇ ਰੱਖੇ ਜਾਣਗੇ।

Koder.ai ਕਿੱਥੇ ਫਿੱਟ ਬੈਠਦਾ ਹੈ

Gregg ਦੀ ਵਿਧੀ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਨਿਯੰਤਰਤ ਬਦਲਾਅ ਅਤੇ ਤੇਜ਼ ਪੁਸ਼ਟੀ ਬਾਰੇ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਟੀਮ Koder.ai ਵਰਤ ਕੇ ਸੇਵਾਵਾਂ ਬਣਾਉਂਦੀ ਹੈ (ਇੱਕ ਚੈਟ-ਡਰਿਵਨ ਪਲੇਟਫਾਰਮ ਜੋ ਵੈੱਬ, ਬੈਕਐਂਡ, ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਂਦਾ ਹੈ), ਦੋ ਫੀਚਰ ਇਸ ਮਨੋਭਾਵ ਨਾਲ ਅਸਾਨੀ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ:

• Planning Mode ਤੁਹਾਨੂੰ "ਸ਼ਾਇਦ ਇਹ X ਹੈ" ਨੂੰ ਇੱਕ ਸਪੱਸ਼ਟ ਪਰਿਕਲਪਨਾ ਅਤੇ ਇੱਕ ਛੋਟੇ, ਟੈਸਟ-ਯੋਗ ਬਦਲਾਅ ਵਿੱਚ ਬਦਲਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
• Snapshots and rollback ਸੁਰੱਖਿਅਤ, ਇਕ-ਚਰ ਪ੍ਰਯੋਗਾਂ ਦੀ ਸਹਾਇਤਾ ਕਰਦੇ ਹਨ: ਇੱਕ ਬਦਲਾਅ ਲਗਾਓ, RED/USE ਸੰਕੇਤਾਂ ਨੂੰ ਮੁੜ-ਮਾਪੋ, ਅਤੇ ਜੇ ਸਬੂਤ "ਨਹੀਂ" ਦੱਸਦਾ ਹੈ ਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਰੋਲਬੈਕ ਕਰੋ।

ਚਾਹੇ ਤੁਸੀਂ ਇਨਸੀਡੈਂਟ ਦੌਰਾਨ ਨਵਾਂ ਕੋਡ ਜਨਰੇਟ ਨਾ ਕਰ ਰਹੇ ਹੋ, ਉਹ ਆਦਤਾਂ—ਛੋਟੀਆਂ ਡਿਫਸ, ਮਾਪਣਯੋਗ ਨਤੀਜੇ, ਅਤੇ ਤੇਜ਼ ਵਾਪਸੀ—ਉਹੀ ਆਦਤਾਂ ਹਨ ਜੋ Gregg ਪ੍ਰਚਾਰ ਕਰਦਾ ਹੈ।

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਵਾਕ-ਹਵਾਲਾ: ਲੇਟੈਂਸੀ ਸਪਾਈਕ ਤੋਂ ਚੈੱਕ ਕੀਤੇ ਫਿਕਸ ਤੱਕ

ਸਿਨਾਰਿਓ: ਪ99 ਪੀਕ ਟ੍ਰੈਫਿਕ 'ਤੇ ਉੱਚਾ ਹੋ ਗਿਆ

ਸਵੇਰੇ 10:15 ਵਜੇ ਤੁਹਾਡਾ ਡੈਸ਼ਬੋਰਡ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ API ਲਈ p99 ਲੇਟੈਂਸੀ ~120ms ਤੋਂ ~900ms ਹੋ ਗਿਆ ਹੈ। ਐਰਰ ਰੇਟ ਸਥਿਰ ਹੈ, ਪਰ ਗਾਹਕਾਂ "ਧੀਮਾ" ਰਿਪੋਰਟ ਕਰ ਰਹੇ ਹਨ।

ਕਦਮ 1 — RED ਨਾਲ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

ਸੇਵਾ-ਪਹਿਲਾਂ ਸ਼ੁਰੂ ਕਰੋ: Rate, Errors, Duration。

ਤੁਸੀਂ Duration ਨੂੰ ਐਂਡਪੌਇੰਟ ਅਨੁਸਾਰ ਸਲਾਈਸ ਕਰਦੇ ਹੋ ਅਤੇ ਦੇਖਦੇ ਹੋ ਕਿ ਇੱਕ ਰੂਟ p99 'ਤੇ ਛਾ ਗਿਆ: POST /checkout। Rate 2× ਵੱਧ ਗਿਆ, ਐਰਰ ਨਾਰਮਲ ਹਨ, ਪਰ Duration ਖਾਸ ਤੌਰ 'ਤੇ concurrency ਵਧਣ 'ਤੇ spike ਕਰਦੀ ਹੈ। ਇਹ ਕਤਾਰ ਜਾਂ ਕੰਟੈਂਸ਼ਨ ਦੀ ਨਿਸ਼ਾਨੀ ਹੈ, ਨਾ ਕਿ ਕੁੱਲ ਮੁਕੰਮਲ ਫੇਲ।

ਅਗਲੇ, ਦਿਹਾਨ ਦਿਓ ਕਿ ਲੇਟੈਂਸੀ ਕੰਪਿਊਟ ਸਮਾਂ ਹੈ ਜਾਂ ਉਡੀਕ ਸਮਾਂ: ਐਪਲੀਕੇਸ਼ਨ "ਹੈਂਡਲਰ ਸਮਾਂ" ਦਾ ਤੁਲਨਾ ਕਰੋ ਕੁੱਲ ਰਿਕਵੇਸਟ ਸਮਾਂ ਨਾਲ (ਜਾਂ ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਟ੍ਰੇਸ ਹੈ ਤਾਂ upstream vs downstream spans)। ਹੈਂਡਲਰ ਸਮਾਂ ਘੱਟ ਹੈ, ਕੁੱਲ ਸਮਾਂ ਵੱਧ ਹੈ—ਰਿਕਵੇਸਟ ਉਡੀਕ ਕਰ ਰਹੇ ਹਨ।

ਕਦਮ 2 — সন্দੇਹਜਨਕ ਹੋਸਟ/ਹੋਸਟਾਂ 'ਤੇ USE ਲਗਾਓ

ਸੰਭਾਵੀ ਬੋਤਲਨੇਕਾਂ ਦੀ ਇਨਵੈਂਟਰੀ ਕਰੋ: CPU, ਮੈਮੋਰੀ, ਡਿਸਕ, ਨੈਟਵਰਕ ਲਈ Utilization, Saturation, Errors。

CPU utilization ਸਿਰਫ ~35% ਹੈ, ਪਰ CPU run queue ਅਤੇ context switches ਵਧ ਰਹੇ ਹਨ। ਡਿਸਕ ਅਤੇ ਨੈੱਟਵਰਕ ਸਥਿਰ ਦਿਖ ਰਹੇ ਹਨ। ਇਹ ਨੋੰਮਿਲ (low CPU%, high waiting) ਕਲਾਸਿਕ ਇਸ਼ਾਰਾ ਹੈ: ਥ੍ਰੈਡ CPU ਨਹੀਂ ਜਲਾ ਰਹੇ—ਉਹ ਬਲੌਕ ਹਨ।

ਕਦਮ 3 — ਲੱਛਣਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਪ੍ਰੋਫਾਈਲਿੰਗ ਚੁਣੋ

• ਜੇ CPU ਉੱਚ ਹੈ: CPU ਪ੍ਰੋਫਾਈਲਿੰਗ (on-CPU ਫਲੇਮ ਗ੍ਰਾਫ) ਵਰਤੋ।
• ਜੇ ਰਿਕਵੇਸਟ ਉਡੀਕ ਰਹੀਆਂ ਹਨ: off-CPU ਪ੍ਰੋਫਾਈਲਿੰਗ ਵਰਤੋ ਤਾਂ ਕਿ ਪਤਾ ਲਗੇ ਕਿ ਥ੍ਰੈਡ ਕਿੱਥੇ ਬਲੌਕ ਹਨ (ਲਾਕ, I/O, ਸ਼ੈਡਿਊਲਿੰਗ)।

ਤੁਸੀਂ spike ਦੌਰਾਨ ਇੱਕ off-CPU ਪ੍ਰੋਫਾਈਲ ਕੈਪਚਰ ਕਰਦੇ ਹੋ ਅਤੇ ਇੱਕ ਸਾਂਝੇ "promotion validation" cache ਦੇ ਆਲੇ-ਦੁਆਲੇ ਮਿਊਟੈਕਸ ਵਿੱਚ ਭਾਰੀ ਸਮਾਂ ਮਿਲਦਾ ਹੈ।

ਕਦਮ 4 — ਠੀਕ ਕਰੋ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ

ਤੁਸੀਂ ਗਲੋਬਲ ਲਾਕ ਨੂੰ ਪ੍ਰਤੀ-ਕੀ ਲਾਕ (per-key lock) ਨਾਲ ਬਦਲ ਦਿੰਦੇ ਹੋ (ਜਾਂ lock-free read path), ਡਿਪਲੋਇ ਕਰਦੇ ਹੋ, ਅਤੇ ਦੇਖਦੇ ਹੋ ਕਿ p99 ਮੁੜ ਮਾਪ ਤੇ ਆ ਜਾਂਦਾ ਹੈ ਜਦ Rate ਉੱਚ ਹੀ ਰਹਿੰਦੀ ਹੈ।

ਪੋਸਟ-ਇਨਸੀਡੈਂਟ ਚੈਕਲਿਸਟ:

• ਨਿਰਧਾਰਤ RED ਲੱਛਣ ਅਤੇ ਸੀਮਿਤ ਐਂਡਪੌਇੰਟ ਰਿਕਾਰਡ ਕਰੋ।
• ਪ੍ਰੋਫਾਈਲ ਅਤੇ ਟਾਈਮ-ਵਿੰਡੋ ਸੇਵ ਕਰੋ।
• ਖਾਸ saturation ਸੰਕੇਤ ਲਈ ਐਲਰਟ ਜੋੜੋ (ਜਿਵੇਂ ਲਾਕ ਵੈਟ / ਰਨ ਕਿਊ)।
• ਲਿਖੋ ਕਿ ਅਗਰ ਇਹ ਫਿਰ ਹੋਵੇ ਤਾਂ "ਅਗਲਾ ਪ੍ਰਸ਼ਨ" ਕੀ ਹੋਵੇਗਾ।