Raport wewnętrzny · 7 listopada 2026

Dlaczego lokalne strony stanęły po przeniesieniu projektów na NAS

Komputer Adama rozmawia z NAS jedną kolejką, a NAS trzyma kod na wolnych dyskach. Gdy kilka narzędzi naraz przeglądało duże repozytoria, wszystko inne czekało w tej samej kolejce. Część przyczyn usunęliśmy dziś, a do pełnej szybkości potrzebne są jeszcze dwie decyzje.

Dane z pomiarów na komputerze Adama, 12:25–15:30. Nazwy klientów i adresy w sieci pominięte.

14,6 s0,27 sodczyt 100 plików PHP z NAS: w zatorze i po usunięciu jego przyczyny
22,6 s0,43 sjedno wejście na stronę WordPress przed zmianą i w pilocie
4297 → 32zapytań do NAS na jedno wyświetlenie strony w pilocie
7,6 mspierwszy odczyt pliku z dysków NAS; ten sam plik z SSD to ok. 0,007 ms

Jak to dziś działa

Od 6 listopada pliki wszystkich projektów leżą na NAS. Na komputerze Adama zostały narzędzia, zależności (vendor, node_modules), historia Git, bazy danych i Docker. Podglądy stron, Mentor, edytory i agenci AI czytają kod z NAS przez sieć, wszyscy przez to samo połączenie.

Schemat: komputer Adama i NAS połączone jednym połączeniem SMB Po lewej cztery grupy programów na komputerze Adama. Wszystkie korzystają z jednego szyfrowanego połączenia SMB do NAS, które w zatorze obsługiwało około 600 operacji na sekundę. Po prawej NAS z kodem projektów. Komputer Adama (SSD) 20 podglądów stron (Docker, PHP, WordPress) Mentor (API, kolejki, harmonogram co minutę) Agenci AI i edytory (Codex, Claude, T3, Zed) Git: ok. 30 repozytoriów, statusy w tle Na SSD: zależności, .git, bazy danych, obrazy Docker 1 połączenie SMB (szyfrowane) jeden proces po stronie NAS, ok. 600 operacji/s w zatorze NAS-BB · UGREEN kod wszystkich projektów, materiały, archiwa (241 GB) dyski: odczyt jak z talerzy (model do potwierdzenia)

Sieć jest w porządku: 10 Gb/s i ok. 0,2 ms opóźnienia. Problem leży w liczbie drobnych pytań o pliki. Każde z nich czeka w jednej kolejce, a NAS obsługuje je po kolei.

Ile kosztuje jedno pytanie o plik

Strona WordPress przy jednym wyświetleniu sprawdza około 3600 plików. Jeśli każde sprawdzenie trwa ułamek milisekundy, nikt tego nie zauważy. Na wolnych dyskach albo w kolejce za innym programem robią się z tego dziesiątki sekund.

Czas jednej operacji na pliku, skala logarytmiczna SSD ok. 7 mikrosekund. NAS, plik w pamięci NAS ok. 0,2 ms. NAS, pierwszy odczyt z dysku ok. 7,6 ms. NAS w zatorze od 40 do 150 ms. 1 µs10 µs 0,1 ms1 ms 10 ms100 ms 1 s Odczyt pliku z SSD Adama SSD: ok. 0,007 ms (100 plików w 0,0007 s) ~7 µs NAS, plik w pamięci NAS NAS, ponowne listowanie: ok. 0,2 ms na plik ~0,2 ms NAS, pierwszy odczyt z dysku NAS, zimne metadane: ok. 7,6 ms na plik (mediana 25 katalogów) 7,6 ms NAS w zatorze (kolejka 26–105) NAS w zatorze: 40–150 ms na operację 40–150 ms

Pierwszy odczyt z dysków NAS jest ok. tysiąc razy wolniejszy od SSD. NAS pamięta odczytane metadane tylko przez kilkadziesiąt minut, więc strona otwierana raz na jakiś czas prawie zawsze trafia na wolny wariant.

Co spowalniało i co to potwierdza

Każda przyczyna ma pomiar albo ślad wywołań systemowych. Kolejność odpowiada wpływowi na to, co widzieli użytkownicy.

  1. Osierocone procesy Git zapchały kolejkę

    Narzędzie agenta AI uruchomiło trzy przeglądy repozytorium dużej strony WordPress i samo się zamknęło. Procesy pracowały dalej przez 69 minut, choć nikt nie czekał na ich wynik. Razem z innymi zadaniami trzymały w kolejce do NAS od 26 do 105 żądań. Każdy odczyt pliku przez stronę czekał wtedy 40–150 ms. Stąd wcześniejszy pomiar: 200 plików PHP w 471 s.

    Po zakończeniu tych procesów kolejka spadła do zera, a odczyt 100 plików PHP przyspieszył z 14,6 s do 0,27 s. Ta sama praca przez osobne połączenie z NAS trwała w zatorze 0,7–1 s zamiast 9–20 s.

  2. Git po migracji uznawał każdy plik za zmieniony

    Indeksy Git zostały na SSD z danymi starego dysku. Dla Gita każdy plik wyglądał na podejrzany, więc każdy przegląd czytał i porównywał całą zawartość repozytorium przez sieć. Agenci robią takie przeglądy w tle co kilkanaście sekund i nigdy nie zapisują wyniku. Dotyczyło to 10 repozytoriów, w tym czterech stron po 13–25 tys. plików.

    Odświeżyliśmy indeksy. Przegląd największych repozytoriów nadal trwa 2,5–9 minut, ale nie czyta już całych plików.

  3. PHP sprawdza każdy plik przy każdym wejściu

    Ustawienie opcache wymagane w standardzie dev każe sprawdzić datę każdego dołączanego pliku. Przez 60 sekund pamięta to system, potem wszystkie ~3600 pytań idzie do NAS naraz. Pierwsze wejście po minucie przerwy trwało 20–70 s albo kończyło się błędem 504.

    Ślad jednego wejścia: 4297 wywołań na plikach z NAS, w tym 3603 sprawdzenia dat (sama wtyczka SEO: 1335).

  4. Dyski NAS są wolne przy pierwszym odczycie

    Pierwsze listowanie katalogu kosztuje ok. 7,6 ms na plik, powtórne 48 razy mniej. Ten sam katalog potrafił się listować raz 0,3 s, raz 16 s, zależnie od tego, co akurat robił NAS.

  5. Rzeczy, które dokładały pracy

    Kosz NAS w głównym folderze nie był wykluczony z Gita, a wylistowanie go trwa ponad 90 s. Brama podglądów przy budzeniu strony ponawiała zapytanie co 10 s i zostawiała w tle kolejne zimne starty. Restart bramy przegląda katalogi wszystkich stron przez 25 minut. W Mentorze serwer API sprawdza przy każdym żądaniu katalog public na NAS.

Co działa, a co nie

Działa

  • Sieć i baza danych. 10 Gb/s, 0,2 ms; 50 zapytań do bazy w 0,5 ms.
  • Brama podglądów. Nie dokłada czasu. Błąd 504 pochodził z PHP.
  • Strona w pilocie. Kolejne wejścia 0,18–0,43 s, zmiany w kodzie widać na stronie.
  • Git po odświeżeniu indeksów. Minuty zamiast godzin.
  • Front Mentora. Kilka milisekund.

Częściowo

  • Pozostałe strony WordPress. 0,3–1,3 s przy kolejnych wejściach, 20–70 s po minucie przerwy.
  • API Mentora. ok. 190 ms na żądanie; z SSD byłoby to kilkanaście ms.
  • Przegląd Git dużych repozytoriów. 2,5–9 min, gdy NAS ma zimne dane.
  • Pilot po dłuższej przerwie. 1,7–3,1 s przy obciążonym NAS.

Nie działa dobrze

  • Pierwsze wejście po uśpieniu strony. Strony śpią po 2 h; pierwsze wejście kompiluje kod z NAS i może skończyć się błędem 504.
  • Restart bramy podglądów. 25 minut dużego obciążenia NAS.
  • Zmiany z innych komputerów w pilocie. Widoczne dopiero po skanie co 15 min.

Wpływ na codzienną pracę

Wszystkie projekty dzielą jedną kolejkę do NAS. Ciężka operacja w jednym projekcie spowalnia każdy inny, także u innych osób.

CzynnośćCo się dzieje dziśPo pełnym wdrożeniu planu
Podgląd strony klientaKolejne wejścia do ok. 1 s, po przerwie 20–70 s albo 504.Kolejne wejścia 0,2–0,4 s. Pierwsze wejście po uśpieniu nadal wolniejsze, dopóki NAS nie dostanie SSD.
Agenci AI na repozytorium stronyKażdy agent co kilkanaście sekund prosi Git o stan repozytorium. Na repozytorium z całym WordPressem to minuty pracy NAS, a kilku agentów naraz zapycha kolejkę dla wszystkich.Osobne połączenie dla narzędzi, strażnik osieroconych procesów, mniejsze repozytoria tam, gdzie śledzony jest tylko motyw.
Kilka projektów narazTesty, przeglądy Git i kopie w jednym projekcie spowalniają podglądy pozostałych.Podglądy stron na osobnym połączeniu, niezależne od narzędzi.
MentorAPI ok. 190 ms, harmonogram co minutę uruchamia procesy czytające kod z NAS.Pliki statyczne poza NAS, cache PHP dla procesów CLI: kilkadziesiąt ms.
Edycja z innego komputera (np. Mac przez SMB)Zmiana widoczna do 60 s później; w pilocie do 15 min.Powiadomienia o zmianach z NAS skracają to do sekund.
Restart narzędzi i usługRestart bramy podglądów obciąża NAS przez ok. 25 min.Brama bierze listę katalogów z osobnego połączenia; restarty krótkie.

Pilot na jednej stronie

Na jednej stronie WordPress (13,5 tys. plików) PHP przestał sprawdzać daty plików przy każdym wejściu. Brama podglądów sama zgłasza PHP, który plik się zmienił, i tylko ten plik jest kompilowany od nowa. Gdy nie wiadomo, co się zmieniło, PHP przeładowuje całość, co trwa dłużej, ale daje pewność. Test edycji: zmiana pojawiła się na stronie, a po cofnięciu zniknęła.

Czas przed i po zmianach, skala logarytmiczna w sekundach Odczyt 100 plików PHP: 14,6 s przed, 0,27 s po. Wejście na stronę, ślad: 22,6 s przed, 0,43 s po. Wejście po minucie przerwy: 21,7 s przed, 1,7 do 3,1 s po. Kolejne wejście: 1,18 s przed, 0,18 s po. 0,1 s1 s 10 s100 s Odczyt 100 plików PHP (zator → bez zatoru) po: 0,27 s przed: 14,6 s 0,27 s14,6 s Wejście na stronę, ślad wywołań (pilot) po: 0,43 s przed: 22,6 s 0,43 s22,6 s Wejście po minucie przerwy (pilot) po: 1,7–3,1 s po: od 1,7 s przed: 21,7 s 1,7–3,1 s21,7 s Kolejne wejście na stronę (pilot) po: 0,18 s przed: 1,18 s 0,18 s1,18 s

Po pilocie jedno wejście wysyła do NAS 32 zapytania zamiast 4297. Pozostały głównie sprawdzenia plików, których nie ma. System nie zapamiętuje takiej odpowiedzi dłużej niż sekundę, więc przy obciążonym NAS nadal kosztują czas.

Co zrobiliśmy 7 listopada

  1. Zakończone trzy osierocone procesy Git (tylko odczyt, bez odbiorcy wyniku). Kolejka do NAS spadła z ok. 26 żądań do zera.
  2. Brama podglądów przy budzeniu strony czeka na jedną odpowiedź zamiast ponawiać zapytanie co 10 s.
  3. Kosz NAS i katalogi testowe migracji wykluczone z przeglądów Git w głównym repozytorium.
  4. Odświeżone indeksy Git w 10 repozytoriach projektów (zawartość porównana, nic nie ukryte, kopie zapisane).
  5. Pilot cache PHP na jednej stronie, z automatycznym odświeżaniem po zmianie pliku.
  6. Restart bramy podglądów, który włączył obie poprawki. Test edycji przeszedł.

Każda zmiana ma kopię i opisany sposób cofnięcia w karcie zadania. Nie przenosiliśmy plików i nie usuwaliśmy danych.

Co dalej i co trzeba zdecydować

Od największego efektu przy najmniejszym koszcie.

Cache PHP z pilota na wszystkie strony

Po tygodniu obserwacji pilota. Szybkie wejścia na każdej stronie, bez zakupów.

Efekt

Kolejne wejścia 0,2–0,4 s, po przerwie kilka sekund zamiast kilkudziesięciu.

Kto

Zmiana standardu dev; wdrożenie lokalne.

Osobne połączenia z NAS dla stron i dla narzędzi

Podglądy stron przestają czekać za Gitem, testami i agentami.

Efekt

Koniec zatorów, w których jedna operacja blokuje wszystkich.

Kto

Administrator uruchamia jeden przygotowany skrypt (z kopią i cofnięciem).

Dyski SSD w NAS dla folderu projektów

Osobna pula SSD albo cache SSD w NAS. Najpierw trzeba sprawdzić model, dyski i wolne sloty.

Efekt

Pierwszy odczyt pliku z kilku milisekund do ułamka milisekundy. Pomaga też Gitowi i stronom po uśpieniu.

Kto

Właściciel NAS: sprawdzenie w panelu UGOS, ewentualny zakup.

Porządek z agentami i repozytoriami

Strażnik osieroconych procesów Git, .gitignore w repozytoriach, które śledzą tylko motyw (jedno ma 118 plików śledzonych i 17 tys. nieśledzonych), poprawki w Mentorze.

Efekt

Mniej pracy w tle i mniejsze ryzyko powtórki dzisiejszego zatoru.

Kto

Lokalnie; .gitignore za zgodą opiekuna projektu.

Plan B: kopia robocza na SSD Adama

Gdyby powyższe nie wystarczyło. NAS zostaje głównym miejscem plików, a strony czytają kopię synchronizowaną w sekundach.

Efekt

Czasy jak przed migracją, niezależnie od NAS.

Kto

Zmiana standardu „pliki stron fizycznie na NAS”; zajmuje miejsce na SSD.