Puncte:1

Resetare intermitentă a conexiunii 104 de către peer în GCP us-east4

drapel br

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.

Priya Gaikwad avatar
drapel us
Puteți confirma dacă problema dvs. este rezolvată sau dacă vă confruntați în continuare cu vreo problemă?
Puncte:0
drapel gh

După cum se menționează în Grupuri Google discuție, âEchipa Google Cloud Compute Engine investighează deja această problemă regională care se întâmplă pe „us-east4”. Vă puteți aștepta la o altă actualizare cu privire la RCA (dacă există) în raportul de urmărire a problemelor publice. Simțiți-vă liber să comentați și acolo.â După cum sa menționat în actualizarea unui alt canal de asistență, progresul pentru această problemă poate fi urmărit prin problema publică tracker.

Puncte:0
drapel pe

Am revizuit instrumentul de urmărire a problemelor publice menționat în răspunsul trecut, dar este deja închis, deoarece îi lipsesc suficiente elemente pentru a reproduce problema.

În plus, deoarece nu știm despre configurația dvs. VPC sau regulile dvs. de firewall, pare puțin dificil să depanați în continuare problema cu informațiile date.

Aceasta poate să nu fie soluția la problema dvs., dar v-aș recomanda deschideți un bilet de asistență cu asistență GCP pentru a vă rezolva problema într-un mod mai bun.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.