6 postów z tagiem "Optimization"

Gdy aplikacja zwalnia pod obciążeniem, pierwszym odruchem jest podniesienie maximumPoolSize z 20 do 100. Zwykle robi się gorzej, nie lepiej. Pula połączeń to nie jest zapas mocy, tylko kolejka przed bazą, która ma tyle samo rdzeni co przed zmianą. Kolejka istnieje tak czy inaczej. Rozmiar puli decyduje tylko o tym, gdzie ją widać: w puli, gdzie da się ją zmierzyć, czy w schedulerze systemu i w lock managerze Postgresa, gdzie jej nie widać. Poniżej arytmetyka rozmiaru puli, PgBouncer w trybie transaction z tym, co się w nim psuje, pułapka dwóch pul i metryka, która to wszystko pokazuje.

Na laptopie z iGPU i jednokanałowym RAM-em intuicja „większy model = wolniejszy, GPU = szybsze niż CPU" rozpada się całkowicie. Model Qwen3-Coder o 30 miliardach parametrów, uruchomiony na samym procesorze, generuje 12–17 tokenów na sekundę. Mistral Small o 24 miliardach parametrów, w całości załadowany na GPU, generuje 0,62 tokena na sekundę — dwadzieścia razy wolniej, przy mniejszym pliku. Różnicy nie robi ani backend, ani kwantyzacja, ani zasilanie z kabla. Robi ją architektura: mixture-of-experts kontra dense.

Kod, który w pętli odpytuje bazę pięćset razy, nie jest wolny dlatego, że baza jest wolna. Każde z tych zapytań kosztuje na serwerze dziesiątki mikrosekund, a cała reszta to czekanie na sieć — i to czekanie skaluje się liniowo z liczbą iteracji. Na lokalnym Postgresie problem jest niewidoczny, na produkcji w innej strefie dostępności ten sam kod to timeout. Poniżej cztery poziomy batchowania, od WHERE id IN (...) po COPY, z pułapkami, które w każdym z nich wywracają sprawę.

Utrata kontroli nad ścieżką zapisu lokalnych modeli LLM prowadzi do krytycznego przepełnienia dysku systemowego na serwerach VPS. Implementacja modelu Bielik poprzez środowisko Ollama wymaga precyzyjnej rekonfiguracji architektury przechowywania danych, aby zagwarantować stabilność systemu operacyjnego i obniżyć koszty infrastruktury z zachowaniem pełnej izolacji danych.

„Czysty Kod. Podręcznik dobrego programisty" Roberta C. Martina (Uncle Boba) to jedna z tych książek, które programista powinien przeczytać przynajmniej raz — a potem wracać do nich za każdym razem, gdy trafi na kod, który budzi wątpliwości.

Zebrałem z niej szczegółowe notatki z każdego rozdziału: kluczowe zasady, przykłady kodu przed i po refaktoryzacji oraz praktyczne wnioski gotowe do zastosowania od zaraz.

W ramach wsparcia projektu open-source ESP32Marauder zająłem się analizą i przebudową mechanizmu zarządzania ustawieniami urządzenia. Choć z pozoru był to prosty element systemu, jego dotychczasowa implementacja skrywała poważny dług technologiczny, który negatywnie wpływał na działanie całego narzędzia. Postanowiłem to zmienić.