🚀 go-pugleaf

W dniu 2015-09-01 o 18:09, Robert Winkler pisze:
> Witam
>
> Mam obecnie na swojej maszynie postawionego mysql'a w wersji 5.6.26
> (system operacyjny to 64-bitowa wersja Windows 10 Pro z 8 GB RAMu)
>
> Trafiłem na pewną "niedogodność".
> Otóż załadowanie kopii bazy z serwera produkcyjnego
> mającej zaledwie 7 GB trwa już kilka godzin.
> Wczytywanie dumpa uruchomiłem o 13:30 i trwa to do teraz (do 18:00)
>
> Czy można jakoś skonfigurować tą wersje mysql'a
> aby wczytywanie dumpa pod Windows trwało krócej?
>
> Przyznam się, że przez ostanie lata używałem ms sql'a
> i tam wczytanie takiej małej bazy trwało góra kilka minut,
> na pewno nie kilka godzin.
>
> Procesor obciążony jest na 60-70%
> dysk na poziomie 40%
> jest wiec jakiś zapas aby mogło to działać odrobinę szybciej,
> tylko na co zwrócić uwagę w my.ini

Nie jestem zwolennikiem teorii spiskowych, ale...
odtwarzanie bazy na windows serwer 2012 + postgres 8.4 trwało 
kilkukrotnie dłużej niż na słabszej maszynie linuksowej. U Ciebie 
procesor i dyski coś jednak robią a u mnie serwer strasznie się nudził a 
baza rosła niecały GB na godzinę (a było tych GB 40). Obciążenie rosło 
dopiero jak zaczęło się indeksowanie.

Czyżby Microsoft stosował jakieś sztuczki? A może po prostu trzeba umieć 
nowe technologie Windowsa wykorzystać, bo nowy postgres 9.4 już sobie z 
tym radzi.

Ale zwolennikiem teorii spiskowych nie jestem :)


-- 
pozdrawiam
AS

W dniu 2015-09-01 o 18:09, Robert Winkler pisze:
> Witam
>
> Mam obecnie na swojej maszynie postawionego mysql'a w wersji 5.6.26
> (system operacyjny to 64-bitowa wersja Windows 10 Pro z 8 GB RAMu)
>
> Trafiłem na pewną "niedogodność".
> Otóż załadowanie kopii bazy z serwera produkcyjnego
> mającej zaledwie 7 GB trwa już kilka godzin.
> Wczytywanie dumpa uruchomiłem o 13:30 i trwa to do teraz (do 18:00)
>
> Czy można jakoś skonfigurować tą wersje mysql'a
> aby wczytywanie dumpa pod Windows trwało krócej?
>
> Przyznam się, że przez ostanie lata używałem ms sql'a
> i tam wczytanie takiej małej bazy trwało góra kilka minut,
> na pewno nie kilka godzin.
>
> Procesor obciążony jest na 60-70%
> dysk na poziomie 40%
> jest wiec jakiś zapas aby mogło to działać odrobinę szybciej,
> tylko na co zwrócić uwagę w my.ini
>
Zapewne masz jakiegoś antywirusa - wyłącz katalog mysql'a z kontroli 
antywirusa.

-- 
Pozdrawiam,
Leszek Kubrak

[...]
>> Czy można jakoś skonfigurować tą wersje mysql'a
>> aby wczytywanie dumpa pod Windows trwało krócej?
[...]

>>
> Zapewne masz jakiegoś antywirusa - wyłącz katalog mysql'a z kontroli
> antywirusa.
>

Antywirus, to było pierwsze co sprawdzałem.
Nie tylko wyłączenie, ale nawet kompletne odinstalowanie
niczego nie poprawiło.

--
Robert

W dniu 01.09.2015 o 18:09, Robert Winkler pisze:
> Trafiłem na pewną "niedogodność".
> Otóż załadowanie kopii bazy z serwera produkcyjnego
> mającej zaledwie 7 GB trwa już kilka godzin.
> Wczytywanie dumpa uruchomiłem o 13:30 i trwa to do teraz (do 18:00)

Zmień:

innodb_log_file_size=2047M
innodb_log_files_in_group=2

w my.cnf (tudzież my.ini jeśli to Windows).
Po zatrzymaniu serwisu usuń pliki ib_logfile0 oraz ib_logfile1.
Po restarcie (który za pierwszym razem nieco potrwa) zostaną one 
odtworzone, każdy po 2047M. Odtwarzanie baz z backupów
jak i wszelkie operacje, które z założenia wymagają przebudowania tabel, 
obszerne rollbacki itd.  będą zdecydowanie SZYBSZE.
Wbrew pozorom godna polecenia jest też opcja

innodb_file_per_table

Pozdrawiam

MK

On Tuesday, September 1, 2015 at 6:09:42 PM UTC+2, Robert Winkler wrote:
> [...]
> Robert

Sprawdzałeś, czy plik z wczytywanymi danymi jest optymalny?
Najpierw gołe definicje tabel, potem inserty, potem testy
poprawności, potem indeksy, na końcu więzy integralności

Pozdrawiam

W dniu 23.09.2015 o 12:51, M.M. pisze:
> On Tuesday, September 1, 2015 at 6:09:42 PM UTC+2, Robert Winkler wrote:
>> [...]
>> Robert
>
> Sprawdzałeś, czy plik z wczytywanymi danymi jest optymalny?
> Najpierw gołe definicje tabel, potem inserty, potem testy
> poprawności, potem indeksy, na końcu więzy integralności
>
> Pozdrawiam
>

Jak można wymusić taką strukturę pliku?
(za pomocą standardowych narzędzi dostępnych w mysql-u)

Przyznaje, że zwykle dostaje plik sql wygenerowany przed administratora
hostującego u siebie bazę z której korzystam.
W plikach tych dostaje po kolej, definicje tabeli z kluczem, indeksami
i więzami integralności, później wielowartościowy insert.
I tak tablica po tablicy, struktura, dane, struktura, dane.

--
Robert

On Wednesday, September 23, 2015 at 2:36:47 PM UTC+2, Robert Winkler wrote:
> W dniu 23.09.2015 o 12:51, M.M. pisze:
> > On Tuesday, September 1, 2015 at 6:09:42 PM UTC+2, Robert Winkler wrote:
> >> [...]
> >> Robert
> >
> > Sprawdzałeś, czy plik z wczytywanymi danymi jest optymalny?
> > Najpierw gołe definicje tabel, potem inserty, potem testy
> > poprawności, potem indeksy, na końcu więzy integralności
> >
> > Pozdrawiam
> >
> 
> Jak można wymusić taką strukturę pliku?
> (za pomocą standardowych narzędzi dostępnych w mysql-u)
> 
> Przyznaje, że zwykle dostaje plik sql wygenerowany przed administratora
> hostującego u siebie bazę z której korzystam.
> W plikach tych dostaje po kolej, definicje tabeli z kluczem, indeksami
> i więzami integralności, później wielowartościowy insert.
> I tak tablica po tablicy, struktura, dane, struktura, dane.

Nie pomogę co do narzędzi. Powiem tylko, że w postgresie na jakiejś
bazie dzięki temu zyskałem ogromne przyspieszenie, więc może w mysqlu
na swojej bazie też zyskasz.
Pozdrawiam

On Wed, 23 Sep 2015 14:36:36 +0200, Robert Winkler wrote:

>> Sprawdzałeś, czy plik z wczytywanymi danymi jest optymalny?
>> Najpierw gołe definicje tabel, potem inserty, potem testy
>> poprawności, potem indeksy, na końcu więzy integralności
>>
> 
> Jak można wymusić taką strukturę pliku?
> (za pomocą standardowych narzędzi dostępnych w mysql-u)
> 
> Przyznaje, że zwykle dostaje plik sql wygenerowany przed administratora
> hostującego u siebie bazę z której korzystam.
> W plikach tych dostaje po kolej, definicje tabeli z kluczem, indeksami
> i więzami integralności, później wielowartościowy insert.
> I tak tablica po tablicy, struktura, dane, struktura, dane.

Tak, ale sprawdź to o czym pisał M.M., szczególnie więzy integralności i
indeksy, czy są na końcu, PO DANYCH. Być może przeparsowanie tego pliku i
wygenerowanie nowego dałoby ogromny wzrost wydajności.

-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

W dniu 2015-09-01 o 18:09, Robert Winkler pisze:
> Witam
>
> Mam obecnie na swojej maszynie postawionego mysql'a w wersji 5.6.26
> (system operacyjny to 64-bitowa wersja Windows 10 Pro z 8 GB RAMu)
>
> Trafiłem na pewną "niedogodność".
> Otóż załadowanie kopii bazy z serwera produkcyjnego
> mającej zaledwie 7 GB trwa już kilka godzin.
> Wczytywanie dumpa uruchomiłem o 13:30 i trwa to do teraz (do 18:00)
>
> Czy można jakoś skonfigurować tą wersje mysql'a
> aby wczytywanie dumpa pod Windows trwało krócej?
>
> Przyznam się, że przez ostanie lata używałem ms sql'a
> i tam wczytanie takiej małej bazy trwało góra kilka minut,
> na pewno nie kilka godzin.
>
> Procesor obciążony jest na 60-70%
> dysk na poziomie 40%
> jest wiec jakiś zapas aby mogło to działać odrobinę szybciej,
> tylko na co zwrócić uwagę w my.ini
>
Odpowiedzi poniżej przeczytałem. I jest tu mowa o indeksach i więzach 
integralności. Z bazą z jaką pracowałem robiło się to prosto.
Wyłączało wszystko co było związane z indeksami i integralnością (potem 
dopiero uruchamiało indeksację. Integralność musiała być zachowana w samym 
dumpie. Nie wiem czy mysql daje taką możliwość.
Zysk (czasowy) był olbrzymi, nie działały mechanizmy sprawdzające dla 
każdego rekordu.
Z drugiej strony nie widzę możliwości ładowania czegokolwiek co struktury 
nie posiada (dlatego piszę o wyłączeniu mechanizmu bazy - warunek trzeba być 
pewnym danych!).
Dlaczego tak? W wyniku działania trigerów, dane zostały już 
(ustawione/skorygowane) - nie ma sensu poddawać ich ponownej weryfikacji 
(chyba, że celowo).

Ale nie sprawdzałem czy mysql ma taką możliwość.

-- 
Artur

W dniu 2015-09-23 o 12:51, M.M. pisze:
> On Tuesday, September 1, 2015 at 6:09:42 PM UTC+2, Robert Winkler wrote:
>> [...]
>> Robert
>
> Sprawdzałeś, czy plik z wczytywanymi danymi jest optymalny?
> Najpierw gołe definicje tabel, potem inserty, potem testy
> poprawności, potem indeksy, na końcu więzy integralności
>
A jak sobie wyobrażasz ładowanie danych do tabeli, której nie ma?
(I co to są te testy poprawności?)
Piszesz o czymś podobnym co ja - ale w innym rozumieniu i ...

Narzędzia jakie znam (innych nie znam) robią wszystko wg kolejności.
No chyba, że są jakieś, które robią (próbują) od dupy strony.


-- 
Artur

On Wednesday, September 23, 2015 at 7:38:08 PM UTC+2, artiun wrote:
> W dniu 2015-09-23 o 12:51, M.M. pisze:
> > On Tuesday, September 1, 2015 at 6:09:42 PM UTC+2, Robert Winkler wrote:
> >> [...]
> >> Robert
> >
> > Sprawdzałeś, czy plik z wczytywanymi danymi jest optymalny?
> > Najpierw gołe definicje tabel, potem inserty, potem testy
> > poprawności, potem indeksy, na końcu więzy integralności
> >
> A jak sobie wyobrażasz ładowanie danych do tabeli, której nie ma?
Np. zapisujesz dane na dysku a potem hakujesz definicję tabel w
silniku bazy danych, ale Ty jedyny na świecie chcesz tak robić.


> (I co to są te testy poprawności?)
To są testy które sprawdzają poprawność.


> Piszesz o czymś podobnym co ja - ale w innym rozumieniu i ...
Po prostu jesteś inny.


> Narzędzia jakie znam (innych nie znam) robią wszystko wg kolejności.
> No chyba, że są jakieś, które robią (próbują) od dupy strony.
Czytać ze zrozumieniem, dostał dane od admina.

W dniu 01.09.2015 o 18:09, Robert Winkler pisze:
> Witam
>
[...]
>

Kilka osób pisało o tym aby wyłączyć więzy integralności
oraz constrainty, więc odpisze tutaj, zamiast każdemu z osobna.

Sprawdziłem właśnie ostatni plik dumpa jaki dostałem
i jest tam na samym początku SET blokujący constrainy i klucze obce,
a przed każdą serią insertów komenda blokująca klucze dla danej tabeli.
Nie widzę więc możliwości aby w ten sposób coś przyspieszyć.

Wygląda na to, że dla mysql'a
jedynym szybkim sposobem na wykonanie kopii bazy
i wciągnięcie jej na inną maszynę
jest przesłanie binarnej kopie całego folderu z danymi.
Nie zawsze można jednak z tego sposobu skorzystać :(

--
Robert

On Thursday, September 24, 2015 at 8:38:29 AM UTC+2, Robert Winkler wrote:
> W dniu 01.09.2015 o 18:09, Robert Winkler pisze:
> > Witam
> >
> [...]
> >
> 
> Kilka osób pisało o tym aby wyłączyć więzy integralności
> oraz constrainty, więc odpisze tutaj, zamiast każdemu z osobna.
> 
> Sprawdziłem właśnie ostatni plik dumpa jaki dostałem
> i jest tam na samym początku SET blokujący constrainy i klucze obce,
> a przed każdą serią insertów komenda blokująca klucze dla danej tabeli.
> Nie widzę więc możliwości aby w ten sposób coś przyspieszyć.
> 
> Wygląda na to, że dla mysql'a
> jedynym szybkim sposobem na wykonanie kopii bazy
> i wciągnięcie jej na inną maszynę
> jest przesłanie binarnej kopie całego folderu z danymi.
> Nie zawsze można jednak z tego sposobu skorzystać :(

Jaka duża jest baza?

W dniu 24.09.2015 o 11:19, M.M. pisze:
> On Thursday, September 24, 2015 at 8:38:29 AM UTC+2, Robert Winkler wrote:
>> W dniu 01.09.2015 o 18:09, Robert Winkler pisze:
>>> Witam
>>>
>> [...]
>>>
>>
>> Kilka osób pisało o tym aby wyłączyć więzy integralności
>> oraz constrainty, więc odpisze tutaj, zamiast każdemu z osobna.
>>
>> Sprawdziłem właśnie ostatni plik dumpa jaki dostałem
>> i jest tam na samym początku SET blokujący constrainy i klucze obce,
>> a przed każdą serią insertów komenda blokująca klucze dla danej tabeli.
>> Nie widzę więc możliwości aby w ten sposób coś przyspieszyć.
>>
>> Wygląda na to, że dla mysql'a
>> jedynym szybkim sposobem na wykonanie kopii bazy
>> i wciągnięcie jej na inną maszynę
>> jest przesłanie binarnej kopie całego folderu z danymi.
>> Nie zawsze można jednak z tego sposobu skorzystać :(
>
> Jaka duża jest baza?
>

Plik dumpa ma 2.9 GB
Po wciągnięciu na serwer robi się z tego 7 GB w katalogu z tym schematem.

--
Robert

On Thursday, September 24, 2015 at 12:40:37 PM UTC+2, Robert Winkler wrote:
> W dniu 24.09.2015 o 11:19, M.M. pisze:
> > On Thursday, September 24, 2015 at 8:38:29 AM UTC+2, Robert Winkler wrote:
> >> W dniu 01.09.2015 o 18:09, Robert Winkler pisze:
> >>> Witam
> >>>
> >> [...]
> >>>
> >>
> >> Kilka osób pisało o tym aby wyłączyć więzy integralności
> >> oraz constrainty, więc odpisze tutaj, zamiast każdemu z osobna.
> >>
> >> Sprawdziłem właśnie ostatni plik dumpa jaki dostałem
> >> i jest tam na samym początku SET blokujący constrainy i klucze obce,
> >> a przed każdą serią insertów komenda blokująca klucze dla danej tabeli.
> >> Nie widzę więc możliwości aby w ten sposób coś przyspieszyć.
> >>
> >> Wygląda na to, że dla mysql'a
> >> jedynym szybkim sposobem na wykonanie kopii bazy
> >> i wciągnięcie jej na inną maszynę
> >> jest przesłanie binarnej kopie całego folderu z danymi.
> >> Nie zawsze można jednak z tego sposobu skorzystać :(
> >
> > Jaka duża jest baza?
> >
> 
> Plik dumpa ma 2.9 GB
> Po wciągnięciu na serwer robi się z tego 7 GB w katalogu z tym schematem.
To wystarczy aby zajeździć dysk, jeśli po każdym zapisanym rekordzie robi
się update i flush czegoś (np. indeksów) w losowym miejscu na dysku.

>>>>> Witam
>>>>>
>>>> [...]
>>>>>
>>>>
>>>> Kilka osób pisało o tym aby wyłączyć więzy integralności
>>>> oraz constrainty, więc odpisze tutaj, zamiast każdemu z osobna.
>>>>
>>>> Sprawdziłem właśnie ostatni plik dumpa jaki dostałem
>>>> i jest tam na samym początku SET blokujący constrainy i klucze obce,
>>>> a przed każdą serią insertów komenda blokująca klucze dla danej tabeli.
>>>> Nie widzę więc możliwości aby w ten sposób coś przyspieszyć.
>>>>
>>>> Wygląda na to, że dla mysql'a
>>>> jedynym szybkim sposobem na wykonanie kopii bazy
>>>> i wciągnięcie jej na inną maszynę
>>>> jest przesłanie binarnej kopie całego folderu z danymi.
>>>> Nie zawsze można jednak z tego sposobu skorzystać :(
>>>
>>> Jaka duża jest baza?
>>>
>>
>> Plik dumpa ma 2.9 GB
>> Po wciągnięciu na serwer robi się z tego 7 GB w katalogu z tym schematem.
 >
> To wystarczy aby zajeździć dysk, jeśli po każdym zapisanym rekordzie robi
> się update i flush czegoś (np. indeksów) w losowym miejscu na dysku.

Czego dotyczy ta uwaga?
Wielkości bazy?
Tego, że używamy mysql'a, a nie jakiegoś innego silnika bazodanowego?

Jak dla mnie w porównaniu z bazami jakie mieliśmy w poprzednim 
projekcie, to te 7 GB to maleństwo.

--
Robert

On Thursday, September 24, 2015 at 1:19:37 PM UTC+2, Robert Winkler wrote:
> >>>>> Witam
> >>>>>
> >>>> [...]
> >>>>>
> >>>>
> >>>> Kilka osób pisało o tym aby wyłączyć więzy integralności
> >>>> oraz constrainty, więc odpisze tutaj, zamiast każdemu z osobna.
> >>>>
> >>>> Sprawdziłem właśnie ostatni plik dumpa jaki dostałem
> >>>> i jest tam na samym początku SET blokujący constrainy i klucze obce,
> >>>> a przed każdą serią insertów komenda blokująca klucze dla danej tabeli.
> >>>> Nie widzę więc możliwości aby w ten sposób coś przyspieszyć.
> >>>>
> >>>> Wygląda na to, że dla mysql'a
> >>>> jedynym szybkim sposobem na wykonanie kopii bazy
> >>>> i wciągnięcie jej na inną maszynę
> >>>> jest przesłanie binarnej kopie całego folderu z danymi.
> >>>> Nie zawsze można jednak z tego sposobu skorzystać :(
> >>>
> >>> Jaka duża jest baza?
> >>>
> >>
> >> Plik dumpa ma 2.9 GB
> >> Po wciągnięciu na serwer robi się z tego 7 GB w katalogu z tym schematem.
>  >
> > To wystarczy aby zajeździć dysk, jeśli po każdym zapisanym rekordzie robi
> > się update i flush czegoś (np. indeksów) w losowym miejscu na dysku.
> 
> Czego dotyczy ta uwaga?
> Wielkości bazy?
> Tego, że używamy mysql'a, a nie jakiegoś innego silnika bazodanowego?
> 
> Jak dla mnie w porównaniu z bazami jakie mieliśmy w poprzednim 
> projekcie, to te 7 GB to maleństwo.
> 
> --
> Robert

Baza ma 7GB danych. Rekord niech ma średnio 1000bajtów. Daje to 7*10^6 =
7mln rekordów. Na sekundę dysk umożliwia np. 100 dostępów. Przy
jednym dostępie na jeden rekord wychodzi 7mln / 100 = 70tys sekund -
jakieś 20 godzin. Taka ilość danych w zupełności wystarczy, aby 
zajeździć dysk.