ਸਾਡੀ GB10 ਮਸ਼ੀਨ ਆਪਣੇ ਆਪ ਬੰਦ ਹੋ ਜਾਂਦੀ ਸੀ। ਲੌਗ ਨੇ ਮੈਮੋਰੀ ਨੂੰ ਦੋਸ਼ੀ ਠਹਿਰਾਇਆ ਸੀ, ਪਰ ਅਸਲ ਕਾਰਨ ਗਰਮੀ ਸੀ।

Ops2026-10-31

ਸਤੰਬਰ ਵਿੱਚ ਸਾਡੀਆਂ ਤਿੰਨ NVIDIA GB10 ਮਸ਼ੀਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਚਾਰ ਦਿਨਾਂ ਵਿੱਚ ਤਿੰਨ ਵਾਰ ਬੰਦ ਹੋ ਗਈ: 10 ਸਤੰਬਰ ਨੂੰ, 12 ਸਤੰਬਰ ਨੂੰ (ਇਹ 17 ਘੰਟਿਆਂ ਲਈ ਬੰਦ ਰਹੀ) ਅਤੇ 13 ਸਤੰਬਰ ਨੂੰ, ਦੁਬਾਰਾ ਚਾਲੂ ਕਰਨ ਤੋਂ ਬਾਰਾਂ ਮਿੰਟ ਬਾਅਦ। ਹਰ ਵਾਰ ਇਸਨੂੰ ਚਾਲੂ ਕਰਨ ਲਈ ਕਿਸੇ ਵਿਅਕਤੀ ਨੂੰ ਪਾਵਰ ਬਟਨ ਦਬਾਉਣਾ ਪਿਆ।

ਗਰਮੀ ਕਾਰਨ ਬੰਦ ਹੋਣਾ ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ

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

ਗਲਤ ਸੁਰਾਗ

ਹਰ ਬੰਦ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਆਖਰੀ ਕਰਨਲ ਲਾਈਨਾਂ GPU ਆਊਟ-ਆਫ਼-ਮੈਮੋਰੀ ਗਲਤੀਆਂ (NV_ERR_NO_MEMORY) ਸਨ, ਇਸ ਲਈ ਮੈਮੋਰੀ ਦੋਸ਼ੀ ਲੱਗ ਰਹੀ ਸੀ। ਅਜਿਹਾ ਨਹੀਂ ਸੀ। ਉਹ ਲਾਈਨਾਂ ਸਿਰਫ਼ ਉਹ ਸਭ ਤੋਂ ਆਮ ਚੀਜ਼ ਸਨ ਜੋ ਕਰਨਲ ਲਿਖਦਾ ਸੀ: 19 ਦਿਨਾਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ ਇੱਕ ਬੂਟ ਵਿੱਚ 440,580 ਲਾਈਨਾਂ। ਜਦੋਂ ਕੋਈ ਲਾਈਨ ਇੰਨੀ ਵਾਰ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਆਖਰੀ ਲਾਈਨ ਹੋਵੇਗੀ। ਕਿਸੇ ਲੌਗ ਲਾਈਨ ਨੂੰ ਦੋਸ਼ੀ ਠਹਿਰਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਗਿਣੋ ਕਿ ਜਦੋਂ ਕੁਝ ਗਲਤ ਨਹੀਂ ਹੁੰਦਾ ਤਾਂ ਇਹ ਕਿੰਨੀ ਵਾਰ ਆਉਂਦੀ ਹੈ।

ਸਹੀ ਸੁਰਾਗ

ਕਿਉਂਕਿ ਪਾਵਰ-ਆਊਟ ਵਿੱਚ ਜਰਨਲ ਆਪਣੇ ਆਖਰੀ ਮਿੰਟ ਗੁਆ ਦਿੰਦਾ ਹੈ, ਅਸੀਂ ਇੱਕ ਛੋਟਾ ਸੈਂਪਲਰ ਸ਼ਾਮਲ ਕੀਤਾ ਸੀ ਜੋ ਹਰ ਮਿੰਟ ਤਾਪਮਾਨ, ਲੋਡ ਅਤੇ ਮੈਮੋਰੀ ਨੂੰ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਲਿਖਦਾ ਹੈ ਅਤੇ ਡਿਸਕ ਤੇ ਫਲੱਸ਼ ਕਰਦਾ ਹੈ। ਇਸਨੇ ਜੁਲਾਈ ਤੋਂ ਬਾਅਦ ਸਾਰੀਆਂ ਪੰਜ ਬੰਦ ਹੋਣ ਦੀਆਂ ਘਟਨਾਵਾਂ ਫੜ ਲਈਆਂ। ਹਰ ਇੱਕ ਪੂਰੇ GPU ਲੋਡ (96%) ਤੇ ਆਈ, ਜਦਕਿ CPU 85 ਤੋਂ 97 °C ਤੇ ਸੀ।

ਸਮੇਂ ਨੇ ਬਾਕੀ ਸਭ ਸਮਝਾ ਦਿੱਤਾ। ਸਤੰਬਰ ਦੀ ਸ਼ੁਰੂਆਤ ਦੇ ਆਸ-ਪਾਸ ਅਸੀਂ ਵੀਡੀਓ ਰੈਂਡਰਿੰਗ ਇਸ ਮਸ਼ੀਨ ਤੇ ਲੈ ਆਏ ਸੀ। ਪੂਰੇ ਲੋਡ ਤੇ ਇਸਦਾ GPU ਪਾਵਰ ਲਗਭਗ 24 W ਤੋਂ ਵਧ ਕੇ 46 W ਹੋ ਗਿਆ, ਇਸਦਾ ਮੱਧਮ GPU ਤਾਪਮਾਨ 68 ਤੋਂ 86 °C ਹੋ ਗਿਆ, ਅਤੇ ਉਹ ਮਿੰਟ ਜਿੱਥੇ CPU 95 °C ਜਾਂ ਇਸ ਤੋਂ ਵੱਧ ਸੀ, ਕੋਈ ਨਹੀਂ ਤੋਂ ਵਧ ਕੇ 4,283 ਹੋ ਗਏ। ਸਾਡੀਆਂ ਦੋ ਹੋਰ GB10 ਮਸ਼ੀਨਾਂ, ਜੋ ਭਾਸ਼ਾ ਮਾਡਲ ਨੂੰ ਉਸੇ 96% ਲੋਡ ਤੇ ਚਲਾਉਂਦੀਆਂ ਹਨ, 65 ਤੋਂ 81 °C ਤੇ ਰਹੀਆਂ। ਇਹ ਮਸ਼ੀਨ ਸਿਰਫ਼ ਮਾੜੀ ਠੰਢੀ ਹੁੰਦੀ ਸੀ।

ਪਹਿਲਾ ਹੱਲ: GPU ਕਲਾਕ ਕੈਪ

GB10 ਤੇ, nvidia-smi ਪਾਵਰ ਲਿਮਿਟ ਸੈੱਟ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਪਰ ਇਹ GPU ਕਲਾਕ ਨੂੰ ਕੈਪ ਕਰ ਸਕਦਾ ਹੈ: nvidia-smi -lgc 0,2000। ਜੁਲਾਈ ਵਿੱਚ ਇਸਨੇ ਸਭ ਤੋਂ ਗਰਮ ਜ਼ੋਨ ਨੂੰ ਸਕਿੰਟਾਂ ਵਿੱਚ 91 °C ਤੋਂ 77 ਤੋਂ 83 °C ਤੱਕ ਲੈ ਆਂਦਾ। ਦੋ ਵੇਰਵੇ ਮਹੱਤਵਪੂਰਨ ਹਨ:

• ਇਸਨੂੰ ਭਾਰੀ ਸੇਵਾਵਾਂ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਲਾਗੂ ਕਰੋ। ਸਾਡੀ ਕੈਪ ਸੇਵਾ ਪਹਿਲਾਂ ਬੂਟ ਤੋਂ ਲਗਭਗ 15 ਸਕਿੰਟ ਬਾਅਦ ਚੱਲਦੀ ਸੀ, ਜਦੋਂ ਮਾਡਲ ਸਰਵਰ ਪਹਿਲਾਂ ਹੀ ਪੂਰੀ ਪਾਵਰ ਤੇ ਲੋਡ ਹੋਣਾ ਸ਼ੁਰੂ ਕਰ ਚੁੱਕਾ ਸੀ, ਜੋ ਉਹ ਪਲ ਸੀ ਜਿਸ ਨੇ ਮਸ਼ੀਨ ਨੂੰ ਕ੍ਰੈਸ਼ ਕੀਤਾ ਸੀ। ਹੁਣ ਇਹ Docker ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਚੱਲਦੀ ਹੈ।
• ਭਾਰ ਹੇਠ ਇਸ ਦੀ ਜਾਂਚ ਕਰੋ। ਕੈੱਪ ਚਾਲੂ ਹੋਣ 'ਤੇ, ਜਦੋਂ GPU ਆਈਡਲ ਹੁੰਦਾ ਹੈ ਤਾਂ ਰਿਪੋਰਟ ਕੀਤਾ ਗਿਆ GPU ਕਲਾਕ ਲਗਭਗ 2,400 MHz ਦਿਖਾਉਂਦਾ ਹੈ। ਭਾਰ ਹੇਠ ਇਹ 1,976 MHz 'ਤੇ ਟਿਕਿਆ ਰਹਿੰਦਾ ਹੈ।

ਦੂਜਾ ਹੱਲ: ਪੜਾਵਾਂ ਵਿੱਚ ਇੱਕ ਹੀਟ ਗਾਰਡ

ਰੈਂਡਰਿੰਗ ਸ਼ਾਮਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਕੈੱਪ ਕਾਫ਼ੀ ਨਹੀਂ ਸੀ, ਇਸ ਲਈ ਹੁਣ ਇੱਕ ਗਾਰਡ ਹਰ ਸੈਂਸਰ ਨੂੰ ਇੱਕ ਸਕਿੰਟ ਵਿੱਚ ਇੱਕ ਵਾਰ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਪੜਾਵਾਂ ਵਿੱਚ ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ: 89 °C ਤੋਂ GPU ਕਲਾਕ ਘਟਾਉਣਾ ਅਤੇ 92 °C ਤੋਂ ਇੱਕ ਵਾਰ ਫਿਰ ਘਟਾਉਣਾ; 94 °C ਤੋਂ ਰੈਂਡਰਰ ਨੂੰ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ (SIGSTOP) ਅਤੇ CPU ਨੂੰ ਧੀਮਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ; 96 °C ਤੋਂ ਹਰ GPU ਜੌਬ ਨੂੰ ਠੰਡਾ ਹੋਣ ਲਈ ਲੱਗਣ ਵਾਲੇ ਸਕਿੰਟਾਂ ਲਈ ਰੋਕ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਤਦ ਹੀ ਵਾਪਸ ਆਉਂਦਾ ਹੈ ਜਦੋਂ ਮਸ਼ੀਨ ਕੁਝ ਸਮੇਂ ਲਈ ਠੰਡੀ ਰਹਿੰਦੀ ਹੈ। 97 °C 'ਤੇ 20 ਸਕਿੰਟਾਂ ਲਈ, ਇੱਕ ਆਖਰੀ-ਸਹਾਰਾ ਬ੍ਰੇਕ ਵੀਡੀਓ ਸੇਵਾ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੋਕ ਦਿੰਦਾ ਹੈ।

ਰੈਂਡਰਿੰਗ ਹੇਠ ਆਪਣੇ ਪਹਿਲੇ ਨੌਂ ਮਿੰਟਾਂ ਵਿੱਚ, ਸਭ ਤੋਂ ਗਰਮ ਜ਼ੋਨ ਦਾ ਸਿਖਰ 94 °C ਸੀ ਅਤੇ ਮੱਧਮਾਨ 89 °C ਸੀ, ਜਦਕਿ ਪਹਿਲਾਂ 97 °C ਦੇ ਪਲੇਟੂ ਸਨ। ਇਸ ਦੀ ਕੀਮਤ ਹੈ: ਸਤੰਬਰ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਦਿਨ ਰੈਂਡਰਰ ਨੂੰ 17% ਸਮੇਂ ਲਈ ਰੋਕਿਆ ਗਿਆ ਸੀ, ਅਤੇ GPU ਦਿਨ ਦੇ ਜ਼ਿਆਦਾਤਰ ਸਮੇਂ 900 MHz ਜਾਂ ਇਸ ਤੋਂ ਘੱਟ 'ਤੇ ਚੱਲਿਆ। ਅਤੇ ਇਹ ਇੱਕ ਇਲਾਜ ਵੀ ਨਹੀਂ ਹੈ: ਮਸ਼ੀਨ 11 ਅਕਤੂਬਰ ਨੂੰ 97 ਤੋਂ 98 °C 'ਤੇ ਇੱਕ ਵਾਰ ਫਿਰ ਆਪਣੇ ਆਪ ਬੰਦ ਹੋ ਗਈ ਸੀ। ਉਦੋਂ ਤੋਂ ਇਹ ਬਿਨਾਂ ਵਿਰਾਮ ਦੇ ਚੱਲ ਰਹੀ ਹੈ, ਜਿਵੇਂ ਅਸੀਂ ਇਹ ਲਿਖ ਰਹੇ ਹਾਂ, 20 ਦਿਨ।

ਰਾਹ ਵਿੱਚ ਅਸੀਂ ਚਾਰ ਗਲਤੀਆਂ ਕੀਤੀਆਂ

• ਇੱਕ ਜੌਬ ਰੋਕਣ ਨਾਲ ਮਸ਼ੀਨ ਠੰਡੀ ਨਹੀਂ ਹੋਈ। ਬ੍ਰੇਕ ਉਦੋਂ ਚੱਲਿਆ ਜਦੋਂ ਰੈਂਡਰਰ ਪਹਿਲਾਂ ਹੀ ਰੁਕਿਆ ਹੋਇਆ ਸੀ, ਕਿਉਂਕਿ ਇੱਕ ਇਮੇਜ ਮਾਡਲ ਹਾਲੇ ਵੀ ਡਰਾਇੰਗ ਕਰ ਰਿਹਾ ਸੀ ਅਤੇ ਇੱਕੀ ਸਕਿੰਟਾਂ ਵਿੱਚ ਇੱਕ ਦਰਜਨ ਟਾਈਮਰ ਸ਼ੁਰੂ ਹੋਏ ਸਨ। ਹੁਣ ਸਭ ਤੋਂ ਉੱਪਰਲਾ ਪੜਾਅ ਸਿਰਫ਼ ਰੈਂਡਰਰ ਨਹੀਂ, ਸਗੋਂ ਹਰੇਕ ਭਾਰੀ GPU ਜੌਬ ਨੂੰ ਰੋਕਦਾ ਹੈ।
• ਗਾਰਡ ਜੌਬਾਂ ਨੂੰ ਨਾਮ ਦੁਆਰਾ ਰੋਕਦਾ ਹੈ, ਅਤੇ ਨਾਮ ਬਦਲ ਗਏ ਸਨ। ਦੋ ਵਾਰ ਇੱਕ ਨਵਾਂ ਇੰਜਣ ਰੋਕ ਤੋਂ ਬਚ ਜਾਂਦਾ: ਸਤੰਬਰ ਵਿੱਚ ਇੱਕ ਨਵੇਂ ਪ੍ਰੋਸੈੱਸ ਨਾਮ ਵਾਲਾ ਇਮੇਜ ਮਾਡਲ, ਅਤੇ ਅਕਤੂਬਰ ਵਿੱਚ ਇੱਕ ਰੈਂਡਰਰ ਜੋ ਰੈਂਡਰ ਸੇਵਾ ਦੇ ਚਾਈਲਡ ਵਜੋਂ ਨਹੀਂ, ਸਗੋਂ ਇੱਕ ਕੰਟੇਨਰ ਵਿੱਚ ਚੱਲਦਾ ਹੈ। ਹੁਣ ਇੰਜਣ ਦੀ ਹਰ ਬਦਲਾਹਟ ਵਿੱਚ ਗਾਰਡ ਦੀ ਸੂਚੀ ਦੀ ਜਾਂਚ ਸ਼ਾਮਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
• ਬ੍ਰੇਕ ਦਾ ਹੋਲਡ ਕਦੇ ਨਹੀਂ ਹਟਿਆ। ਇਸ ਨੇ ਵੀਡੀਓ ਸੇਵਾ ਰੋਕ ਦਿੱਤੀ ਅਤੇ ਇੱਕ ਹੋਲਡ ਫਾਈਲ ਛੱਡ ਦਿੱਤੀ ਤਾਂ ਜੋ ਕੁਝ ਵੀ ਇਸ ਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਨਾ ਕਰੇ। ਕਿਸੇ ਨੂੰ ਵੀ ਅਲਰਟ ਨਹੀਂ ਦਿੱਤਾ ਗਿਆ, ਅਤੇ ਸਾਨੂੰ ਪਤਾ ਲੱਗਣ ਤੋਂ ਪਹਿਲਾਂ ਆਉਟਪੁੱਟ ਤਿੰਨ ਦਿਨਾਂ ਲਈ ਰੁਕ ਗਿਆ। ਹੁਣ ਹੋਲਡ ਆਪਣੇ ਆਪ ਹਟ ਜਾਂਦਾ ਹੈ: ਆਖਰੀ ਬ੍ਰੇਕ ਤੋਂ ਪੰਜ ਮਿੰਟ ਬਾਅਦ, ਬਿਨਾਂ ਨਵੇਂ ਬ੍ਰੇਕ ਦੇ, ਘੱਟੋ-ਘੱਟ 30 GB ਮੈਮੋਰੀ ਖਾਲੀ ਅਤੇ ਦਸ ਮਿੰਟ ਦਾ ਔਸਤ 93 °C ਜਾਂ ਇਸ ਤੋਂ ਘੱਟ। ਮਸ਼ੀਨ ਦੇ ਠੰਡਾ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਨਾ ਕਦੇ ਕੰਮ ਨਹੀਂ ਕਰਨ ਵਾਲਾ ਸੀ: ਰੈਂਡਰਿੰਗ ਦੇ ਨਾਲ ਅਤੇ ਬਿਨਾਂ ਇਸ ਦੀ ਔਸਤ 88 °C ਸੀ।
• ਅਲਾਰਮ ਮਸ਼ੀਨ ਦੇ ਆਮ ਤਾਪਮਾਨ 'ਤੇ ਵੱਜਿਆ ਸੀ। ਅਲਰਟ ਥ੍ਰੈਸ਼ਹੋਲਡ 88 °C ਸੀ, ਜੋ ਇਸ ਮਸ਼ੀਨ ਦਾ ਔਸਤ ਸੀ। ਇੱਕ ਦਿਨ ਵਿੱਚ, ਇਹ 32% ਸਮਾਂ 90 °C ਜਾਂ ਇਸ ਤੋਂ ਵੱਧ 'ਤੇ ਰਿਹਾ, 8% ਸਮਾਂ 93 °C ਜਾਂ ਇਸ ਤੋਂ ਵੱਧ 'ਤੇ ਅਤੇ 3% ਸਮਾਂ 95 °C ਜਾਂ ਇਸ ਤੋਂ ਵੱਧ 'ਤੇ, ਅਤੇ ਕਦੇ ਵੀ 97 °C ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਿਆ। ਅਸੀਂ ਅਲਾਰਮ ਨੂੰ 97 °C 'ਤੇ ਲੈ ਗਏ, ਉਹ ਪਠਾਰ ਜਿੱਥੇ ਇਹ ਅਸਲ ਵਿੱਚ ਬੰਦ ਹੋ ਗਿਆ ਸੀ, ਅਤੇ ਅਲਾਰਮ ਈਮੇਲ ਬੰਦ ਹੋ ਗਏ।

ਸਿੱਖ

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

Factory Floor ਵਿੱਚ ਇਸ ਕਿਸਮ ਦਾ ਇੱਕ ਗਰਮੀ ਗਾਰਡ ਸ਼ਾਮਲ ਹੈ: ਇਹ GPU ਅਤੇ ਥਰਮਲ-ਜ਼ੋਨ ਸੈਂਸਰਾਂ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਵੱਧ ਗਰਮ ਵਾਲਾ ਪੜ੍ਹਦਾ ਹੈ, ਇੱਕ ਨਿਰਧਾਰਤ ਤਾਪਮਾਨ 'ਤੇ (ਡਿਫੌਲਟ ਵਜੋਂ 92 °C) ਤੁਹਾਡੇ ਦੁਆਰਾ ਨਾਮ ਦਿੱਤੀਆਂ ਭਾਰੀ ਜੌਬਾਂ ਨੂੰ ਰੋਕ ਦਿੰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਹੇਠਲੇ ਤਾਪਮਾਨ (84 °C) ਤੋਂ ਘੱਟ ਹੋਣ 'ਤੇ ਹੀ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਜਿਸ ਦੇ ਨਾਲ ਮੈਮੋਰੀ ਅਤੇ ਡਿਸਕ ਗਾਰਡ ਵੀ ਹਨ।