Salt la conținutul principal
Când utilizați Windsurf în WSL (prin Remote - WSL), editorul poate deveni lent, poate înceta să mai răspundă sau se poate deconecta în mod repetat de la backend‑ul WSL. Acest lucru este cel mai frecvent cauzat de extensii care efectuează monitorizare și indexare agresive a fișierelor în sistemul de fișiere WSL, ceea ce saturează protocolul Plan 9 (9P) — puntea de sistem de fișiere dintre Windows și mediul Linux din WSL. Această situație este mai probabilă în repository‑uri mari și atunci când mai multe servere de limbaj rulează în paralel.

​
Simptome

  • Windsurf este vizibil lent sau are latențe atunci când este conectat la WSL
  • Editorul se deconectează frecvent de la backend-ul WSL și încearcă să se reconecteze
  • Deconectările apar în timpul dezvoltării active (de ex., când utilizați Cascade) și atunci când editorul este inactiv
  • Windsurf se blochează sau nu mai răspunde, necesitând repornirea atât a IDE-ului, cât și a WSL (wsl --shutdown)
  • Utilizarea memoriei de către WSL crește în timp, chiar și pe sisteme cu 32 GB+ RAM
  • Jurnalele de diagnostic WSL afișează un număr mare de evenimente P9 Reply_Rlerror (erori de tip „fișierul nu a fost găsit”)
  • Performanța este normală atunci când utilizați Windsurf în afara WSL (de ex., la deschiderea unui folder local din Windows)
  • Soluțiile uzuale (repornirea WSL, reinstalarea Windsurf, creșterea memoriei în .wslconfig) nu rezolvă problema de la sine

​
Cauza principală

Comunicarea dintre Windows și sistemul de fișiere Linux din WSL folosește protocolul Plan 9 (9P), care are un debit de date limitat comparativ cu accesul nativ la sistemul de fișiere. Când extensiile sunt instalate în mediul WSL, unele efectuează monitorizare agresivă a fișierelor și indexare în întregul workspace. În repository-uri mari (de ex., peste 250.000 de fișiere, 5+ GB), acest lucru generează un volum masiv de operațiuni asupra sistemului de fișiere prin puntea 9P, ceea ce poate:
  • Satura capacitatea protocolului
  • Produce mii de erori de tip fișier inexistent (Reply_Rlerror)
  • Determina întreruperea conexiunii dintre Windsurf și backend-ul WSL
  • Contribui, în timp, la creșterea presiunii asupra memoriei în interiorul WSL
Acest efect este amplificat atunci când rulează și mai multe servere de limbaj (de ex., Sorbet, Ruby LSP, TypeScript etc.), deoarece acestea adaugă o suprasarcină suplimentară de monitorizare a fișierelor. Activitatea combinată asupra sistemului de fișiere din partea extensiilor și a serverelor de limbaj poate supraîncărca puntea 9P chiar și pe sisteme cu 32 GB+ de RAM. Un exemplu cunoscut este extensia Vue (Volar), despre care s-a observat că determină o indexare excesivă a fișierelor în mediile WSL chiar și atunci când workspace-ul nu conține fișiere Vue. Această problemă este documentată în ecosistemul VS Code: microsoft/vscode-remote-release#11091 Acest lucru este cu atât mai probabil dacă ați transferat un set mare de extensii din VS Code sau dintr-un alt editor, care nu sunt necesare pentru proiectul curent.

​
Soluții

​
1. Reinstalare curată a serverului Windsurf în WSL

Ștergeți directorul serverului Windsurf din WSL și lăsați Windsurf să îl reinstaleze la următoarea conectare: 
rm -rf ~/.windsurf-server
Apoi reconectați Windsurf la WSL. Serverul va fi reinstalat automat.

​
2. Reduceți la minimum extensiile instalate (impact maxim)

Instalați doar extensiile de care aveți efectiv nevoie pentru repository-ul în care lucrați.
  • Deschideți panoul Extensions în Windsurf în timp ce sunteți conectat la WSL
  • Verificați ce extensii sunt instalate în mediul WSL (nu doar local)
  • Dezactivați sau dezinstalați extensiile de care nu aveți nevoie—în special pe cele care efectuează monitorizare intensivă a fișierelor sau indexare
Extensii cunoscute drept problematice în WSL:
  • Vue (Volar) — despre care s-a confirmat că duce la indexare excesivă a fișierelor prin bridge-ul 9P, chiar și în proiecte care nu sunt Vue. Dezinstalarea doar a acestei extensii a rezolvat deconectările pentru mai mulți utilizatori.
  • Alte extensii de limbaj specifice framework-urilor (Angular, Svelte etc.) pot avea un comportament similar dacă sunt instalate, dar nu sunt necesare pentru workspace-ul curent.
Nu presupuneți că extensiile care funcționează bine într-o configurație locală (non-WSL) se vor comporta la fel în WSL. Bridge-ul 9P al sistemului de fișiere este factorul limitator—extensiile care sunt inofensive local pot deveni destabilizatoare atunci când fiecare operație pe fișier trebuie să treacă prin această barieră de protocol. Reducerea activității de sistem de fișiere generată de extensii reduce în mod direct încărcarea pe bridge-ul 9P.

​
3. Optimizați limitele de resurse WSL

Creați sau editați fișierul %USERPROFILE%\.wslconfig pe gazda Windows (de exemplu, C:\Users\<YourUser>\.wslconfig), cu limite de resurse potrivite pentru configurația sistemului dvs.: 
[wsl2]
memory=16GB
swap=4GB
processors=4
autoMemoryReclaim=gradual
Ajustați valorile în funcție de resursele disponibile ale sistemului dumneavoastră. După ce salvați fișierul, reporniți WSL: 
wsl --shutdown
Apoi redeschideti Windsurf si reconectati-va la WSL.

​
Diagnosticare

​
Verificati jurnalele de diagnosticare WSL pentru erori 9P

Pentru a confirma ca saturatia 9P este cauza problemei, colectati jurnalele de diagnosticare WSL: 
wsl --debug-shell
Sau colectați un pachet complet de date de diagnostic: 
Invoke-WebRequest -UseBasicParsing "https://aka.ms/wsldiag" -OutFile wsldiag.ps1
.\wsldiag.ps1
Căutați volume mari de evenimente Reply_Rlerror în jurnalele 9P/filesystem. Mii (sau chiar mai multe) indică, de obicei, că extensiile sau procesele din WSL generează prea multe cereri către sistemul de fișiere, cu care bridge-ul 9P nu poate ține pasul.

​
Când să folosiți fiecare soluție

  • Minimizați extensiile dacă aveți multe extensii instalate în WSL de care nu aveți nevoie în mod activ sau dacă ați migrat extensii dintr-un alt editor. (Schimbarea cu cel mai mare impact.)
  • Reinstalare curată a serverului dacă starea serverului Windsurf poate fi coruptă sau învechită (de ex., după o actualizare eșuată sau o blocare anterioară).
  • Optimizați .wslconfig dacă WSL consumă în mod excesiv resursele gazdei sau dacă nu ați configurat anterior limite de resurse. (Îmbunătățire generală a stabilității WSL.)
Pentru rezultate cât mai bune, aplicați toate cele trei soluții. Combinația dintre un server curat, extensii minime și limite de resurse ajustate abordează atât cauza principală (saturarea 9P cauzată de activitatea extensiilor), cât și factorii contribuitori (epuizarea resurselor).