FUNDAL
Am un bot Discord de lungă durată (3+ ani) scris în discord.py
care a rulat întotdeauna pe GCP, zona us-east4-a. Botul rulează k8s
folosind discord.py 1.7.2 și python 3.9.
PROBLEMĂ
În ultima lună sau două, am început să văd un număr tot mai mare de întreruperi ale conexiunii, [Eroare 104] Resetarea conexiunii de către peer. Resetările nu sunt legate direct de cantitatea de activitate pe bot. Acestea au loc intermitent pe tot parcursul zilei în producție (în medie, la fiecare câteva minute).
Aceste resetări cauzează eșecuri aleatorii ale API-ului HTTP discord și duc la un nivel ridicat de deconectări pe WebSocket. Multe dintre aceste deconectări shard pot RELUA, dar multe (~200 pe zi) ajung să ducă la un apel IDENTIFICARE ca o nouă conexiune și uneori declanșează așteptări extinse de retragere și întreruperi parțiale.
EXEMPLU
Iată un exemplu de deconectare:
Traceback (cel mai recent apel ultimul):
Fișierul „/opt/venv/lib/python3.9/site-packages/discord/shard.py”, linia 187, în reconectare
self.ws = await asyncio.wait_for(coro, timeout=60.0)
Fișierul „/usr/local/lib/python3.9/asyncio/tasks.py”, linia 481, în wait_for
returnează fut.result()
Fișierul „/opt/venv/lib/python3.9/site-packages/discord/gateway.py”, linia 305, în from_client
gateway = gateway sau await client.http.get_gateway()
Fișierul „/opt/venv/lib/python3.9/site-packages/discord/http.py”, linia 967, în get_gateway
date = await self.request(Route('GET', '/gateway'))
Fișierul „/opt/venv/lib/python3.9/site-packages/discord/http.py”, rândul 192, la cerere
asincron cu self.__session.request(method, url, **kwargs) ca r:
Fișier „/opt/venv/lib/python3.9/site-packages/aiohttp/client.py”, linia 1117, în __aenter__
self._resp = await self._coro
Fișier „/opt/venv/lib/python3.9/site-packages/aiohttp/client.py”, rândul 544, în _request
așteptați resp.start(conn)
Fișierul „/opt/venv/lib/python3.9/site-packages/aiohttp/client_reqrep.py”, linia 890, la început
mesaj, sarcină = await self._protocol.read() # tip: ignora
Fișier „/opt/venv/lib/python3.9/site-packages/aiohttp/streams.py”, rândul 604, în citire
await self._ospătar
aiohttp.client_exceptions.ClientOSError: [Errno 104] Resetarea conexiunii de către peer
EXPERIMENT PENTRU IZOLAREA PROBLEMEI
Am efectuat un experiment pentru a izola ceea ce cauzează problema. Am implementat un container cu botul meu pe o VM (nu k8s
) și a izolat-o astfel încât să comunice doar cu discord (fără bază de date exterioară) și să-i trimită automat comenzi pentru a simula comportamentul și încărcarea utilizatorului (trimit aproximativ 60 de comenzi pe minut pe același server -- cu mult sub sarcina mea de producție). Rulez acest lucru timp de 20 de minute sau până când observ dacă se resetează conexiunea și văd următoarele:
- În
noi-est4-a
, sunt capabil să reproduc resetările intermitente ale conexiunii.
- În
noi-est4-b
, sunt capabil să reproduc resetările intermitente ale conexiunii.
- În
noi-est4-c
, sunt capabil să reproduc resetările intermitente ale conexiunii.
- În
us-central1-a
, Eu sunt nu poate reproduce nicio resetare a conexiunii (chiar și după 3 ore -- nici un ciob nu se deconectează deloc).
- În
noi-est1-b
, Eu sunt nu poate reproduce nicio resetare a conexiunii.
- Pe laptopul meu (internet rezidențial pe coasta de est), sunt nu poate reproduce nicio resetare a conexiunii.
Toate experimentele folosesc același recipient, același tip de mașină și aceeași procedură de testare.
Am repetat experimentul în noi-est4-a
cu mai multe tipuri de mașini de până la 8 vCPU și cu nivelurile de rețea premium și standard și încă văd resetări. Am încercat și un alt VM într-un alt proiect, dar problemele de conexiune persistă întotdeauna noi-est4
.
Am un caz de asistență deschis cu GCP, deoarece pare a fi o problemă specifică regiunii.
Există experimente suplimentare pe care le-aș putea oferi pentru a încerca să restrâng cauza? Există probleme comune de configurare GCP care ar putea duce la această problemă?
În lipsa de a mă muta în altă regiune, simt că nu am mai multe opțiuni.