Forum Użytkownikow Subiekt GT
InsERT GT => Subiekt GT => Wątek zaczęty przez: globaltc w Kwiecień 08, 2019, 15:32:11
-
Panowie,
Szukam sugestii. Przesiadłem sie z I3 na Xenona, dodatkowo z SQL SRV 2008 na 2017, jakie moje zdziwienie gdy okazało się, że długotrwałe zapytania wykonują się przeszło dwa razy wolniej. Gdzie szukać przyczyn takiego stanu rzeczy? Na nowym serwerze zrobiłem dearchiwizację.
-
Panowie,
Szukam sugestii. Przesiadłem sie z I3 na Xenona, dodatkowo z SQL SRV 2008 na 2017, jakie moje zdziwienie gdy okazało się, że długotrwałe zapytania wykonują się przeszło dwa razy wolniej. Gdzie szukać przyczyn takiego stanu rzeczy? Na nowym serwerze zrobiłem dearchiwizację.
Jakie i3, jaki "xenon"? Ile ramu tu ile tam, jakie dyski...? Jakie edycje SQL-i, jak skonfigurowane...? Jaki compatiblity level ustawiony na nowej maszynie etc. etc.
-
I3-4160 3,6Ghz na Xenon E1-2124 3,3 Ghz. Ram z 8GB DDR3 na 16GB DDR4 2666. Dysk SSD na SSD w Raid1. SQL2008 na SQL2017 obydwa express. Compatibility ustawiony na 2008.
-
Jakie masz wyniki odczytu/zapisu na tym raidzie (pokażesz zrzut)?
-
I3-4160 3,6Ghz na Xenon E1-2124 3,3 Ghz. Ram z 8GB DDR3 na 16GB DDR4 2666. Dysk SSD na SSD w Raid1. SQL2008 na SQL2017 obydwa express. Compatibility ustawiony na 2008.
Xenony to procki w Xbox-ach 360 ;) W serwerach są Xeony.
Jak masz zbliżone wyniki zapisu i odczytu to można pogrzebać dalej w samym SQL-u. Jak chce ci się dłubać samemu to zrób kopię bazy i przestaw jej compatibility na 140 i odbuduj indeksy i wtedy sprawdź te wlekące się zapytania. Dodatkowy RAM przy Expressie niewiele zmienia bo wykorzystanie pamięci jest ograniczone do 1GB jeśli mnie pamięć nie myli.
-
Czytanie 406 - 422 MB/s
Edit: Na MS SQL 2008 na nowej maszynie mam wyższe osiągi. Teraz pytanie jak zmusić MS SQL 2017 do szybszego działania... ? Compability niezależnie które ustawiam nie pomaga.
-
Taki SQL - zamiast zgadywać trzeba sprawdzić, jak coś się dzieje oto trzeba analizować w miejscu występowania problemu... Ustaw wysoką wydajność w opcjach zasilania i zrób test na SQL 2008 R2.
-
Wysoka wydajność była ustawiona.
Wygląda, że sam sprzęt jest znacząco szybszy
1. Nowy Serwer + SQL 2008 R2 działa o 15-20% szybciej
2. Stary Serwer+ SQL 2008 R2 wzorzec
3. Nowy Serwer + SQL 2017 działa o przeszło 70% wolniej
Wnioski takie, że to wina SQLa a nie Maszyny. Testował ktoś podobną sprawę u siebie przy przesiadce?
-
Wygląda, że sam sprzęt jest znacząco szybszy
1. Nowy Serwer + SQL 2008 R2 działa o 15-20% szybciej
To według Ciebie jest "znacząco szybciej" - na jakie czasy w sekundach to się przekłada w praktyce ?
Wnioski takie, że to wina SQLa a nie Maszyny. Testował ktoś podobną sprawę u siebie przy przesiadce?
Trafiony... Ja nie miałem czasu na takie testy i nie musiałem wyjaśniać takich problemów, nie przesadzam nikogo na najnowsze wersje jeśli nie ma takiej potrzeby.
-
Tak, według mnie 15-20% to znacząco szybciej. Abstrahując od tego, przesiadka głównie spowodowana jest podniesieniem bezpieczeństwa danych.
Próbowałem u telekonsultantów Insert, podobno nie znają się na SQLach 8) Szukam dalej. Jak znajdę rozwiązanie to się pochwalę.
-
Tak, według mnie 15-20% to znacząco szybciej. Abstrahując od tego, przesiadka głównie spowodowana jest podniesieniem bezpieczeństwa danych.
W ogóle nie odpowiedziałeś na moje pytanie.
Próbowałem u telekonsultantów Insert, podobno nie znają się na SQLach 8)
To przecież oczywiste, nie rozumiem skąd pomysł, że mogłoby być inaczej.
Szukam dalej. Jak znajdę rozwiązanie to się pochwalę.
Chętnie przeczytam.
-
Tak, według mnie 15-20% to znacząco szybciej. Abstrahując od tego, przesiadka głównie spowodowana jest podniesieniem bezpieczeństwa danych.
W ogóle nie odpowiedziałeś na moje pytanie.
Przy dłuższych zapytaniach dochodzi do 10sec. Nie ma to jednak bezpośredniego związku ze sprawą. Potraktowałem to jako pytanie wtrącone :) Nie chcę udowadniać, że moja nowa konfiguracja jest szybsza. To efekt uboczny ( miły )
Chcąc podnieść bezpieczeństwo danych chciałem przy okazji przejść na nowszą wersję SQLa, niestety tutaj straty czasu są już tak duże. Pozwoliłem sobie tutaj napisać, bo wydaje się to być rzeczą nienaturalną.
-
Tak, według mnie 15-20% to znacząco szybciej. Abstrahując od tego, przesiadka głównie spowodowana jest podniesieniem bezpieczeństwa danych.
W ogóle nie odpowiedziałeś na moje pytanie.
Przy dłuższych zapytaniach dochodzi do 10sec. Nie ma to jednak bezpośredniego związku ze sprawą. Potraktowałem to jako pytanie wtrącone :) Nie chcę udowadniać, że moja nowa konfiguracja jest szybsza. To efekt uboczny ( miły )
Sam poruszyłeś temat, więc się zainteresowałem.
Chcąc podnieść bezpieczeństwo danych chciałem przy okazji przejść na nowszą wersję SQLa, niestety tutaj straty czasu są już tak duże. Pozwoliłem sobie tutaj napisać, bo wydaje się to być rzeczą nienaturalną.
Coraz mnie rozumiem - co ma wspólnego wersja serwera SQL z bezpieczeństwem danych ?
-
Tak, według mnie 15-20% to znacząco szybciej. Abstrahując od tego, przesiadka głównie spowodowana jest podniesieniem bezpieczeństwa danych.
W ogóle nie odpowiedziałeś na moje pytanie.
Przy dłuższych zapytaniach dochodzi do 10sec. Nie ma to jednak bezpośredniego związku ze sprawą. Potraktowałem to jako pytanie wtrącone :) Nie chcę udowadniać, że moja nowa konfiguracja jest szybsza. To efekt uboczny ( miły )
Sam poruszyłeś temat, więc się zainteresowałem.
Chcąc podnieść bezpieczeństwo danych chciałem przy okazji przejść na nowszą wersję SQLa, niestety tutaj straty czasu są już tak duże. Pozwoliłem sobie tutaj napisać, bo wydaje się to być rzeczą nienaturalną.
Coraz mnie rozumiem - co ma wspólnego wersja serwera SQL z bezpieczeństwem danych ?
Niewiele, stąd zwrot "przy okazji". Doskonale obrazuje to przysłowie "upiec dwie pieczenie na jednym ogniu". Skoro i tak już zmieniam serwer, to czemu nie dać nowszego sqla? Ten tok rozumowania wydawał się logiczny, dopóki nie pojawiły się problemy z wydajnością.
SQL 2017 chciałem zainstalować, ponieważ przeczytałem na stronie Insertu że 2005 i 2008 przestanie być wspierany. "30 września 2018 r. zakończymy wsparcie dla współpracy programu InsERT GT z serwerem bazy danych Microsoft SQL Server 2005 i 2008."
-
Skoro i tak już zmieniam serwer, to czemu nie dać nowszego sqla? Ten tok rozumowania wydawał się logiczny, dopóki nie pojawiły się problemy z wydajnością.
A niby dlaczego dać? Co przemawiało za tym, żeby zmienić - tylko cyfra?
SQL 2017 chciałem zainstalować, ponieważ przeczytałem na stronie Insertu że 2005 i 2008 przestanie być wspierany. "30 września 2018 r. zakończymy wsparcie dla współpracy programu InsERT GT z serwerem bazy danych Microsoft SQL Server 2005 i 2008."
Koniec wsparcia dotyczy wersji 2008 - a nie dotyczy wersji 2008 R2
-
Skoro i tak już zmieniam serwer, to czemu nie dać nowszego sqla? Ten tok rozumowania wydawał się logiczny, dopóki nie pojawiły się problemy z wydajnością.
A niby dlaczego dać? Co przemawiało za tym, żeby zmienić - tylko cyfra?
SQL 2017 chciałem zainstalować, ponieważ przeczytałem na stronie Insertu że 2005 i 2008 przestanie być wspierany. "30 września 2018 r. zakończymy wsparcie dla współpracy programu InsERT GT z serwerem bazy danych Microsoft SQL Server 2005 i 2008."
Koniec wsparcia dotyczy wersji 2008 - a nie dotyczy wersji 2008 R2
Historia pokazuje, że kwestią czasu jest, kiedy przestanie być wspierane 2008 R2 ?
Trochę odbiegliśmy od tematu. Przerodził się on w dyskusję nad zasadnością tego ruchu. Prawdą jest, że jak nie wymyślę nic lepszego to zostanę przy 2008 R2. Jednak liczyłem, że może wspólnie dojdziemy do jakichś wniosków, które mogą ułatwić później przejście pozostałym użytkownikom.
-
Historia pokazuje, że kwestią czasu jest, kiedy przestanie być wspierane 2008 R2 ?
Jaka niby "historia" ?
Trochę odbiegliśmy od tematu. Przerodził się on w dyskusję nad zasadnością tego ruchu. Prawdą jest, że jak nie wymyślę nic lepszego to zostanę przy 2008 R2. Jednak liczyłem, że może wspólnie dojdziemy do jakichś wniosków, które mogą ułatwić później przejście pozostałym użytkownikom.
Zdefiniuj "wspólnie".