częste restarty Firebird, Error Code 401

[mpi]

A konfigurowałeś w jakiś szczególny sposób system lub firebirda?
Dziś z ciekawości wygenerowałem ten sam raport na moim lapku dużo gorszym od komputera w przychodni a jednak tam tworzył się on przez godzinę a u mnie 12 minut.

[PiotrSz]

A konfigurowałeś w jakiś szczególny sposób system lub firebirda?
Dziś z ciekawości wygenerowałem ten sam raport na moim lapku dużo gorszym od komputera w przychodni a jednak tam tworzył się on przez godzinę a u mnie 12 minut.

próbowałem przetestować tą waszą teorię o problemach na systemach 64-bit
wstępne wyniki dla tego samego raportu (ok 5000 zestawów)

- system roboczy, serwer na core2duo win7 pro 32-bit, FB 2.5 w Classic, generowane na stacji klienckiej i5 win7 pro 64-bit - ok 25-30 minut (nie pamiętam dokładnie)

- system testowy 1 - program w wersji jak na roboczej, baza z nocnego backupu roboczej, nowy komp na 2-rdzeniowym pentium z serii G8xx, Win7 Pro 64-bit - generowanie raportu ok 25 minut, testowałem FB w wersji SuperServer i SuperClassic i różnicy w prędkości przy tworzeniu raportu nie było praktycznie żadnej ale gdyby jednocześnie klienci mieli korzystać z tego serwera to Classic byłby szybszy bo jeden rdzeń procesora był wolny i do użycia

- system testowy 2 - program w wersji jak na roboczej, baza z nocnego backupu roboczej, stary lapek na Centrino 1,6 i WinXP Pro 32-bit - generowanie raportu ok 40-45 minut - ale tutaj sprzęt był bardzo słaby więc wynik dla systemu 32-bit totalnie niemiarodajny..

jak mi się uda to może na testowym 1 zainstaluje na chwile Win7Pro 32-bit i powtórzę test

pozdrawiam

[Lastryko]

A konfigurowałeś w jakiś szczególny sposób system lub firebirda? [...]

Nie, przynajmniej nic takiego sobie nie przypominam.
Wszystkie opcje FB mam ustaione na wartości domyślne.

[foti]

Sam nie rozliczam, także odpwiedź z drugiej ręki.
Świadczeń ok 3,5k. Czas tworzenia - od kilkudziesięciu sekund do kilku minut.

Tez wg mnie muli
i7 na pokładzie nowy sprzęt a raport się generuje dłużej niż wczęsniej na P4M
także w programie jest coś skopane jeśli chodzi o generowanie raportów.

[Przemyslaw]

Pytanie co... dwa xeony generują raport prawie godzinę, a c2d 15 minut... wyłączałem już za namową PiotrSZ HT w UEFI ale to nic nie daje...
Brak już mi pomysłów a Kamsoft uważa, że tylko oracle da rade. Czy na pewno problem jest w firebirdzie?
Jakie duże macie bazy? Ja około 6GB. Dyski SAS.

[mpi]

U mnie jedna baza to ok 700MB a muli raport przez godzinę (na moim gorszym sprzęcie 12 minut). Druga baza 1,2GB i też muli.

[Przemyslaw]

Sprawdzałem własnie na Pentium G860. Robi dwa razy szybciej niż dwa Xeony E5630. Ktoś ma jakiś pomysł dlaczego na nowszej architekturze wolniej to działa?

[Lastryko]

[...] Ktoś ma jakiś pomysł dlaczego na nowszej architekturze wolniej to działa?

Nie ma co gdybać.
Ja bym zaczął od badania podstawowych parametrów OS (perfmon).

Przy okazji znalazłem coś takiego.
http://dyemanov.blogspot.com.br/2012/03/firebird-vs-windows-file-system-caching.html

[dobie]

Wychodzi na to ze ma to być rozwiazane w werji 3.0 nad ktorą to prace trwają. Moze ktoś by wyprubowal jak to by sie generowalo na wersji 3.0 beta ( do pracy nie nadaje si epuki co ale test mozńa by zrobić.)

pliki beta
http://www.dqteam.com/fb2/HEAD/

niestety pod linux :-(

[Jose]

Czy któraś z osób które przestawiły FB w tryb Classic server może potwierdzić, że faktycznie przy błędzie na końcówce wywala się tylko ta konkretna, a nie wszystkie?

nie wiem czy znajdziesz kogoś poza mną kto to zrobił..
potwierdzam, że w trybie Classic praktycznie skończyły się problemy wieszania serwera bazy tak, że nie da się pracować
jak się wywala klient to praktycznie tylko on
przez ostatni rok miałem może ze 2-3 takie przypadki, że cały serwer bazy zawisł
w trybie SuperServer zdarzało się po kilka dziennie!

Po kilka dziennie wywalało klientów, ale czy wyskakiwał komunikat error code 401 który podałem w 1. poście i uruchamiałeś ponownie usługe FB?

zanim jednak przełączysz bazę w Classic to proponuję
- jeżeli nie robisz regularnie testów bazy fixem to zacznij (wystarczy w sumie gfix -v ale polecam całego)
- sprawdzenie sieci czy na 100% nie ma z nią problemów
- sprawdzenie czy aby userzy nie uruchamiają po kilka razy PPSa na stanowisku (zdarzało się, że to powodowało restart)
- upgrade silnika i bazy na FB 2.5 ale z tym powoli i ostrożnie - najlepiej sobie jakiś weekend zaplanować i dobrze potestować zanim uruchomisz dla ludzi
- jak to będzie stabilnie chodzić (a przynajmniej nie mniej stabilnie niż teraz) to dopiero próbować Classic

RDP nie powinno mieć wpływu na restarty serwer bazy
u mnie na SuperServer praktycznie nie używałem RDP a restarty i problemy były!
za to zauważyłem, że FB sypał błędami nawet przy połączeniu localhost jak nie były podłączone klienty
wszystko o UDFa się odbijało :-/

do sprawdzenia sieci możesz też użyć darmowego (po rejestracji) Axence NetTools
w najnowszej wersji do opcji NetWatch doszła możliwość odpytywania nie tylko
pingiem ale i konkretnego portu czy działa
można więc zrobić sprawdzanie czy FB odpowiada na 3050 na serwerze

komunikat z loga błędów podawałeś z końcówki (tam 401) a co wywalał FB do firebird.log na serwerze ?
co do Guardiana to ja bym go przy SuperServer jednak zostawił - u mnie przyzwoicie dbał o restart bazy - został do tego specjalnie stworzony!

podsumowując - $#%$% tylu ludzi im już zgłasza z tym problem (ja od 2009 roku!!!) a producent olewa temat.. czy oni naprawdę nie widzą, że większość ludzi którzy mają z tym problem mają duże instalacje z dużymi bazami i prędzej czy później będą potrzebowali większego programu ? ja po takim traktowaniu coraz mniej przychylam się do zakupu kolejnego produktu tego producenta!

pozdrawiam

1) całego gfix tzn.? regularnie z jaką częstotliwością? codziennie robić?
2) to chyba nie problem z siecią skoro po restarcie usługi wszystko działa, prawda? w logu Firebird widać, że zalicza błędy krytyczne przez odwołania do funkcji Kamsoftowych, mój problem polega na tym że przy niektórych resetach serwer FB jak wynika z komunikatu odmawia połączeń (nawet na serwerze, gdzie w kspps.ini mam BAZA_DBSTRING=PPS@localhost:D:\KS\KS-PPS\BAZA\KSPPS.FDB) chciałbym pozbyć się tych błędów i ograniczyć liczbę restartów - wcześniej w logu miałem 4-5 błędów na dzień, teraz między 10 a 20.
3) Owszem, zdarza się, że użytkownicy uruchamiają kilka PPS na jednym stanowisku - z tym będę musiał powalczyć, rejestracja twierdzi, że czasem muszą mieć otwarty naraz terminarz i wizyte np. Pani z Kamsoft podpowiedziała mi, aby do KSPPS.ini dopisać URUCHOM_KILKA_EXE=NIE i faktycznie to działa
4) Nie jestem przekonany do przejścia na 2.5 - z postów na forum widać, że to nie rozwiązuje tego typu problemów, zatem ryzyko przy upgradzie bazy chyba nie warte zachodu
5) Guardian rozumiem tylko nadzoruje czy usługa chodzi i jeśli nie to ją podnosi? Guardian w ogóle mam odinstalowany ale problem był kiedy guardian był zainstalowany i tak samo jest gdy usługe guardiana usunąłem. Poprawiło się tylko to, że Windows zawsze restartuje Firebirda pomyślnie tj. gdy zobacze błąd error code 401 na końcówkach, loguje się na serwer i usługa jest uruchomina za każdym razem. gdy Guarian się opiekował usługą FB to czasem była uruchomiona podczas błędu a czasem nie(więc wystąpienie błędu całkowicie normalne)

log firebird z jednego dnia w załączeniu.
czy ktoś oprócz problem próbował Oracle XE 11g? Czy w ogóle ktoś na forum korzysta z KS PPS na Oracle ?

migracji na 2.5 i Classic ?

2.5 to już mam. Wstępnie się przymierzam (tylko w labie) do sprawdzenia
działania KS-a z FB 2.5.2.
Na sobotę zaplanowałem przełączenie FB w tryb Classic Server.
Przy okazji, zmieniałeś może konfigurację dot. wykorzystania pamięci? (page cache itp.)

@Lastryko
przestawiłeś FB w Classic server? działa?

[Przemyslaw]

Sprawdziłem kolejny raz i napisałem maila do twórców Firebirda. Nie ogarniam tego.

[Lastryko]

W sobotę przestawiłem w tryb Classic Server. Działa.

Nie spodziewam się specjalnie mniejszej ilości restartów
(chociaż w poniedziałek i wtorek nic się nie wydarzyło)
lecz ograniczenia skutku wyjątku tylko do jednego klienta. 

[PiotrSz]

Po kilka dziennie wywalało klientów, ale czy wyskakiwał komunikat error code 401 który podałem w 1. poście i uruchamiałeś ponownie usługe FB?

te same błędy były
Guardian zazwyczaj sam podnosił bazę ale zdarzało się, że trzeba było ręcznie

1) całego gfix tzn.?

całego bata z gfixem i gbakiem
był gdzieś na forum ale jak coś to przypominam mojego

gfix KSPPS.FDB -v -full -user sysdba -pass masterkey
pause
gfix KSPPS.FDB -mend -user sysdba -pass masterkey
pause
gbak -user sysdba -password masterkey -b KSPPS.FDB backup.bak -v -Y log_b.log
pause
ren kspps.fdb kspps.OLD
pause
gbak -user sysdba -password masterkey -c -o backup.bak KSPPS.FDB -Y log_c.log
pause
pause

zapisz sobie to do pliku fix.bat i uruchom w katalogu bazy (ale najpierw na wszelki wypadek standardowa kopia bazy)
oczywiście nie uruchamiaj tego przy podłączonych klientach - jak już nikt nie jest podłączony to dobrze zamknąć port 3050 na firewallu
na czas fixa
wsadziłem tam tyle pauz (które trzeba potwierdzać dowolnym klawiszem) żeby było widać wyniki pracy fixa bo bez tego to okienko znika
po zakończeniu pracy
gfix może dać informacje o błedach w bazie (pierwszy sprawdza baze, drugi naprawia)
pierwszy gbak zrzuca bazę do backup.bak (który jest później niepotrzebny
KSPPS.OLD to stara baza przed poprawkami (może się przydać)
drugi gbak odtwarza bazę z backupu

zrobienie fixa powinno też przyspieszyć troszkę bazę

regularnie z jaką częstotliwością? codziennie robić?

ja standardowo robię teraz raz na miesiąc i ewentualnie jak mam jakieś podejrzenie że z bazą coś się dzieje
jak serwer FB się sypał to po każdej większej wysypce robiłem fixa.. teraz to nie realne bo przy mojej wielkości bazy trwa 20-30 minut

2) to chyba nie problem z siecią skoro po restarcie usługi wszystko działa, prawda? w logu Firebird widać, że zalicza błędy krytyczne przez odwołania do funkcji Kamsoftowych, mój problem polega na tym że przy niektórych resetach serwer FB jak wynika z komunikatu odmawia połączeń (nawet na serwerze, gdzie w kspps.ini mam BAZA_DBSTRING=PPS@localhost:D:\KS\KS-PPS\BAZA\KSPPS.FDB) chciałbym pozbyć się tych błędów i ograniczyć liczbę restartów - wcześniej w logu miałem 4-5 błędów na dzień, teraz między 10 a 20.

problemy z siecią też to mogą powodować (na to od lat wskazywał Kamsoft) ale jeżeli u Ciebie potrafi się wysypać jak kiedyś u mnie na połączeniu do bazy po localhost to ewidentnie problem z UDF

3) Owszem, zdarza się, że użytkownicy uruchamiają kilka PPS na jednym stanowisku - z tym będę musiał powalczyć, rejestracja twierdzi, że czasem muszą mieć otwarty naraz terminarz i wizyte np. Pani z Kamsoft podpowiedziała mi, aby do KSPPS.ini dopisać URUCHOM_KILKA_EXE=NIE i faktycznie to działa

dzięki - przyda się!

4) Nie jestem przekonany do przejścia na 2.5 - z postów na forum widać, że to nie rozwiązuje tego typu problemów, zatem ryzyko przy upgradzie bazy chyba nie warte zachodu

FB 2.5 problemu z UDF nie rozwiązuje ale chodzi dobrze! jeżeli tylko poprawnie się zmigruje bazę to nie ma później z tym problemów

5) Guardian rozumiem tylko nadzoruje czy usługa chodzi i jeśli nie to ją podnosi? Guardian w ogóle mam odinstalowany ale problem był kiedy guardian był zainstalowany i tak samo jest gdy usługe guardiana usunąłem. Poprawiło się tylko to, że Windows zawsze restartuje Firebirda pomyślnie tj. gdy zobacze błąd error code 401 na końcówkach, loguje się na serwer i usługa jest uruchomina za każdym razem. gdy Guarian się opiekował usługą FB to czasem była uruchomiona podczas błędu a czasem nie(więc wystąpienie błędu całkowicie normalne)

nie znam się na tym na tyle.. ale skoro z jakiegoś powodu Guardian dla SuperServer powstał to coś musi być na rzeczy.. dla Classic Server go nie ma i standardowa obsługa usług z windowsa "opiekuje" się serwerem bazy

log firebird z jednego dnia w załączeniu.

błędy jak kiedyś u mnie

czy ktoś oprócz problem próbował Oracle XE 11g? Czy w ogóle ktoś na forum korzysta z KS PPS na Oracle ?

nie jestem pewny czy 11g jest już wspierane w PPSie (coś kojarzę, że ktoś na forum zamieścił odpowiedź Kamsoftu, że Somed jeszcze nie wspiera)
natomiast na 10g na pewno jest kilku świadczeniodawców na forum

z przestawieniem bazy w Classic Server możecie się jeszcze wstrzymać bo podobno wersja PPSa bez UDFa jest już testowana przez kilku świadczeniodawców (ale z jakim skutkiem to nie wiem)

pozdrawiam

[PiotrSz]

W sobotę przestawiłem w tryb Classic Server. Działa.

Nie spodziewam się specjalnie mniejszej ilości restartów
(chociaż w poniedziałek i wtorek nic się nie wydarzyło)
lecz ograniczenia skutku wyjątku tylko do jednego klienta.

dokładnie o to chodzi!
Classic Server nie rozwiązuje problemu z UDFem ale limituje zakres problemu
do hosta który się wysypał!

aha i jeszcze jedno!
nie testowałem Classic Server na FB 2.0 !!! powinno niby działać tak samo ale FB 2.5 ma sporo zmian i wprowadza np trzecią architekturę SuperClassic (jej też nie testowałem)

pozdrawiam

[Lastryko]

1) całego gfix tzn.?

całego bata z gfixem i gbakiem
był gdzieś na forum ale jak coś to przypominam mojego [...]

Ja przed tym wpisuję jeszcze (FB 2.5)
gfix -shut single -force 20 -user sysdba -password masterkey kspps.fdb

W drugą stronę nie trzeba. gbak sam przestawia w tryb normal.