Cześć,
od kilku dni pracuję na nowy laptopie Lenovo, ta sama firma tylko dużo wyższy model.
Przeniosłem wszystkie dane, uruchomiłem projekt Spring Boot, uruchamiam wszystkie testy i okazuj się, że wykonują się ponad 2 razy wolniej ni na starym laptopie 
kombinowałem z ustawieniami zasilania, oba laptopy mają identycznie ustawienia, to samo sdk ten sam sytem Ubuntu 22 a mimo to na starym testy idą nieporównywalnie szybciej.
Podczas wykonywania testów patrzę w System monitor, na starym laptopie procesor pracuję prawie cały czas na max wydajności, na nowym nie przekracza zazwyczaj 30%
Ktoś może spotkał się z podobnym problemem i wie jak zmusić procka do wydajniejszej pracy? :) na nowym laptopie jest Intel® Core™ Ultra 7 165U × 14 na starym jest i5
wszystkie porównania w necie obu procesorów wskazują na dużą przewagę 165U
Odpalasz testy równolegle?
Może nowszy cpu ma wolniejsze rdzenie a testy lecą jednowątkowo?
Nie odpalam ich równolegle, przy testach integracyjnych byłby problem, lecą jednowątkowo
No to sprawdź dokładnie specyfikację cpu w starym komputerze, czy na pewno ma wolniejsze rdzenie niż nowy.
To obciążenie CPU 100% vs 30% obserwowałeś na całym CPU czy konkretnym, pojedynczym rdzeniu?
Tak wygląda specyfikacja obu:
a tak podczas uruchomionych testów:
Sprawdź szybkość dysków, częstotliwość RAM oraz CL ramu. Sprawdź czy stary laptop miał OC. Uruchom profiler testów i zobacz ktore operacje się wykonują dłużej.
szary88 napisał(a):
wykonują się ponad 2 razy wolniej
Ale mówimy o różnicy 10 minut -> 20 minut, 10 s -> 20 s czy o różnicy 120 ms -> 240 ms?
Bo czynników tu może być w opór dużo, samo JVM też się "rozgrzewa", i na temat samego poprawnego sposobu mierzenia czasu wykonywania testu można napisać książkę.
Czy np wersje Springa / Spring Boota są te same? Czy bierzesz po prostu "latest"?
Uruchamiasz testy w IDE czy w konsoli?
Korzystasz z obrazów dockerów w testach? Jak wygląda system dockerowy na jednym i na drugim lapku?
Jak wygląda baza? Łączą się z nią podczas testów? Jak to wygląda na jednym i na drugim lapku
Podejrzewam, że scheluder świruje, bo rdzenie mają różną wydajność. Spróbuj ograniczyć proces do 4 najwydajniejszych wirtualnych rdzeni procesora (których konkretnie to nie wiem, ale strzelam, że do czterech pierwszych).
Zobacz czy masz najnowszy kernel (6+). Nie wiem, czy scheduler w starych wersjach ogarnia dobrze rdzenie P+E.
Procki w Intelu też lubią się grzać jak głupie, zainstaluj https://man.archlinux.org/man/extra/thermald/thermald.8.en i zobacz czy pomogło
Pinek napisał(a):
szary88 napisał(a):
wykonują się ponad 2 razy wolniej
Ale mówimy o różnicy 10 minut -> 20 minut, 10 s -> 20 s czy o różnicy 120 ms -> 240 ms?
Bo czynników tu może być w opór dużo, samo JVM też się "rozgrzewa", i na temat samego poprawnego sposobu mierzenia czasu wykonywania testu można napisać książkę.
Czy np wersje Springa / Spring Boota są te same? Czy bierzesz po prostu "latest"?
Uruchamiasz testy w IDE czy w konsoli?
Korzystasz z obrazów dockerów w testach? Jak wygląda system dockerowy na jednym i na drugim lapku?
Jak wygląda baza? Łączą się z nią podczas testów? Jak to wygląda na jednym i na drugim lapku
na starym laptopie testy wykonują się 2 minuty 30 sekund na nowym 6 minut 10 sekund (za każdym razem dokładnie tyle samo)
Wersja Sping Boota jest identyczna, jdk też identyczne
W obu przypadkach testy uruchamiane są w Intelij (ta sama wersja, te same wszystkie ustawienia, skopiowane ze starego na nowy)
Testy integracyjne korzystają z dockera, uruchamiany jest obraz, liquidbase stawia bazę mysl 8.0 i na tym wykonywane są testy, obraz wyeksportowałem na starym laptopie
i zaimportowałem na nowym, więc to jest dokładnie to samo.
Zanim na nowym postawiłem Ubuntu 22 zainstalowałem najpierw wersje 24 i co ciekawe tam również testy wykonywały się w czasie 6:10.
Dla porównania teraz zainstalowałem 22, żeby wszystko było identycznie jak na starym i cały czas jest 6:10 :/
Sprawdzę to co pisaliście i wieczorem postaram się odpowiedzieć na pozostałe posty.
@szatkus1 podpowiesz w jaki sposób można "ograniczyć proces do 4 najwydajniejszych wirtualnych rdzeni procesora "
Do usług https://www.baeldung.com/linux/process-set-processor-affinity
Do tego pewnie przejrzenie /proc/cpuinfo może pomóc w zidentyfikowaniu, które rdzenie są P a które E.
szatkus1 napisał(a):
Do usług https://www.baeldung.com/linux/process-set-processor-affinity
Do tego pewnie przejrzenie /proc/cpuinfo może pomóc w zidentyfikowaniu, które rdzenie są P a które E.
Korzystając z tego co podesłałeś udało się ustalić, że tylko pierwszy i drugi rdzeń mogą pracować z częstotliwością 4900 MHz
uruchomiłem Intelij wymuszając aby korzystał tylko z pierwszego rdzenia. W htop i system monitorze widać, że faktycznie go używa
ale czas wykonania testów jest prawie taki sam jak bez wymuszenia pracy na jednym najszybszym rdzeniu, ponad 6 minut.
Zauważyłem, że problem dotyczy tylko testów integracyjnych. Testy jednostkowe gdzie nie stawiany jest cały kontekst wykonują się minimalnie szybciej na nowym laptopie więc jutro jeszcze temu się przyjrzę może uda się ustalić wąskie gardło.
W intellij (nie wiem czy w wersji free) masz toola do profilowania aplikacji, spróbuj tak ja ksugeruje Riddle przyjrzeć się gdzie te testy spędzają najwięcej czasu.
https://www.jetbrains.com/help/idea/profiler-intro.html
RequiredNickname napisał(a):
W intellij (nie wiem czy w wersji free) masz toola do profilowania aplikacji, spróbuj tak ja ksugeruje Riddle przyjrzeć się gdzie te testy spędzają najwięcej czasu.
https://www.jetbrains.com/help/idea/profiler-intro.html
Na tych laptopach akurat mam wersję Community więc nie mam tej opcji ale na obu komputerach zainstalowałem VisualVm i chyba znalazłem przyczynę.
Przy uruchamianiu testu zapytania do bazy na starym wykonują się wielokrotnie szybciej niż na nowym, np:
Stary:
ALTER TABLE PROMOTIONS MODIFY id int NOT NULL AUTO_INCREMENT 40.4 ms (0.8%) 1
Nowy:
ALTER TABLE PROMOTIONS MODIFY id int NOT NULL AUTO_INCREMENT 425 ms (1.7%) 1
Teraz tylko trzeba ustalić czemu.
Moze to kwestia ustawienia docker volume dla tej zdockeryzowanej bazki?
Tgc napisał(a):
Moze to kwestia ustawienia docker volume dla tej zdockeryzowanej bazki?
Tak, to najwyraźniej kwestia ustawień tworzonego kontenera.
Za każdym razem gdy uruchamiane są testy tworzony jest nowy kontener i do tej pory w parametrach startowych było tylko:
--log-bin-trust-function-creators
dodałem na nowym laptopie
"--log-bin-trust-function-creators",
"--innodb_buffer_pool_size=1G",
"--innodb_log_file_size=256M",
"--innodb_flush_log_at_trx_commit=2",
"--innodb_flush_method=O_DIRECT",
"--skip-innodb-doublewrite",
"--max_connections=200",
"--log-error-verbosity=2"
i powyższe zapytanie już nie wykonuje się 425 ms tylko
ALTER TABLE PROMOTIONS MODIFY id int NOT NULL AUTO_INCREMENT 95,4 ms (0,8%) 1
ale to i tak jeszcze ponad 2x wolniej niż na starym laptopie więc coś jeszcze trzeba pozmieniać
Za każdym razem gdy uruchamiane są testy tworzony jest nowy kontener i do tej pory w parametrach startowych było tylko:
czemu nie użyjesz .withReuse(true) w testach integracyjnych dla tworzonych kontenerów ?
Minusem jest fakt że trzeba je zamknąć po wszsytkich testach (bo się nie usuwają), ale to załatwia containerName.stop()
Tu masz fajny przykład jak sobie czyścić automatycznie kontenery -> https://gist.github.com/albi23/bfedb38da19054939a8be2fa280be08a
@aolo23 to raczej mojego problemu nie rozwiąże.
Dodanie parametrów przy tworzeniu kontenera pomogło ale zarówno na nowy jak i na starym laptopie więc finalnie to nie jest głwny bloker.
Sprawdziłem dyski, odczyt i zapis na nowym jest znacznie lepszy
Stary laptop:
Zapis: 879 MB/s vs 2.3 GB/s na nowym
Odczyt: 390 MB/s vs 2.1 GB/s na nowym
Ram LPDDR5 Częstotliwość: 7467 MT/s (prędkość skuteczna) / 6400 MT/s (prędkość skonfigurowana)
vs
LPDDR3 Częstotliwość: 2133 MHz (0,5 ns)
na nowym miałem trochę nowszą wersję dockera, zmieniłem na dokładnie tą wersje która jest na starym.
Patrzę w ustawieniach dockera, róznica jest tylko tu:
Stary laptop: 8 CPU, 15.43 GiB pamięci RAM
Nowy laptop: 12 CPU, 30.8 GiB pamięci RAM
pozostałe wartości takie same.
Kończą mi się już pomysły a w testach zapytania na nowym wykonują się cały czas 2x wolniej :/
Jakieś oprogramowanie szpiegujące?
Swojego czasu miałem spory problem przez różnego typu korpobloatware które analizowały każdy dostęp do pliku etc.
@opiszon nic takiego nie ma, sam tu wszytko instalowałem od zera.
Intel ostatnio nie ma dobrej passy, żeby się nie okazało, że i w moim modelu jest jakaś wada :)
szary88 napisał(a):
@opiszon nic takiego nie ma, sam tu wszytko instalowałem od zera.
Intel ostatnio nie ma dobrej passy, żeby się nie okazało, że i w moim modelu jest jakaś wada :)
Na logikę (która oczywiście w IT czasem zawodzi) - skoro na nowym lapku processor się nudzi (działa na 30%) to raczej nie to jest problemem.
Jest możliwe, że winą jest jakaś konfiguracja dockera na hoście (albo w ogóle konfiguracja tego linuxa):
ustawienia sieci (host, bridged),
swappines,
inne parametry sysctl,
może nawet java (ta na hoście), używasz sdkman? (żeby mieć tą samą).
no i na pewno nie odpalaj testów (w celu porównania) z intellij, bo to dodatkowa komplikacja.
nie wiem jak intellij, ale kiedyś mocno wydajność zaburzała słaba konsola w Eclipse (era dinozaurów) - ale serio, jak było dużo "printlnów" to różnica była dramatyczna. Bo może być tak, że wina jest po stronie intellij :-)
Ej, właśnie, bo to chyba wszyscy przeoczyli.
A co gdyby puścić te testy normalnie w terminalu, bez intellij.
Inny trop - może masz na starym kompie inaczej skonfigurowanego mavena używanego przez intellij (może chodzić na de facto innej javie, inny maven itp).
Używam Gradla, testy w konsoli tez odpalałem, efekt ten sam, na nowym 2x wolniej.
Wersja Javy identyczna na obu. Coś musi być z tym dockerem, nie przypominam sobie żebym na starym laptopie coś kombinował w jego ustawieniach, działało wszystko od początku, wydajność raczej zadowalająca więc chyba tam nic nie zmieniałem ale już kurde nie wiem
porównaj docker info
porównaj opcje GRADLE_OPTS , gradle.properties etc.
najlepiej byłoby wyizolować jeden propsty test i odpalić np. pod jmh, żeby upewnić się co do wartości (to, że jedno czy kilka zapytań zadziała wolniej to nic nie znaczy).
- Ta sama wersja OS? Ta sama wersja Dockera? Ta sama wersja obrazu kontenera?
Jeśli odrzucimy zgadywanie, to dalszy usystematyzowany troubleshooting wymaga zbierania i analizy danych:
- Na 100% wiesz, że to kwestia tylko zapytań? (np. odpaliłeś jvm z flighrecorderem, a później to analizowałeś?)
- Jesteś w stanie do obrazu kontenera dorzucić monitoring?( np. zbudować custom image z dodanym https://0x.tools , tak by oprócz bazy podnosił się profiling) -> dostaniesz dane dotyczące tego co się dzieje w kontenerze podczas wykonywania zapytań
- Jesteś w stanie zebrać performance counters z windowsa podczas wykonywania testów? (to powinno dać pogląd, czy problemy są na styku windows -> docker, czy raczej wewnątrz kontenera)
@jarekr000000 docker info porównywałem, wersja dockra jest ta sama
różnice są tylko tu:
containerd version: 472731909fa34bd7bc9c087e4c27943f9835f111
runc version: v1.1.13-0-g58aa920
...
CPUs: 14
Total Memory: 30.8GiB
vs
containerd version: d2d58213f83a351ca8f528a95fbd145f5654e957
runc version: v1.1.12-0-g51d5e94
CPUs: 8
Total Memory: 15.43GiB
gradle.properties jest ten sam.
GRADLE_OPTS nie jest ustawiony na obu laptopach
@yarel
Na obu komputerach jest Ubuntu 22, ta sama wersja Dockera, kontener jest tworzony za każdym razem przy uruchamianiu testu na podstawie obrazu który wyeksportowałem na starym laptopie i zaimportowałem na nowym.
Ad1. nie jestem pewien na 100% ale to od razu rzuca się w oczy. Odpalam teraz tylko jeden test integracyjny w konsoli na obu laptopach i patrzę w profiler. W JDBC za każdym razem mam podobny wynik do tego poniżej.
AD2. nie robiłem tego ale pokombinuje
AD3. używam ubuntu ale tu może też takie dane dane da się wyciągnąć
Szukałem też jakiś sterowników ale niestety na stronie lenovo nic nie ma dla tego modelu na linuxa
Ja bym dalej węszył w kierunku tych rdzeni. Różnica wydajności powyżej to pi razy oko tyle ile Core-E są wolniejsze od Core-P. Może docker z jakiegoś powodu przydziela kontenerom słabsze rdzenie?
@szatkus1 wymusiłem żeby test w konsoli korzystał z rdzenia 0 i to działa bo widać w system monitorze, dockera teoretycznie też po pid zmusiłem do używania rdzenia 1 czyli drugiego najszybszego ale nie widzę, żeby z niego korzystał, muszę znaleźć jakieś narzędzie które to potwierdzi bo w htop nie widzę rdzenia.
Chociaż mam cichą nadzieję, że to jednak nie to, bo kupować laptopa z nowym prockiem i ręcznie sterować rdzeniami, żeby był szybszy niż stary laptop to już naprawdę słabe :)
szary88 napisał(a):
@szatkus1 wymusiłem żeby test w konsoli korzystał z rdzenia 0 i to działa
Zasadnicze pytanie: czy cokolwiek o zmienia w czasach działania testów?
Nic nie zmieniło.
W dokumentacji dockera znalazłem, że uruchamiając kontener również można sterować jakie zasoby mu przydzielić:
https://docs.docker.com/engine/containers/resource_constraints/
testowałem różne kombinacje ale niestety efekt ten sam, zapytania wykonują się jak na screenie który wkleiłem kilka postów wcześniej.
Skończyły mi się już pomysły gdzie szukać przyczyny tak wolnego działania tych testów.