ਪ੍ਰੋਗਰੈਸ ਲੇਬਲ ਵਿੱਚ ਲੁਕੀ ਮੈਮੋਰੀ ਖਤਮ ਹੋਣ ਦੀ ਗੜਬੜ

ਸਤੰਬਰ ਦੇ ਅਖੀਰ ਵਿੱਚ ਇੱਕ ਸ਼ਾਮ, ਇੱਕ ਯੂਜ਼ਰ ਦੇ ਵਰਕਸਪੇਸ ਵਿੱਚ AI ਏਜੰਟ ਇੱਕ ਟਰਨ ਦੇ ਵਿਚਕਾਰ out-of-memory ਗਲਤੀ ਨਾਲ ਕਰੈਸ਼ ਹੋ ਗਿਆ। ਸਪੱਸ਼ਟ ਸ਼ੱਕੀ ਗੱਲਾਂ, ਜਿਵੇਂ ਬਹੁਤ ਸਾਰੇ ਸਬ-ਏਜੰਟ ਇਕੱਠੇ ਚੱਲਣੇ ਜਾਂ ਸੰਦਰਭ ਦਾ ਬਹੁਤ ਵੱਡਾ ਹੋ ਜਾਣਾ, ਦੋਵੇਂ ਗ਼ਲਤ ਸਨ। ਅਸਲ ਕਾਰਨ ਇੱਕ ਸਟੇਟਸ ਲੇਬਲ ਸੀ: ਜਦੋਂ ਮਾਡਲ ਇੱਕ ਵੱਡੀ ਸ਼ੈੱਲ ਕਮਾਂਡ ਨੂੰ ਥੋੜ੍ਹੇ-ਥੋੜ੍ਹੇ ਕਰਕੇ ਸਟ੍ਰੀਮ ਕਰ ਰਿਹਾ ਸੀ, ਅਸੀਂ ਹਰ ਟੁਕੜੇ ’ਤੇ ਹੁਣ ਤੱਕ ਦੀ ਪੂਰੀ ਕਮਾਂਡ ਨੂੰ ਪ੍ਰੋਗਰੈਸ ਲੇਬਲ ਵਜੋਂ ਦੁਬਾਰਾ ਭੇਜ ਰਹੇ ਸੀ। ਇੱਕ 124 KB ਕਮਾਂਡ ਲਗਭਗ 41,000 ਇਵੈਂਟ ਅਤੇ ਲਗਭਗ 690 MB ਕਤਾਰਬੱਧ ਸਟਰਿੰਗ ਬਣ ਗਈ।

ਏਜੰਟ ਆਪਣਾ ਕੰਮ ਕਿਵੇਂ ਸਟ੍ਰੀਮ ਕਰਦਾ ਹੈ

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

ਮਾਡਲ ਛੋਟੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਸਟ੍ਰੀਮ ਕਰਦਾ ਹੈ। ਜਿਸ ਮਾਡਲ ਨਾਲ ਅਸੀਂ ਚੱਲ ਰਹੇ ਸੀ, ਉਹਨਾਂ ਟੁਕੜਿਆਂ ਵਿੱਚੋਂ ਅਕਸਰ ਸਿਰਫ਼ ਤਿੰਨ ਅੱਖਰ ਲੰਮੇ ਹੁੰਦੇ ਸਨ।

ਪਹਿਲੇ ਅੰਦਾਜ਼ੇ ਗਲਤ ਸਨ

ਕਰੈਸ਼ ਸਕੇਲਿੰਗ ਦੀ ਸਮੱਸਿਆ ਵਰਗਾ ਲੱਗਿਆ, ਇਸ ਲਈ ਅਸੀਂ ਉੱਥੋਂ ਸ਼ੁਰੂ ਕੀਤਾ।

• ਸਮਾਨਾਂਤਰ ਸਬ-ਏਜੰਟ? ਟਰਨ ਨੇ ਸਿਰਫ਼ ਦੋ ਵਰਤੇ ਸਨ, ਹਰ ਇੱਕ ਲਗਭਗ 1.5 MB ਸਟੇਟ ਰੱਖਦਾ ਸੀ। ਇਹ ਕਾਫ਼ੀ ਨਹੀਂ ਸੀ।
• ਰੱਖੇ ਹੋਏ ਟਰੇਸ? ਸਾਡੀ ਟਰੇਸਿੰਗ ਇੱਕ ਰਨ ਟ੍ਰੀ ਮੈਮੋਰੀ ਵਿੱਚ ਰੱਖਦੀ ਸੀ, ਪਰ ਉਹ ਕਰੈਸ਼ ਵੇਲੇ ਹੀਪ ਦੇ ਆਕਾਰ ਦੇ ਨੇੜੇ ਵੀ ਨਹੀਂ ਸੀ।

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

ਅਸਲ ਵਿੱਚ ਦੁਬਾਰਾ ਬਣਾਉਣਾ

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

ਇਹ ਕੰਮ ਕਰ ਗਿਆ। ਹੀਪ ਵਧਿਆ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਉਸੇ ਗਲਤੀ ਨਾਲ ਮਰ ਗਈ।

ਵਿਧੀ ਸਾਦੀ ਸੀ ਜਦੋਂ ਅਸੀਂ ਇਸਨੂੰ ਵੇਖ ਸਕੇ। ਜਦੋਂ ਮਾਡਲ ਇੱਕ ਵੱਡੀ ਕਮਾਂਡ ਲਿਖ ਰਿਹਾ ਸੀ, ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਇੱਕ heredoc ਜੋ 124 KB ਫਾਈਲ ਲਿਖ ਰਿਹਾ ਸੀ, ਤਾਂ ਸਾਡਾ ਸਟ੍ਰੀਮਿੰਗ ਕੋਡ ਹਰ ਟੁਕੜੇ ’ਤੇ ਟੂਲ ਦਾ ਲੇਬਲ ਅੱਪਡੇਟ ਕਰ ਰਿਹਾ ਸੀ। ਲੇਬਲ ਨਵੇਂ ਤਿੰਨ ਅੱਖਰ ਨਹੀਂ ਸੀ; ਉਹ ਹੁਣ ਤੱਕ ਦੀ ਪੂਰੀ ਕਮਾਂਡ ਸੀ। ਇਸ ਲਈ ਇਵੈਂਟ ਵਧਦੇ ਗਏ: 3 ਅੱਖਰ, ਫਿਰ 6, ਫਿਰ 9, … 124 KB ਤੱਕ, ਲਗਭਗ 41,000 ਵਾਰ। ਸਾਕੇਟ ਇਹਨਾਂ ਨੂੰ ਜਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਬਣਦੇ ਸਨ ਭੇਜ ਨਹੀਂ ਸਕਦਾ ਸੀ, ਇਸ ਲਈ ਉਹ ਉਸਦੇ ਰਾਈਟ ਬਫਰ ਵਿੱਚ ਸਟਰਿੰਗਾਂ ਵਜੋਂ ਇਕੱਠੇ ਹੁੰਦੇ ਗਏ, ਲਗਭਗ 690 MB।

ਫਿਕਸ

• ਲੇਬਲ ਸੀਮਤ ਕਰੋ। ਸਟੇਟਸ ਲੇਬਲ ਨੂੰ ਸਿਰਫ਼ ਇਹ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ। ਹੁਣ ਇਹ 200 ਅੱਖਰਾਂ ਤੱਕ ਸੀਮਤ ਹੈ, ਅਤੇ ਅਸੀਂ ਅਧੂਰੀ ਕਮਾਂਡ ਨੂੰ ਦੁਬਾਰਾ ਸਕੈਨ ਕਰਨ ਦੀ ਦਰ ਵੀ ਘਟਾਈ ਹੈ।
• ਵਰਗ-ਅਧਾਰਿਤ ਜੋੜ ਰੋਕੋ। ਸਟ੍ਰੀਮ ਕੀਤੇ ਟੁਕੜਿਆਂ ਨੂੰ ਵਾਰ-ਵਾਰ ਸਟਰਿੰਗ ਕੰਕੈਟਨੇਸ਼ਨ ਨਾਲ ਜੋੜਨਾ ਵੱਡੇ ਆਉਟਪੁੱਟ ਲਈ O(n²) ਹੁੰਦਾ ਹੈ। ਅਸੀਂ ਚੰਕ-ਅਧਾਰਿਤ ਤਰੀਕੇ ’ਤੇ ਗਏ ਜੋ ਰੇਖਿਕ ਸਮੇਂ ਵਿੱਚ ਜੋੜਦਾ ਹੈ।

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

• ਚੈਟ ਵਿੱਚ ਦਿਖਾਈ ਜਾਂਦੀ ਲਾਈਵ ਕਮਾਂਡ ਦਾ ਆਉਟਪੁੱਟ ਬੈਚ ਹੁੰਦਾ ਹੈ ਅਤੇ ਆਖਰੀ 8,000 ਅੱਖਰ ਰੱਖੇ ਜਾਂਦੇ ਹਨ।
• ਹਰ ਇਵੈਂਟ ਲਾਈਨ 4 MB ਤੱਕ ਸੀਮਤ ਹੈ।
• ਬ੍ਰਾਊਜ਼ਰ ਦਾ ਰੀਪਲੇਅ ਬਫਰ, ਜੋ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਫੜਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਪ੍ਰੋਜੈਕਟ ਪ੍ਰਤੀ 8 MB ਤੱਕ ਸੀਮਤ ਹੈ।
• ਪੁਰਾਣੇ ਚੈੱਕਪੌਇੰਟ ਟਰਨ ਦੇ ਨਾਲ ਹੀ ਕੱਟੇ ਜਾਂਦੇ ਹਨ, ਨਵੀਂ ਹਾਲਤ ਅਤੇ ਪਿਛਲੇ ਟਰਨਾਂ ਨੂੰ ਲੋੜੀਂਦੇ ਐਂਕਰ ਰੱਖ ਕੇ।

ਹੜ੍ਹਾਂ ਦੀ ਇਮਾਨਦਾਰ ਜਾਂਚ

ਦੋ ਗੱਲਾਂ ਨੇ ਇਸਨੂੰ ਜਿੰਨਾ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ ਉਸ ਤੋਂ ਔਖਾ ਟੈਸਟ ਕਰਨਾ ਬਣਾਇਆ:

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

ਅਸੀਂ ਇਸ ਤੋਂ ਕੀ ਸਿੱਖਿਆ

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

ਜੇ ਤੁਸੀਂ Mythex ਦੇ ਚੈਟ ਵਿੱਚ ਹਾਲ ਹੀ ਵਿੱਚ ਕੋਈ ਬਹੁਤ ਲੰਮੀ ਫਾਈਲ ਬਿਨਾਂ ਏਜੰਟ ਰੁਕੇ ਦਿਖਦੀ ਵੇਖੀ ਹੈ, ਤਾਂ ਇਸ ਦਾ ਇੱਕ ਹਿੱਸਾ ਇਹੀ ਹੈ।