Forum Użytkownikow Subiekt GT
InsERT GT => Rachmistrz GT => Wątek zaczęty przez: pas_ w Styczeń 02, 2016, 01:04:54
-
Cześć
Mam taki problem. Przeprowadzam konwersje baz inserta po aktualizacji i z pewną dozą niepokoju obserwuje jak przerażająco długo to trwa.
Kiedyś miałem 80 baz i wystarczyła nie cała nocka. Dziś przy 120 bazach trwa to prawie 2 dni. Konwersje przeprowadzałem zawsze za pomocą biura GT, bazy są na MS SQL express 2008 r2, system to win 2008 r2 std.
Można coś z tym zrobić, żeby to trwało krócej? Dodam że po analizie zasobów serwera, w trakcie konwersji wnoszę że serwer czeka .... aż ta pierdoła B-GT da mu coś do roboty ;)
-
Na początek przenieś bazy na macierz SSD.
-
SSD zawsze lepsze. Z tym ze ja mam te 90 IOPS i kolejke do DS,w trakcie konwersji max 5...
-
To teraz uruchom kilka konwersji równolegle.
ps.
Podaj dokładną konfigurację serwera.
-
Tak odpalam dwie równolegle. Co prawda poprzez sieć ale zawsze skraca to czas.
Może da rade takie zachowanie wymusić lokalnie? Albo konfiguracja klienta BiuroGT? Mam taką samą jak na końcówkach.
SW
sys: windows 2008 r2 std 64bit
sql: MS SQL 2008 expres
HW
CPU Xeon e5620 2,4ghz
ram: 16GB (4x4gb)
ds: intel embedded RAID II, 4 x 1tb w RAID5
Mobo: S5500BC
-
Tak odpalam dwie równolegle.
To uruchom więcej konwersji, aż serwer będzie miał co robić.
Co prawda poprzez sieć ale zawsze skraca to czas.
To podstawowy i duży błąd, przecież sieć spowalnia wszystkie operacje.
Może da rade takie zachowanie wymusić lokalnie? Albo konfiguracja klienta BiuroGT? Mam taką samą jak na końcówkach.
Pisałem o równoległej konwersji podmiotów, a nie o równoległym uruchamianiu Biura GT. Czy da się wykorzystać Biuro GT lub inaczej podejść doproblemu - zapewne tak, ale nie miałem potrzeby szukać rozwiązania.
SW
sys: windows 2008 r2 std 64bit
sql: MS SQL 2008 expres
HW
CPU Xeon e5620 2,4ghz
ram: 16GB (4x4gb)
ds: intel embedded RAID II, 4 x 1tb w RAID5
Mobo: S5500BC
Serwer kompletnie bez sensu - wolny i nie najnowszy procesor, dużo niewykorzystanego RAM'u, gdzie dyski SSD o których wcześniej pisałeś ?
-
ale ja nie pisałem że mam dyski SSD :)
Pisałem o równoległej konwersji podmiotów, a nie o równoległym uruchamianiu Biura GT. Czy da się wykorzystać Biuro GT lub inaczej podejść doproblemu - zapewne tak, ale nie miałem potrzeby szukać rozwiązania.
Ok. a powiedz mi proszę jak skonfigurować równoległą konwersję? Żadnych magicznych pstryczków w BiuroGT ani w Programie serwisowym nie widać.
-
Załóż kilka podmiotów Biura na potrzeby konwersji.
-
Załóż kilka podmiotów Biura na potrzeby konwersji.
A robiąc to programem serwisowym możesz odpalić kilka/naście sesji tego programu.
-
ale ja nie pisałem że mam dyski SSD :)
Nie zrozumiałem Twojej odpowiedzi, więc wracamy do "podstaw"...
SSD zawsze lepsze.
Nie zawsze, przy pracy z jedną bazą danych nie robię znaczącej różnicy, jedynie w Biurach rachunkowych przy pracy z wieloma bazami danych mogą zrobić znaczącą różnicę.
Z tym ze ja mam te 90 IOPS
Jeśli nie pomyliłeś jednostek to masz podsystem dyskowy około 1000 (tysiąc) razy wolniejszy od jednego dysku SSD
...i kolejke do DS,w trakcie konwersji max 5...
Uruchom 4-8 konwersji równolegle i sprawdź wtedy.
-
U mnie 30 sek-150 sek na jedną bazę ( liczę z kopia zapasową ) , przy 100 bazach trochę to trwa i zależy tez od konkretnej aktualizacji, HW i3 3250 3,50 Ghz, 8 GB , SSD Crucial MX100 256 GB, płyta najtańsza B75 ( konwersję przeprowadzam na serwerze nie po sieci) . Proc obciążony na 25 % więc wąskim gardłem jest SSD :) albo RAM ( no i Insert bo nie ma softu zoptymalizowanego pod wiele rdzeni)
-
U mnie 30 sek-150 sek na jedną bazę ( liczę z kopia zapasową )
U mnie to trwa 5 minut na bazę, a mam wrażenie że wcześniej w tych 3 minutach się mieścił ale też procesor bardziej intensywnie chodził.
Biorąc pod uwagę że ten SSD Crucial MX100 256 GB
to efektywnie 13k - 20k IOPS w zapisie, plus do tego 1GHz więcej na twoim i3... to spadek czasu wykonywania operacji jest khm politycznie mówiąc oczekiwałbym spadku liniowego i jeszcze lepszego wyniku.
Jeśli szukasz dziury ;) to u Ciebie akurat widać* że dodatkowe gigaherce na procesorze jeszcze by pomogły. Na wykorzystanie pozostałych 3 rdzeni w tym insyfcie nie ma co liczyć. Nie jest to program zoptymalizowany - typowy biznesowy przypadek.
* to trochę strzał z doświadczenia i wiedzy, poziom pewności 99%. Tak na prawdę trzeba by sprawdzić wysycenie twojego sdd.
-
W wątku porównujecie cas konwersji, a nie podaliście z jakiej do jakiej wersji. Takie porównywanie wyników jest bez sensu, bo np. u mnie konwersja jednej bazy trwa 1 sekundę (z 1.42 do 1.42HF1) :)
-
Na wykorzystanie pozostałych 3 rdzeni w tym insyfcie nie ma co liczyć. Nie jest to program zoptymalizowany - typowy biznesowy przypadek.
Przede wszystkim procesory i3 nie posiadają 4 rdzeni. Na możliwość uruchamiania równoległych konwersji przez Biuro można liczyć, program jest cały czas rozwijany, ale napisaliśmy jak wykorzystać wiele rdzeni już teraz, wystarczy skorzystać. Skro problemy z wydajnością występują również w "wasyfcie" czy "cosyfcie" to warto o tym wspomnieć, zamiast krytykować tylko Insert.
-
Dzisiaj analizowałem co się dzieje przy konwersji.. ogólnie idzie masę skryptów które trwają w przedziale 1-100 ms.
Najdłuższe zapytania które lecą to backup i restore bazy.
-
Przeanalizuj raz jeszcze, dokładnie ;)
-
Dzisiaj analizowałem co się dzieje przy konwersji.. ogólnie idzie masę skryptów które trwają w przedziale 1-100 ms.
Najdłuższe zapytania które lecą to backup i restore bazy.
a mi najbardziej zamula w momencie aktualizacji wzorców wydruku ,ciekawe dlaczego?
-
Dzisiaj analizowałem co się dzieje przy konwersji.. ogólnie idzie masę skryptów które trwają w przedziale 1-100 ms.
Najdłuższe zapytania które lecą to backup i restore bazy.
a mi najbardziej zamula w momencie aktualizacji wzorców wydruku
Dokładnie, na dobrym sprzęcie ten krok potrafi trwać minutę :(
ciekawe dlaczego?
Jest skopany algorytm konwersji, są aktualizowane wszystkie wzorce, a nie tylko te, które się zmieniły.
-
trzeba by to zgłosić do Inserta, konwersja mogłaby być krótsza prawie o połowę
-
trzeba by to zgłosić do Inserta,
Oczywiście, czym więcej zgłoszeń tym lepiej.
-
ta, to trwa najdłużej - wzorce. Backup baz jest pomijalny.
Gdzie to im zgłaszacie na infolinie? Mi ostatnim razem ręka odmówiła posłuszeństwa ;)
-
główne menu->Pomoc->Zgłoś sugestię Ctrl+F12
-
no akurat dzisiaj przyszła aktualizacja z 1.42hf1 na 1.42SP1 mi konwersja przez biuro gt na serwerze zajmuje średnio 83-90 sek w zależności od bazy, a wam jak to szybko idzie? ( oczywiście nadal zamula na 40 sek. przy wydrukach)
szczególnie interesuje mnie prędkość na serwerze z 4 rdzeniami (i5) bo sam mam tylko i3 i jestem ciekaw czy dodatkowe dwa jaja dużo dają?
-
no akurat dzisiaj przyszła aktualizacja z 1.42hf1 na 1.42SP1 mi konwersja przez biuro gt na serwerze zajmuje średnio 83-90 sek w zależności od bazy, a wam jak to szybko idzie? ( oczywiście nadal zamula na 40 sek. przy wydrukach)
szczególnie interesuje mnie prędkość na serwerze z 4 rdzeniami (i5) bo sam mam tylko i3 i jestem ciekaw czy dodatkowe dwa jaja dużo dają?
Nic nie dają.
-
Załóż kilka podmiotów Biura na potrzeby konwersji.
A robiąc to programem serwisowym możesz odpalić kilka/naście sesji tego programu.
wystarczy przytrzymać CTRL przy klikaniu w ikonę Biuro GT
Odpaliłem Biuro GT x2 i zaznaczyłem po kilka podmiotów do konwersji, w każdym GT inne oczywiście, procesor wreszcie jest obciążony tak jak powinien ( 83%) , wygląda na to że optymalnie powinno się otwierać 3 sesje dla i3 , a dla i5 5-6 sesji :) ale trzeba uważać z zaznaczaniem podmiotów ,bo jak równocześnie zaczną robić konwersje tej samej bazy może być tragedia zapewne . Czyli jednak można 3 razy szybciej :)
-
ale trzeba uważać z zaznaczaniem podmiotów ,bo jak równocześnie zaczną robić konwersje tej samej bazy może być tragedia zapewne.
Czyli nie sprawdziłeś ;) Tragedii być nie powinno, gdyż podmiot jest blokowany na wyłączność. Można też sobie podzielić podmioty grupami/cechami...
Czyli jednak można 3 razy szybciej :)
Kto co lubi, a niektórzy lubią spędzać przy konwersji nawet weekend z obawami, że nie zdążą do poniedziałku... ;) A można jeszcze szybciej niż 3x... ;)
-
Ja kiedyś sprawdzałem i w razie trafienie przez BGT na podmiot w trakcie kiedy konwersji Biuro wywalało błąd i koniec pracy. Nie przechodziło do kolejnej bazy.
-
Czyli nie sprawdziłeś ;) Tragedii być nie powinno, gdyż podmiot jest blokowany na wyłączność. Można też sobie podzielić podmioty grupami/cechami...
z tym podziałem grupami dobry pomysł ale u mnie coś nie działa kiedy daję filtr na grupach w oknie wyboru nic się nie dzieje w biurze gt dalej widać wszystkie, tez tak masz?
-
Czyli nie sprawdziłeś ;) Tragedii być nie powinno, gdyż podmiot jest blokowany na wyłączność. Można też sobie podzielić podmioty grupami/cechami...
z tym podziałem grupami dobry pomysł ale u mnie coś nie działa kiedy daję filtr na grupach w oknie wyboru nic się nie dzieje w biurze gt dalej widać wszystkie, tez tak masz?
U mnie wszystko działa. Sprawdzam na wersji 1.15.
-
Witam, mam również identyczny problem z długim czasem konwersji bazy.
Proszę o informację jak można uruchomić konwersję równoległą ?
pozdrawiam
-
Witam, mam również identyczny problem z długim czasem konwersji bazy.
Proszę o informację jak można uruchomić konwersję równoległą ?
pozdrawiam
Jeśli robisz to przez program serwisowym, to odpalasz go kilka razy i w każdym wskazujesz inna bazę do konewrsji.
-
Witam, mam również identyczny problem z długim czasem konwersji bazy.
Proszę o informację jak można uruchomić konwersję równoległą ?
pozdrawiam
Chodzi o długi czas konwersji pojedynczej bazy czy długi czas konwersji wielu baz?
Jaki sprzęt?
-
chodzi o dlugi czas konwersji bazy . konwersja jednej bazy trwa ok 10 minut
jest ich 400
konwertowanie programem Biuro GT
parametry serwera
Xeon E1
Ram 16GB
Dysk 1000GB RAID
-
chodzi o dlugi czas konwersji bazy . konwersja jednej bazy trwa ok 10 minut
Wygląda po prostu na bardzo słaby sprzęt, a przynajmniej do pracy z programami Insertu i tyloma bazami SQL, zalecenia wielokrotnie były opisywane na forum. Ale tak dokładniej...
Xeon E1
Jaki model ?
Ram 16GB
Jaka edycja SQL'a, ile instancji ?
Dysk 1000GB RAID
HDD, SSD, ile dysków jakie poziomy RAID ?
-
chodzi o dlugi czas konwersji bazy . konwersja jednej bazy trwa ok 10 minut
Wygląda po prostu na bardzo słaby sprzęt, a przynajmniej do pracy z programami Insertu i tyloma bazami SQL, zalecenia wielokrotnie były opisywane na forum. Ale tak dokładniej...
Xeon E1
Jaki model ?
E3-1220
4 Rdzenie po 3,4GHz
Jaka edycja SQL'a, ile instancji ?
SQL 2008
Dysk 1000GB RAID
HDD, SSD, ile dysków jakie poziomy RAID ?
2x dysk HDD RAID1 1TB
W czasie aktualizacji obciążenie procesora do 8% MAX
Obiciążenie dysków podczas aktualizacji odczyt 20MB
-
Procesor ma dokładnie 4x3.1, a dopiero w Tubo osiąga 3.4, ale ogólnie jest w porządku. Nie wiem po co tyle niewykorzystywanego RAM'u ? Nie odpowiedziałeś na pytanie o serwer SQL ? Dyski wyglądają na zdecydowanie za wolne, nie zamieściłeś też informacji czy włączony jest cache, zrób i zamieść wynik testu z ATTO... Dyski mogą ograniczać wykorzystanie procesora (jak procesor czekana dysk to nic nie robi). Niezalenie od tego należy skorzystać z porad, które regularnie zamieszczany i wykonywać konwersję równolegle na kilku podmiotach do pełnego wykorzystania sprzętu.
-
Procesor ma dokładnie 4x3.1, a dopiero w Tubo osiąga 3.4, ale ogólnie jest w porządku. Nie wiem po co tyle niewykorzystywanego RAM'u ? Nie odpowiedziałeś na pytanie o serwer SQL ? Dyski wyglądają na zdecydowanie za wolne, nie zamieściłeś też informacji czy włączony jest cache, zrób i zamieść wynik testu z ATTO... Dyski mogą ograniczać wykorzystanie procesora (jak procesor czekana dysk to nic nie robi). Niezalenie od tego należy skorzystać z porad, które regularnie zamieszczany i wykonywać konwersję równolegle na kilku podmiotach do pełnego wykorzystania sprzętu.
Dyski nie są za wolne gdyż ich wykorzystanie podczas konwersji jest 20MB a podczas testów programem np HD Tune odczyt z pełną prędkością wynosi ok 200MB wykorzystywanie dysku podczas konwersji 10%. Więc proces nie jest ograniczany przez procesor, dysk, ani ram.
Konwersja w chwili obecnej trwa ok 4 dni. Posiadam ok 400 podmiotów ( włączenie w piątek po 15. koniec konwersji poniedziałek ok 12)
Jak dla mnie tragedia. Posiadam BiuroGT jak w tym programie uruchomić kilka konwersji na raz ?
dziękuję i pozdrawiam
-
Dyski nie są za wolne gdyż ich wykorzystanie podczas konwersji jest 20MB a podczas testów programem np HD Tune odczyt z pełną prędkością wynosi ok 200MB wykorzystywanie dysku podczas konwersji 10%. Więc proces nie jest ograniczany przez procesor, dysk, ani ram.
No cóż, opieram się na informacjach jakie podajesz, dobrze i za darmo radzę, ale skoro wiesz lepiej (być może tak jest bo masz dostęp do sprzętu) to szukaj rozwiązania dalej.
Konwersja w chwili obecnej trwa ok 4 dni. Posiadam ok 400 podmiotów ( włączenie w piątek po 15. koniec konwersji poniedziałek ok 12)
Jak dla mnie tragedia. Posiadam BiuroGT jak w tym programie uruchomić kilka konwersji na raz ?
To zależy tylko i wyłącznie od wybranych rozwiązań, czas ten powinno udać się skrócić do kilku, kilkunastu godzin.
Posiadam BiuroGT jak w tym programie uruchomić kilka konwersji na raz ?
No wystarczy kilka razy uruchomić program.
-
A tak konkretniej o tym serwerze SQL?
Na pewno to 2008, a nie 2008R2 przypadkiem?
A jeśli nawet to jaka edycja?
Znam 6 podstawowych od Express do Datacenter i śmiem twierdzić że nie jest to całkiem wszystko jedno.
-
...
Dyski nie są za wolne gdyż ich wykorzystanie podczas konwersji jest 20MB a podczas testów programem np HD Tune odczyt z pełną prędkością wynosi ok 200MB wykorzystywanie dysku podczas konwersji 10%. Więc proces nie jest ograniczany przez procesor, dysk, ani ram. ...
Proszę zwrócić uwagę, że HD Tune sprawdza prędkość maksymalną dysku, przy ciągłym odczycie dużego pliku. Taki test to może być adekwatny do kopiowania baz z dysku na dysk, a nie podczas dokonywania konwersji.
Proszę sprawdzić wydajność dysku w ATTO Disc Benchmark lub CrystalDiscMark, wyciągnąć średnią dla paczki między 4, a 32KB, to będzie odpowiadało bardziej rzeczywistości.
-
Wszyscy się skupiają na sprzęcie, ale niestety od bazy to też zależy. Na tym samym sprzęcie mam różne podmioty i jednych konwersja trwa minutę a innych 26 minut i ostatnio to już chciałem zabijać proces, bo myślałem, że się zawiesiło (InsERT GT w najdłuższym i najwolniejszym etapie konwersji nie sygnalizuje w żaden sposób postępu procesu, który wygląda jakby się zawiesił...). I chyba nie zależy to nawet tak bardzo od wielkości baz tych podmiotów, bo nie są jakieś specjalnie duże, co od wielkości logów tych baz - te najgorsze to mają nawet 18GB logi do bazy... :(
-
Wszyscy się skupiają na sprzęcie, ale niestety od bazy to też zależy. Na tym samym sprzęcie mam różne podmioty i jednych konwersja trwa minutę a innych 26 minut i ostatnio to już chciałem zabijać proces, bo myślałem, że się zawiesiło (InsERT GT w najdłuższym i najwolniejszym etapie konwersji nie sygnalizuje w żaden sposób postępu procesu, który wygląda jakby się zawiesił...). I chyba nie zależy to nawet tak bardzo od wielkości baz tych podmiotów, bo nie są jakieś specjalnie duże, co od wielkości logów tych baz - te najgorsze to mają nawet 18GB logi do bazy... :(
Piszą o logach masz na mysli pliki .ldf z bazy?
Jesli tak, to bardzo ciekawe odkrycie, bo domyslnie wielkość pliku .ldf jest ustawiona na 10% bazy.
Chyba, ze chodzi Ci o inne logi, ale zazwyczaj one nie biorą udziału w konwersji, są tylko zapisem raportu o przebiegu konwersji.
-
Jesli tak, to bardzo ciekawe odkrycie, bo domyslnie wielkość pliku .ldf jest ustawiona na 10% bazy.
Domyślnie do czego? Przecież wielkość tego logu zależy od modelu recovery i częstotliwości backupu logu. Przy full i bez backupu logu (domyślne ustawienie na płatnych wersjach MS SQL) log będzie rósł aż braknie miejsca na dysku.
-
Jesli tak, to bardzo ciekawe odkrycie, bo domyslnie wielkość pliku .ldf jest ustawiona na 10% bazy.
Domyślnie do czego? Przecież wielkość tego logu zależy od modelu recovery i częstotliwości backupu logu. Przy full i bez backupu logu (domyślne ustawienie na płatnych wersjach MS SQL) log będzie rósł aż braknie miejsca na dysku.
Tacy użytkownicy raczej nie pojawiają się na tym forum.
A jeśli jesteś taki, to co tu robisz w gronie maluczkich? ;)
-
Wszyscy się skupiają na sprzęcie, ale niestety od bazy to też zależy. Na tym samym sprzęcie mam różne podmioty i jednych konwersja trwa minutę a innych 26 minut i ostatnio to już chciałem zabijać proces, bo myślałem, że się zawiesiło (InsERT GT w najdłuższym i najwolniejszym etapie konwersji nie sygnalizuje w żaden sposób postępu procesu, który wygląda jakby się zawiesił...). I chyba nie zależy to nawet tak bardzo od wielkości baz tych podmiotów, bo nie są jakieś specjalnie duże, co od wielkości logów tych baz - te najgorsze to mają nawet 18GB logi do bazy... :(
Kto ustawia i po co taki recovery model ? Jak ktoś ustawia to dlaczego nimi nie zarządza i doprowadza do takiego rozrostu ?
Nie widzę potrzeby stosowania pełnych serwerów SQL dla programów Insertu, ale niektórzy wolą wydać kilka tys. na SQL'a zamiast kilkaset zł na usługi dobrego serwisanta - każdy "oszczędza" jak uważa. Na powszechnie stosowanych darmowych silnikach nie ma problemu z logami, więc w żaden sposób nie wpływają na czas konwersji i pozostaje "tylko" sprzęt oraz właściwa strategia.
Ponadto zamiast "zgadywać" i opisywać swoje domysły należałby po prostu sprawdzić z czego wynikają takie różnice w czasie konwersji.