Pierderea pachetelor în interogarea PGSQL duce la un timp de recuperare foarte lung

Avem o problemă de rețea aparent complexă cu care m-am luptat de ceva vreme și mă întrebam dacă are cineva gânduri

Avem un număr de servere în AWS Londra și un alt set de servere în CoLos din Londra și Frankfurt

Ne conectăm de la AWS la aceste CoLos folosind AWS DirectConnect

Serverele AWS se conectează în principal la serverele CoLo folosind PGSQL, serverele CoLo găzduind bazele de date. Interogările sunt executate înainte și înapoi toată ziua.

De asemenea, serverele CoLo împing un volum mare de date înapoi în AWS sub formă de Rsync și Elastic. Nu vedem niciodată probleme cu Rsync sau Logstash push în Elastic.

În general, totul funcționează bine, cu excepția cazului în care un anumit tip de interogare PGSQL se blochează între AWS și CoLo.

Parcurgând fișierele PCAP, vedem următoarele:

• Pentru cea mai mare parte a sesiunii, serverul (CoLo) trimite 1460 de octeți de date, iar clientul (AWS) ACK acţionează. Acest lucru continuă înainte și înapoi fără probleme
• Apoi vedem serverul trimite de obicei între 5-20 de segmente care nu ajung la client.Această scădere ar putea fi oriunde, deoarece calea rețelei trece prin 2-3 operatori diferiți și DirectConnect
• Apoi clientul începe corect să facă ACK până la ultimul segment pe care l-a primit
• În momentul în care serverul a primit ACK-ul care indică pierderea pachetului, a trimis încă 10-20 de segmente
• În cele din urmă, serverul începe să trimită din nou primul segment pierdut, care este primit și ACK imediat.
• Serverul trimite apoi două dintre segmentele „actuale” spate în spate, dar din nou clientul ACK spune că încă nu este prins încă
• În acest moment, serverul începe o retragere exponențială între trimiterea unui segment „actual” și a unui segment vechi până când atinge intervalul de 120 de secunde.
• Procesul se repetă după cum urmează:
  1. Serverul trimite cel mai recent segment lipsă
  2. Clientul acceptă acest segment imediat
  3. Serverul trimite două segmente „actuale” în succesiune rapidă
  4. Clientul le ACK cu același ACK ca la pasul 2
  5. Serverul se retrage exponențial și se întoarce la pasul 1 (decalajul crește până când ajunge la 120 de secunde)
• În cele din urmă, după o perioadă suficient de lungă (uneori până la o oră), serverul poate retrimite toate segmentele pierdute și continuă ca de obicei.

Trebuie reținut următoarele:

• În niciun moment în captură nu este setată o dimensiune de fereastră zero, de fapt, în timpul recuperării, clientul își mărește fereastra cu ~ 6 octeți la fiecare ACK
• Rularea netstat nu arată nicio așteptare de primire sau transmitere în timpul incidentului
• Rularea comenzii „ss” pare să arate activarea algo-ului de evitare a congestionării cubice

Evident, orice pierdere de pachete nu este ideală, dar întrebarea mea este că acesta nu este un comportament corect, deoarece 10-20 de segmente pierdute durează până la orice oră pentru a se recupera?

Aceasta seamănă foarte mult cu problema noastră: https://engineering.skroutz.gr/blog/uncovering-a-24-year-old-bug-in-the-linux-kernel/ S-ar putea să vorbesc cu gazdele noastre de server CoLo și să văd despre o actualizare a nucleului