[1.2.0] Problem zamrażania aplikacji i zuzycie CPU 100%

[_euan_ 1]

W poprzednich wersjach sello takie zachowanie również wystepowało. Myślałem ze w 1.2 zoptymalizujecie nieco kod i wspoldzielenie czasu procesora miedzy wątkami - niestety zaraz po instalacji nowej wersji sello udało mi się zrobić to co zawsze.

 

Wystarczy włączyć Odbieranie parametrów z serwisu z zaznaczonymi wszystkimi opcjami dotyczącymi aukcji oprócz ostatniej, czyli tylko dla niekompletnych aukcji. Czekamy chwilę aż nawiąże połączenie i rozpocznie pobierać dane. Zaznaczamy wsystkie transakcje CTRL+A i grupujemy je według klienta CTRL+G. W 75% przypadków Sello zamraża się i przestaje odpowiadać. Obciążenie procesora skacze nagle ze standardowego 5-15% do 100%. Można czekać kilkadziesiat minut i nic. Należy zrestartować Sello gdyż z tego stanu najczęsciej juz nie wychodzi.

 

Przy duzej ilosci stworzonych paczek, zaznaczamy wszystkich klientów i wybieramy Oznacz jako wyslane/odebrane. W momencie gdy Sello tworzy automatyczne wiadomosci o nadaniu wysylki następuje zamrozenie (jakies 40% szans ). Jednak z tego stanu Sello wychodzi zawsze - po uplywie nie wiecej niz 5 minut.

 

Czy u innych występuje też takie zachowanie? Komputer na ktorym uruchamiam klienta Sello to Celeron 2,2 GHz z 2 GB Ramu. Zoptymalizowany do pracy jak należy.

 

Na serwerze gdzie uruchamiana jest baza danych, Dell Pentium 4 3,2 GHz z 4 GB Ramu, również takie zachowanie sie pojawia.

 

Czy programisci moga sie udzielic w tym wątku? Moze wspolnie dojdziemy do jakiegos rozwiazania, ktore spowoduje stabilniejsza prace Sello.

 

PS. czesto tez przy pobieraniu informacji z serwera przestaje dzialac menu kontekstowe wywoływane spod prawego przycisku myszy. w poprzednich wersjach tez to bylo.

[e-strefa 0]

U mnie czesto sello sie wieszalo przy zaznaczaniu jako wyslane, ale w nowej wersji (zarowno becie jak i fianlu) problem chyba ustapil. U mnie sello nigdy sie nie podnosilo.

 

A co do kontekstowego menu to problem jest chyba nada. Napewno jak wlaczymy sello i nie damy mu pobrac parametrow, tylko odrazu wybierzemy jakas inna zaskladke niz start to prawy klawisz myszki dzialac nie bedzie.

[mac 1]

Czy u innych występuje też takie zachowanie?

 

Takie i inne. Niestety wygląda na to, że przez te pól roku niewiele zostało poprawione.

[Bartosz Rosa 1 785]

Myślałem ze w 1.2 zoptymalizujecie nieco kod i wspoldzielenie czasu procesora miedzy wątkami

współdzielenie czasu procesora nie ma tu nic do rzeczy, tym się zajmuje system operacyjny bo to on przydziela procesorowi zadania.

 

W 75% przypadków Sello zamraża się i przestaje odpowiadać. Obciążenie procesora skacze nagle ze standardowego 5-15% do 100%. Można czekać kilkadziesiat minut i nic. Należy zrestartować Sello gdyż z tego stanu najczęsciej juz nie wychodzi.

To faktycznie jest problem, a aplikacja zamraża się dlatego, że operacja grupowania jest wykonywana z głównego wątku. Ile jest tych transakcji, że doprowadzają do zawiśnięcia? Czy jest połączenie z GT?

 

Przy duzej ilosci stworzonych paczek, zaznaczamy wszystkich klientów i wybieramy Oznacz jako wyslane/odebrane. W momencie gdy Sello tworzy automatyczne wiadomosci o nadaniu wysylki następuje zamrozenie (jakies 40% szans ). Jednak z tego stanu Sello wychodzi zawsze - po uplywie nie wiecej niz 5 minut.

sytuacja jak wyżej

 

Czy programisci moga sie udzielic w tym wątku? Moze wspolnie dojdziemy do jakiegos rozwiazania, ktore spowoduje stabilniejsza prace Sello.

Jak najbardziej, potrzebujemy tylko nieco więcej informacji, żeby odtworzyć środowisko pracy. Czyli ile jest średnio obiektów (transakcja, paczka) poddawanych zbiorowym operacjom, czy jest połączenie z GT?

 

Sprawy związane z wydajnością będą dopracowywane w myślę niedługiej przyszłości, bo do tej pory zawsze było "coś ważniejszego" i nie starczało siły roboczej na optymalizacje - a niektóre szkoły programowania mówią "zrób żeby działało, a potem optymalizuj". Tak, że może przydałby się wątek w którym można by wpisywać wszelkie miejsca i sytuacje, które spowalniają pracę lub wręcz uniemożliwiają. Wtedy o wiele łatwiej np mi znaleźć na forum to czego szukam, niż przeszukiwać całe forum i pamiętać, że ktoś tam kiedyś zgłaszał COŚ, albo otwierać kilkanaście wątków, które są wpisane do naszej bazy błędów.

 

PS. czesto tez przy pobieraniu informacji z serwera przestaje dzialac menu kontekstowe wywoływane spod prawego przycisku myszy. w poprzednich wersjach tez to bylo.

To jest bardzo ciężki do wyśledzenia błąd bo pojawia się tak samo znienacka jak i znika, gdy chce się go namierzyć. Mam nadzieję, że chociaż odświeżanie list (gridów) podczas synchronizacji działa poprawnie (bo też był taki problem)

[mac 1]

Sprawy związane z wydajnością będą dopracowywane w myślę niedługiej przyszłości, bo do tej pory zawsze było "coś ważniejszego" i nie starczało siły roboczej na optymalizacje - a niektóre szkoły programowania mówią "zrób żeby działało, a potem optymalizuj". Tak, że może przydałby się wątek w którym można by wpisywać wszelkie miejsca i sytuacje, które spowalniają pracę lub wręcz uniemożliwiają. Wtedy o wiele łatwiej np mi znaleźć na forum to czego szukam, niż przeszukiwać całe forum i pamiętać, że ktoś tam kiedyś zgłaszał COŚ, albo otwierać kilkanaście wątków, które są wpisane do naszej bazy błędów.

 

To to to.

Ale przede wszystki przydałby się bugtracker z prawdziwego zdarzenia bo:

 

"Wtedy o wiele łatwiej np mi znaleźć na forum to czego szukam, niż przeszukiwać całe forum i pamiętać, że ktoś tam kiedyś zgłaszał COŚ, albo otwierać kilkanaście wątków,...."

 

Jest to naprawde wkurzająca sytuacja kiedy zgłaszasz bład, a pól roku później przy nowej wersji okazuje się że ów bład...ma się całkiem dobrze.

I teraz pojawiają się myśli "czy go zgłaszałem ? czy tylko o tym pomyślałem". Potem szukanie w wypowiedziach z przed kilku miesięcy . ehh szkoda gadać.

Lista bugów to chyba nie żadna tajemnica "państwowa"!

[e-strefa 0]

Mac masz racje. Ja tez sie ciagle zastanawiam czy zglaszalem czy nie, a niektore rzeczy wiem ze sa na "todo" i nawet ich juz nie zglaszam(nie wiem czy slusznie), a widze tez ze maja sie dobrze

[Bartosz Rosa 1 785]

ja to rozumiem, ale mamy swój nieco rozbudowany bugtracker firmowy, a prowadzenie dwóch będzie stwarzać tylko więcej problemów nam.

[_euan_ 1]

Czemu nie odpalić nowego wątku z niższmym priorytetem który odpowiedzialny byłby za zgrupowanie transakcji lub wysyłanie/odebranie paczek? wielowątkowość to jednak podstawa. operacje iteracyjne najlepiej umieszczać w osobnych wątkach nie w głównym, żeby właśnie uniknąć owego zamrażania aplikacji.

 

współdzielenie czasu procesora nie ma tu nic do rzeczy, tym się zajmuje system operacyjny bo to on przydziela procesorowi zadania.

 

można na to oczywiscie wpłynąć poprzez priorytetowanie wątków.

 

rozumiem że pozostawiliście to w głównym wątku gdyz nie jest to operacja długa ani skomplikowana - więc skończy się błyskawicznie nie powodujac przyhamowania sello. owszem macie racje - ale wychodzi na to że "algorytm" grupowania macie naprawde spieprzony, jeśli powoduje takie zamrażanie dla jedynie 50-120 transakcji. Nawet jesli nie ma transakcji do zgrupowania. Albo odpalic operacje w osobnym wątku albo zmienić sposob grupowania (zmienic zasadę porównywania pól, posiedziec przy komendach wysyłanych do mssql itp.)

 

co do wysyłane/odebrane - zdarza się coś takie przy również śmiesznie małej ilości rzędu 10-35 paczek.

 

powiązanie z subiektem GT istnieje. wystawianie dokumentów poczatkowych czy koncowych zostało wyłączone już dawno temu. stan towarów w subiekcie również nie jest aktualizowany. połączenie z subiektem jest tylko do synchronizacji towarów (cen, zdjęć, opisów, ilości). synchronizacja z subiektem odbywa się automatycznie co 8 godzin (poza godzinami pracy).

 

pondato automatyczne odbieranie transakcji i komentarzy ustawione jest na 5 minut (na serwerze). wysylanie wiadomosci co 2 minuty.

 

PS. jako ze jestem programistą doskonale zdaję sobie sprawe że ważniejsze jest dla Was że aplikacja robi 100 innych rzeczy prawidłowo. że wogóle działa. tez byłoby to dla mnie najistotniejsze. no ale testy to testy dlatego zameczam takimi "bzdetami" zamrazająca sie aplikacja przy jakiejs operacji to bez wątpienia niechlujna szkoła programowania - zmiencie to, a wyjdzie Wam na dobre :] (z Subiektem GT to samo ). pozdrawiam.

[Bartosz Rosa 1 785]

oczywiście racja z wątkami, i prawdopodobnie tak to będzie zrobione. Ja zazwyczaj jeśli używałem grupowania to co najwyżej kilku transakcji - grupowania nie robiłem więc i nie sprawdzałem jego wydajności.

 

Tu może nie chodzić o wydajność samego kodu, ale zdarzało się, że serwer sql na niektórych komputerach potrafi timeouty rzucać przy prostych operacjach, gdzie na innym komputerze dużo bardziej skomplikowane operacje wykonywał szybko. Jakby spytać specjalistów od sqla jak poprawić jego wydajność, pierwsza odpowiedź brzmi - dołożyć więcej ramu. Może tędy droga w niektórych przypadkach? Choć u Ciebie raczej sql serwer na brak ramu narzekać nie może.

 

no ale testy to testy dlatego zameczam takimi "bzdetami" Mrugnięcie zamrazająca sie aplikacja przy jakiejs operacji to bez wątpienia niechlujna szkoła programowania - zmiencie to, a wyjdzie Wam na dobre :]

no i bardzo dobrze że zamęczasz "bzdetami" bo to jest istotne

[e-strefa 0]

Co do zanzaczania wyslanych paczek to u mnie wieszalo sie zawsze gdy byly mieszane (listy i pobrania), a jak byly do tego paczki to juz 100% pewnosci ze bedzie zwis i tak na przykald oznaczanie jako wyslane dla 8-10 paczek na 3-4 razy!!!

Nowe sello ja narazie sie nie powiesilo.

 

Co do sprzetu to prawda jest ze mam wszystko na laptopie, ale ramu mam 2GB, wiec tragedii nie ma.