Skocz do zawartości

Zbiorowa konwersja baz do najnowszej wersji (aktualizacja podmiotów)

Polecane posty

Podczas konwersji baz program wymaga gigantycznych ilości przestrzeni na dysku serwera. Zanim zainstalowaliśmy pakiet nexo, na naszym serwerze wolne było ponad 120GB a obecnie został nam 1GB. Połowa klientów nadal nie ma najnowszej wersji, gdyż zbiorowo jest to już niewykonalne a ręczne aktualizowanie znacznej ilości klientów będzie pracą bez końca, gdyż zanim skończę wyjdzie kolejna aktualizacja :) Program "puchnie" w niebywałym tempie, gdyż ten decyduje za mnie o archiwizacji danych przed konwersją i nie daje mi opcji wyboru aby nie zrobić archiwum lub zrobić tymczasowe, które następnie sam usunie. Co ciekawe, jeżeli ten proces (konwersji) zostanie przerwany z powodu braku miejsca, przestrzeń nie zostanie oczyszczona lecz znika w zastraszajacym tempie. Jeżeli używam mechanizmu archiwizacji (przed konwersją) silnika bazy SQL, to sprawia, że do dziś szukam gdzie się podziało 100GB. Próba usunięcia plików "deployments" wywołuje jeszcze dziwniejsze zjawisko. Na moich oczach bowiem pliki są usuwane (opcja usuń PERMANENTNIE) ale przestrzeń się nie zwalnia. Kolejna zagadka to fakt, że archiwum wykonane w programie serwisowym wszystkich firm zajmuje 7,5GB a próba konwersji zaledwie 25% firm zakończona zostaje z powodu braku miejsca po "zjedzeniu" aż... 15GB. Czy potraficie mi wyjaśnić i doradzić jak spuścić powietrze z tego nadmuchanego balona? :/

Edytowane przez Artur Mechliński
Link to postu

W sumie, to jest chyba problem ogólny, więc warto abyście w Insert zwrócili na to uwagę. Za pewne dla celów optymalizacyjnych, trzymacie na dysku komputera klienta, wszystkie wersje bibliotek programu. W naszym przypadku, od wersji 12, uzbierało się już kilka katalogów, a każdy z nich ma 700MB. To samo pewnie nastąpiło u Pana Artura. Może warto by w procesie aktualizacji, dodać domyślnie zaznaczony checkbox z opcją "Usuń biblioteki poprzednich wersji programu". Wtedy, Ci mniej wprawni użytkownicy, mogli by nad tym jakoś panować, a jakby ktoś chciał użyć starszej wersji, to i tak pobierze się ona z bazy danych, bo tam też ją trzymacie. Na moim komputerze, gdzie korzystam z 3 podmiotów, folder Deployments ma 24GB :( Co się musi dziać w przypadku Pana Artura, jeśli ma wiele podmiotów, to masakra jakaś.

Link to postu
2 godziny temu, Radomił Ząbik napisał:

Na moim komputerze, gdzie korzystam z 3 podmiotów, folder Deployments ma 24GB :( Co się musi dziać w przypadku Pana Artura, jeśli ma wiele podmiotów, to masakra jakaś.

 

Nasze biuro dopiero zaczęło korzystać z nexo, więc na dobrą sprawę baza jest niemal pusta w porównaniu ze starym oprogramowaniem innej firmy, której archiwa z 10 lat (Kpir, ksh, kadry i płace) mieszczą się w 1GB archiwum a programy (na każdy rok oddzielny) zajmują 7,3GB. Nasz katalog deployments miał 105GB (wersja 13 oryginalnie instalowana oraz 1 raz aktualizowano podmioty). Po konsultacji z informatykiem usunąłem deployments, robiąc jego kopię na zewnętrznym dysku ale ku mojemu zdziwieniu powierzchnia dysku została bez zmian. W koszu nic się nie pojawiło, nowych plików nie zauważyłem, stare niby zniknęły, 100GB także nie ma. Czarna magia. Widzę jak pliki znikają. Widzę, że deployments jest pusty a ponad 100GB nadal gdzieś jest i nie wiadomo gdzie. Przynajmniej do czasu jak informatyk nie rozpocznie dochodzenia to ja tego nie wiem. Skoro kilka wersji programu jak u Pana Radomiła dla 3 podmiotów potrafi zająć 24GB, to nie wyobrażam sobie co się będzie działo u nas później oraz jakim cudem ma nam starczyć 300GB na serwerze. Koszmar. Zwłaszcza, że używamy niemal pełnego pakietu programów nexo. Wymiana dysków w systemie RAID na serwerze to nie jest taka niewinna zabawa jak na zwykłym komputerze, więc mam nadzieję, że nie będę zmuszony do zlecenia tej "operacji na otwartym sercu" :|

Link to postu
Dnia 5.05.2017 at 16:28, Artur Mechliński napisał:

(...) Kolejna zagadka to fakt, że archiwum wykonane w programie serwisowym wszystkich firm zajmuje 7,5GB a próba konwersji zaledwie 25% firm zakończona zostaje z powodu braku miejsca po "zjedzeniu" aż... 15GB. (...)

Pragniemy wyjaśnić ten temat - proszę więc o podanie informacji o zaznaczonych opcjach w operacji zbiorczej konwersji.

Link to postu

Mamy tutaj do czynienia z kilkoma różnymi problemami i chciałabym zaadresować każdy z osobna. Problemy są takie: 

  1. Kopie zapasowe tworzone przy konwersji zajmują dużo miejsca, bo tworzone są automatycznie i nigdy nie są usuwane.
  2. Usuwanie plików z katalogu Deployments nie powoduje zwolnienia przestrzeni dyskowej ("Próba usunięcia plików "deployments" wywołuje jeszcze dziwniejsze zjawisko. Na moich oczach bowiem pliki są usuwane (opcja usuń PERMANENTNIE) ale przestrzeń się nie zwalnia.").
  3. Zbiorcza konwersja podmiotów powoduje zajęcie dużych ilości miejsca na dysku ("Kolejna zagadka to fakt, że archiwum wykonane w programie serwisowym wszystkich firm zajmuje 7,5GB a próba konwersji zaledwie 25% firm zakończona zostaje z powodu braku miejsca po "zjedzeniu" aż... 15GB.").
  4. Wszystkie dotychczasowe wersje nexo są przechowywane w bazie dystrybucyjnej i/lub na dysku lokalnym i zajmują dużo miejsca, mimo że nie są już używane.

Nie mamy w tej chwili sposobu na łatwe załatwienie tych wszystkich spraw, ale chciałabym wyjaśnić, skąd się biorą te problemy i co można z nimi zrobić już teraz, żeby nie było aż tak źle. 

  1. Przy niewielkiej liczbie podmiotów kopie zapasowe można usuwać w programie serwisowym (menu Podmiot -> Kopie zapasowe na serwerze). W przypadku dużej liczby podmiotów jest za dużo klikania i trzeba kasować pliki z serwerowego katalogu z kopiami zapasowymi.
  2. Pliki programu w katalogu Deployments dzielą się na dwie grupy: pierwsza to pliki w katalogu .zip-cache, a druga to pliki w katalogach utworzonych dla poszczególnych podmiotów (Nexo/{nazwa systemowa podmiotu}).
    Katalog .zip-cache zawiera binaria programu rozpakowane z bazy dystrybucyjnej przy tworzeniu podmiotów (dzięki temu nie trzeba ich stamtąd pobierać przy każdym uruchomieniu podmiotu), natomiast foldery poszczególnych podmiotów (Nexo/{nazwa systemowa podmiotu}/Binaries) zawierają twarde dowiązania (hardlinki) do plików w .zip-cache. W związku z tym usuwanie plików z katalogu podmiotu jest usuwaniem linków i tak naprawdę nie zwalnia miejsca na dysku. 
    Jeśli chodzi o rozmiary i zawartość katalogu .zip-cache, to patrz punkt 4. 
  3. Temat konwersji zbiorczej w Biurze pozostawiam do wyjaśnienia specjalistom od Biura, którzy badają sprawę. 
  4. Przy założeniu, że wiadomo dokładnie, które wersje nexo są używane, można pozostałe usunąć. Co i skąd można wyrzucić:
    * w bazie dystrybucyjnej InsERT_Launcher: z tabeli InsLauncher.Packages można wyrzucić wszystko, co nie jest używane,
    * w {Program Files}\InsERT\nexo\Packages - można wyrzucić wszystko, chyba że są tam jakieś pakiety, o których wiadomo, że są używane, a nie zostały jeszcze załadowane do bazy dystrybucyjnej (zostaną załadowane, gdy uruchomi się podmiot wymagający tych pakietów; można załadować je programem serwisowym),
    * w katalogu Deployments: można wyrzucić cały .zip-cache (podczas używania podmiotu to, co jest faktycznie potrzebne, znowu się tam zapisze, ale nieużywane wersje nie wrócą).

Jeśli chodzi o rozwiązania tych problemów po naszej stronie, to planujemy w kolejnych wersjach programu wprowadzić możliwość usuwania starych kopii zapasowych (problem 1), na żądanie i być może automatycznie. W przypadku usuwania na żądanie taką akcję można by uruchamiać zbiorczo dla wielu podmiotów. Planujemy również usuwanie pakietów z binariami ze starych wersji (problem 4), żeby wyczyścić, to co się nagromadziło i zapobiegać takiemu gromadzeniu w przyszłości. 

 

Mam nadzieję, że moje wyjaśnienia okażą się dla panów pomocne. 

Link to postu

Jak już koleżanka wspomniała, foldery z binariami podmiotów są jedynie 'obrazami' plików z zip-cache, czego jednak programy typu Eksplorator plików nie uwzględniają, w związku przy np. 100 podmiotach pokażą zajętość 600*100 MB = 60 GB (binaria wersji 15.0 zajmują ok. 600 MB), co jest oczywiście nieprawdą. Faktyczną ilość miejsca zajmowaną przez binaria można stwierdzić porównując ilość wolnego miejsca na dysku przed i po wykonaniu operacji 'Usuń binaria ze stacji roboczej'.

 

Dodam jeszcze, że usuwanie nieużywanych pakietów z bazy dystrybucyjnej najlepiej wykonać Programem serwisowym. W tym celu z menu 'Widok' wybrać 'Pokaż  bazy'-> 'nexo oraz Insert Launcher'. Następnie prawoklik  na bazie dystrybucyjnej (najpewniej Insert_Launcher) i opcja 'Binaria'. Dalej należy wybrać pakiety z nieużywanych wersji i wybrać Usuń z serwera.

Czyszczenie 'Deployments' należy wykonać przy użyciu operacji 'Narzędzia' -> 'Usuń binaria ze stacji roboczej'. Przy następnym uruchomieniu programu zostaną pobrane binaria tylko aktualnej wersji.

Link to postu

A czy usunięcie binarii z bazy dystrybucyjnej, spowoduje ich usunięcie na stacja roboczych klientów, podczas uruchamiania programu? Mamy ponad 50 końcówek z NEXO, więc bieżąca konserwacja na tych komputerach, może być czasochłonna - chyba, że modyfikacja, o której wspominała Pani Katarzyna, załatwi temat.

Link to postu

Jeżeli binaria 3 podmiotów zajmują 24 GB na dysku,  polecam skorzystać z opcji 'Usuń binaria ze stacji roboczej'.  Oczekiwana zajętość miejsca po tej operacji, jeżeli podmioty są w tej samej wersji, wynosi ok. 700 MB. 

Oczywiście w kolejnych wersjach będziemy pracować nad tym, aby oczyszczanie miejsca na dysku odbywało się automatycznie.

Edytowane przez Piotr T.
Link to postu

No w moim przypadku, akurat jest to 3 podmioty (dwie spółki plus baza developerska), większość użytkowników korzysta z jednej bazy, a zaczynali około wersji 13, więc póki co problem ich jeszcze nie dotyczy - nie mamy aż tak małych dysków SSD :) U siebie zrobiłem już porządki ręcznie, więc jest ok, a jak wprowadzicie zmiany na przyszłość, to nie muszę dopisywać chłopakom z IT procedury konserwacyjnej w temacie Insert NEXO, nie sądzę, abyście spłodzili w tym roku więcej niż jeszcze ze 4 wersje ;)

 

Link to postu
Dnia 5.05.2017 at 16:28, Artur Mechliński napisał:

Podczas konwersji baz program wymaga gigantycznych ilości przestrzeni na dysku serwera. Zanim zainstalowaliśmy pakiet nexo, na naszym serwerze wolne było ponad 120GB a obecnie został nam 1GB.

Wymagana ilość przestrzeni dyskowej jest pochodną objętości jaka będzie wymagana dla plików które w wyniku tej operacji powstaną: czyli kopia podmiotu na serwerze celem ewentualnego odzyskania podmiotu w przypadku nieudanej konwersji, archiwum podmiotu jeżeli będzie wykonywane mechanizmami Biura, skonwertowany podmiot, którego objętość nieznacznie może wzrosnąć i ewentualne wgranie nowych binariów na dysk serwera - to poniekąd zależy od konfiguracji.

 

Również sam proces konwersji, jak sprawdziliśmy monitorując zajętość dysku w trakcie jej trwania, nie rezerwuje przestrzeni dyskowej przekraczającej niewspółmiemrnie objętość konwertowanego podmiotu.

 

Dnia 5.05.2017 at 16:28, Artur Mechliński napisał:

Połowa klientów nadal nie ma najnowszej wersji, gdyż zbiorowo jest to już niewykonalne a ręczne aktualizowanie znacznej ilości klientów będzie pracą bez końca, gdyż zanim skończę wyjdzie kolejna aktualizacja

 

Zalecam wykorzystywanie operacji zbiorczej do dokonywania konwersji - pozwoli to na przygotowanie podmiotów do pracy za jednym razem. Oczywiście wcześniej należy zapewnić odpowiednią przestrzeń na dysku.

 

Dnia 5.05.2017 at 16:28, Artur Mechliński napisał:

Program "puchnie" w niebywałym tempie, gdyż ten decyduje za mnie o archiwizacji danych przed konwersją i nie daje mi opcji wyboru aby nie zrobić archiwum lub zrobić tymczasowe, które następnie sam usunie. Co ciekawe, jeżeli ten proces (konwersji) zostanie przerwany z powodu braku miejsca, przestrzeń nie zostanie oczyszczona lecz znika w zastraszajacym tempie.

 

Operacje typu "Konwersja podmiotów" czy też "Archiwizacja" postaramy się wzbogacić o możliwość parametryzowania dotyczącego plików archiwizacji czy też kopii na serwerze by zautomatyzować odzyskiwanie miejsca na dysku.

Dnia 5.05.2017 at 16:28, Artur Mechliński napisał:

Kolejna zagadka to fakt, że archiwum wykonane w programie serwisowym wszystkich firm zajmuje 7,5GB a próba konwersji zaledwie 25% firm zakończona zostaje z powodu braku miejsca po "zjedzeniu" aż... 15GB. Czy potraficie mi wyjaśnić i doradzić jak spuścić powietrze z tego nadmuchanego balona?

 

Tutaj nastąpiło chyba nieporozumienie - proszę zwrócić uwagę, że porównuje Pan archiwa, które są plikami skompresowanymi, po dearchiwizacji ich objętość jest większa. Zastanawiam się czy nie ma również czeskiego błędu w tych 15 GB.

 

Niemniej - proces odzyskiwania miejsca po niepotrzebnych już kopiach bądź archiwach będziemy optymalizowali.

Link to postu

Dziękuję za szczegółowy opis problemu oraz deklarację usprawnień. Spróbuję wykonać zasugerowane rozwiązania i mam nadzieję, że uda mi się wygospodarować przestrzeń umożliwiającą wydajną pracę z programem Biuro. 

 

Dnia 12.05.2017 at 15:32, Roman Budzisz napisał:

Tutaj nastąpiło chyba nieporozumienie - proszę zwrócić uwagę, że porównuje Pan archiwa, które są plikami skompresowanymi, po dearchiwizacji ich objętość jest większa. Zastanawiam się czy nie ma również czeskiego błędu w tych 15 GB.

 

Niemniej - proces odzyskiwania miejsca po niepotrzebnych już kopiach bądź archiwach będziemy optymalizowali.

 

Być może nastąpiło nieporozumienie, gdyż faktycznie nie rozumiem dlaczego program wykonuje konwersję baza po bazie a pomimo tej sekwencyjnej czynności na koniec każdej konwersji nie kompresuje tego archiwum lub po prostu go nie usuwa. 

 

W kwestii owych 15GB sprawa wyglądała tak, że podczas kolejnej próby konwersji zbiorowej (po wcześniejszym posiadaniu wolnych około 50GB) zabrakło nam miejsca na serwerze i nie zostało praktycznie nic. Konwersja została przerwana mniej więcej w połowie. Następnego dnia wyszła kolejna aktualizacja, więc chciałem ponowić procedurę aby dokończyć proces i licząc, że nowsza wersja ma jakieś usprawnienia w tej kwestii. Udało mi się w tym celu zwolnić 15GB (wcześniej sprawdzając ile zajmuje archiwum wszyskich baz (skompresowane). Odpaliłem konwersję zbiorową i po pewnym czasie ponownie pozostałem bez miejsca na dysku a aktualizacja podmiotów została przerwana na mniej więcej 25% firm. Obecnie mam więc spory bałagan jeżeli chodzi o wersje programów, gdyż podmioty z początku listy mają najnowsze wersje a na końcu nigdy nie były aktualizowane.

 

Czekam zatem z niecierpliwością na aktualizację rozwiązującą ten problem.

Link to postu
  • 4 miesiące temu...
Dnia 09/05/2017 o 13:46, Katarzyna Rozmarynowska napisał:

Planujemy również usuwanie pakietów z binariami ze starych wersji (problem 4), żeby wyczyścić, to co się nagromadziło i zapobiegać takiemu gromadzeniu w przyszłości. 

Informuję, że w wersji 17 dodaliśmy automatyczne usuwanie binariów ze starych, nieużywanych wersji programu.

Co usuwamy: pakiety programu z bazy InsERT_Launcher, z folderów na końcówce (%programdata%\InsERT\Packages i %localappdata%\InsERT\Packages) oraz z folderu Deployments\.zip-cache. Usuwamy pakiety/pliki, o których wiadomo, że nie były używane co najmniej 90 dni. Informacje o ich użyciu są rejestrowane przez program podczas normalnej pracy i zapisywane w bazie InsERT_Launcher i/lub wymienionych folderach na końcówce.
Kiedy usuwamy: podczas aktualizacji dowolnego podmiotu (w ramach "przygotowywania do uruchomienia programu" - rozpakowujemy nowe binaria i usuwamy stare).
Czego należy się spodziewać: jeśli zainstalują państwo 17, to za 90 dni przy jakiejś aktualizacji podmiotu (np. do wersji 18) wszystkie stare wersje nexo, których już państwo nie używacie (od więcej niż 90 dni), zostaną usunięte. Jeśli zdarzy się, że usuniemy jakieś binaria, które jednak były potrzebne, to InsLauncher przy uruchamianiu podmiotu wymagającego tych binariów zaproponuje pobranie ich z internetu.

Link to postu
  • 2 lata później...

Czy da się zmienić/wskazać ścieżkę folderu C:\Users\Użytkownik1, 2, 3, itd.\AppData\Local\InsERT na wspólną dla wszystkich użytkowników serwera terminali?

np. C:\Users\Public\AppData\Local\InsERT

W chwili obecnej, dla 25 użytkowników tworzą się, dla każdego z nich, zapisy tych samych binariów, co zjada z powierzchni dysku jakieś 50GB ekstra, a w ostatnim czasie, jak między aktualizacjami było mniej niż 90 dni, to dysk zapchał się do 99% co uniemożliwiło zalogowanie się do programów części użytkowników.

Link to postu

Dzień dobry.

18 godzin temu, Wojciech Łozdowski napisał:

Czy da się zmienić/wskazać ścieżkę folderu C:\Users\Użytkownik1, 2, 3, itd.\AppData\Local\InsERT na wspólną dla wszystkich użytkowników serwera terminali?

Tak. Można posłużyć się odpowiednim wpisem w rejestrze Windows. Oczywiście należy zachować dużą ostrożność dokonując zmian w rejestrze systemowym.

W kluczu HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\InsERT\ (na 32-bitowym systemie bez WOW6432Node) należy dodać klucz InsERT nexo. W tak stworzonym kluczu należy dodać wartość ciągu (wpis typu String Value), o nazwie  DeploymentsDirectory, a jego wartością powinna być ścieżka do istniejącego folderu, który stanie się nowym folderem Deployments.

Uwaga! Stary folder Deployments sam nie zniknie. Można z niego usunąć .zip-cache i wszystkie foldery podmiotów.

Czyli instrukcja jest taka:

  1. Utworzyć nowy folder np. P:\Deployments,
  2. Zrobić wpis w rejestrze i jako wartość wstawić "P:\Deployments",
  3. zrobić ew. porządki w starym katalogu użytkowników: można spokojnie usunąć .zip-cache poszczególnych użytkowników oraz z katalogów nexo usunąć foldery podmiotów klientów biura. Pliki UserSettings lepiej zostawić - są tam zapisane parametry uruchomieniowe poszczególnych użytkowników.
  • Dziękuję 1
Link to postu
×
×
  • Dodaj nową pozycję...