ਗੁੰਮ ਸਵੈਪ ਫਾਈਲ ਜਿਸਨੇ ਸਾਡੇ ਸਰਵਰ ਜਮਾ ਦਿੱਤੇ

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

“ਜਮ ਜਾਣਾ” ਕਿਹੋ ਜਿਹਾ ਲੱਗਿਆ

• ਲੋਡ ਬੈਲੈਂਸਰ ਦੇ ਹੈਲਥ ਚੈੱਕ ਉਸ ਸਰਵਰ ’ਤੇ ਟਾਈਮ ਆਊਟ ਹੋ ਗਏ।
• AWS Systems Manager ਰਾਹੀਂ ਭੇਜੀਆਂ ਕਮਾਂਡਾਂ “Pending” ਵਿੱਚ ਅਟਕੀਆਂ ਰਹੀਆਂ ਅਤੇ ਕਦੇ ਨਹੀਂ ਚੱਲੀਆਂ।
• ਲੌਗਾਂ ਵਿੱਚ ਕੋਈ out-of-memory ਕਿੱਲ ਨਹੀਂ ਸੀ। ਕੋਈ ਪ੍ਰਕਿਰਿਆ ਮਰੀ ਨਹੀਂ ਸੀ।

ਇੱਕ ਹਫ਼ਤਾ ਪਹਿਲਾਂ ਅਸੀਂ ਪ੍ਰੋਡਕਸ਼ਨ ਨੂੰ ਛੋਟੇ ARM ਸਰਵਰਾਂ ’ਤੇ ਲਿਜਾਇਆ ਸੀ, ਹਰ ਇੱਕ ਵਿੱਚ 2 GB RAM ਨਾਲ। ਸਾਡਾ ਸਟੇਜਿੰਗ ਸਰਵਰ, ਜੋ ਇਸ ਤੋਂ ਵੀ ਛੋਟਾ ਹੈ, ਇੱਕ ਡਿਪਲਾਇ ਦੌਰਾਨ ਕੰਟੇਨਰ ਇਮੇਜ ਖੋਲ੍ਹਦੇ ਸਮੇਂ ਇਸੇ ਤਰ੍ਹਾਂ ਜਮ ਗਿਆ ਸੀ।

ਮੈਮੋਰੀ ਦੀ ਗਲਤੀ ਕਿਉਂ ਨਹੀਂ?

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

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

ਸਵੈਪ ਤੋਂ ਬਿਨਾਂ, ਕਰਨੈਲ ਕੋਲ ਅਲਾਟ ਹੋਈ ਪਰ ਘੱਟ ਵਰਤੀ ਜਾਂਦੀ ਮੈਮੋਰੀ ਰੱਖਣ ਲਈ ਕੋਈ ਥਾਂ ਨਹੀਂ ਹੁੰਦੀ, ਇਸ ਲਈ ਇਸਨੂੰ ਕੈਸ਼ ਤੋਂ ਲੈਣਾ ਪੈਂਦਾ ਹੈ।

ਫਿਕਸ

ਸਰਵਰ ਬੂਟਸਟਰੈਪ ਸਕ੍ਰਿਪਟ ਹੁਣ ਹਰ ਵਾਰ ਜਦੋਂ ਸਰਵਰ ਬੂਟ ਹੁੰਦਾ ਹੈ ਜਾਂ ਠੀਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਇੱਕ 2 GB ਸਵੈਪ ਫਾਈਲ ਬਣਾਉਂਦੀ ਹੈ, ਘੱਟ swappiness (10) ਨਾਲ। ਘੱਟ swappiness ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਰਨੈਲ ਅਜੇ ਵੀ ਕੰਮ ਦੀ ਮੈਮੋਰੀ RAM ਵਿੱਚ ਰੱਖਣ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ, ਪਰ ਜੋ ਪੰਨੇ ਘੱਟ ਛੂਹੇ ਜਾਂਦੇ ਹਨ ਉਹ ਡਿਸਕ ’ਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਪ੍ਰੋਗਰਾਮ ਕੋਡ ਨੂੰ ਕੈਸ਼ ਤੋਂ ਬਾਹਰ ਧੱਕਣ ਦੀ ਥਾਂ। ਅਸੀਂ ਇਹ ਦੋਵੇਂ ਪ੍ਰੋਡਕਸ਼ਨ ਸਰਵਰਾਂ ਅਤੇ ਸਟੇਜਿੰਗ ’ਤੇ ਲਾਈਵ ਲਾਗੂ ਕੀਤਾ, ਅਤੇ ਡਿਪਲਾਇ ਪਾਈਪਲਾਈਨ ਹਰ ਪ੍ਰੋਡਕਸ਼ਨ ਡਿਪਲਾਇ ’ਤੇ ਬੂਟਸਟਰੈਪ ਸਕ੍ਰਿਪਟ ਮੁੜ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੀ ਹੈ, ਤਾਂ ਜੋ ਬਦਲਿਆ ਗਿਆ ਸਰਵਰ ਵੀ ਇਹ ਪ੍ਰਾਪਤ ਕਰੇ।

ਜਿਸਨੇ ਸਾਨੂੰ ਵੱਧ ਫਿਕਰ ਵਿੱਚ ਪਾਇਆ: ਅਣਹੈਲਥੀ ਸਰਵਰ ਰਹਿ ਗਿਆ

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

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

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

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

• “ਕਰੈਸ਼ ਨਾ ਹੋਣਾ” ਦਾ ਮਤਲਬ “ਸਿਹਤਮੰਦ” ਨਹੀਂ। ਥ੍ਰੈਸ਼ਿੰਗ ਕੋਈ ਗਲਤੀ ਨਹੀਂ ਪੈਦਾ ਕਰਦੀ, ਸਿਰਫ਼ ਇੰਨੀ ਸੁਸਤੀ ਕਿ ਮਸ਼ੀਨ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦੇਵੇ।
• ਛੋਟੇ ਸਰਵਰਾਂ ਨੂੰ ਸਵੈਪ ਚਾਹੀਦਾ ਹੈ। ਭਾਵੇਂ ਥੋੜ੍ਹਾ ਹੀ ਹੋਵੇ, ਘੱਟ swappiness ਨਾਲ, ਕਰਨੈਲ ਨੂੰ ਠੰਢੀ ਮੈਮੋਰੀ ਰੱਖਣ ਦੀ ਥਾਂ ਦਿੰਦਾ ਹੈ।
• ਮੈਮੋਰੀ ਹੱਦਾਂ ਜੋ ਮਸ਼ੀਨ ਤੋਂ ਵੱਧ ਜੁੜਦੀਆਂ ਹਨ, ਇੱਕ ਸੱਟਾ ਹਨ। ਕਈ ਵਾਰ ਤੁਸੀਂ ਹਾਰਦੇ ਹੋ। ਜਾਣੋ ਕਿ ਕਦੋਂ ਸੱਟਾ ਲਾਇਆ ਹੈ।
• ਜਾਣੋ ਕਿ ਤੁਹਾਡਾ ਆਟੋਸਕੇਲਿੰਗ ਕਿਹੜੇ ਹੈਲਥ ਚੈੱਕ ’ਤੇ ਭਰੋਸਾ ਕਰਦਾ ਹੈ। ਜਿਹੜਾ ਹੈਲਥ ਚੈੱਕ ਸਿਰਫ਼ ਇਹ ਪੁੱਛਦਾ ਹੈ ਕਿ “ਕੀ VM ਚਾਲੂ ਹੈ?”, ਉਹ ਕੰਮ ਬੰਦ ਕਰ ਚੁੱਕੇ ਸਰਵਰ ਨੂੰ ਨਹੀਂ ਬਦਲੇਗਾ।