Wpis z mikrobloga

@Qrystus: Przy okazji. Nie wiesz jak ogarnąć narzut bazy na jeden wątek procesora na serwerze bez dostępu do zapytań? Przy autoryzacji użytkownika mam 100% użycia na jednym wątku, a 0% na kolejne 23...
  • Odpowiedz
@carlo497: tak informacyjne:

Zasadniczo to jeden wątek zawsze wykonuje się na jednym CPU (rdzeniu) na raz. Tak działa ta architektura i tak samo zachowa się każdy program. Pytaniem otwartym jest co robi ta Twoja baza w czasie gdy wątek wysyca rdzeń na którym jest w 100%.
  • Odpowiedz
@maniac777: To jest właśnie zagadka. Gdy wykonuję jakiś większy select to odpala się parę procesów i przykładowo mam obciążone 8 wątków po 2% ale w jednym konkretnym przypadku ten mechanizm nie działa i nie pojawia się żaden nowy proces bazy, a sam narzut jest ogromny.
  • Odpowiedz
@carlo497: Bazy danych dla skomplikowanych zapytań mogą wykonać część zdań równolegle odpalając osobne wątki dla fragmentów zapytania które są niezależne od siebie (np przy UNION, niektórych podzapytaniach czy złączeniach). Jest to technika przyspieszająca jednostkowy czas wykonania, ale ze względu na to że całość i tak musi być jeszcze potem złożona do kupy może być sumarycznie bardziej obciążająca CPU. Jak się domyślasz dla prostszych i bardziej monolitycznych zapytań (nawet kosztownych obliczeniowo) może
  • Odpowiedz
@maniac777: Domyślałem się, że tak to będzie działać tylko jest jedno ale. Tutaj od kliknięcia przycisku zaloguj po podaniu loginu i hasła mija około 5-10 sekund zanim cokolwiek się stanie. Producent oprogramowania daje dupy i nie potrafi tego naprawić, a ja próbuję to jakoś obejść.
  • Odpowiedz
@carlo497: Pytanie czy piszesz o przycisku zaloguj w kliencie bazy czy o przycisku zaloguj w aplikacji która jej używa?
Przypuszczam piszesz o aplikacji i jak większość aplikacji po zalogowaniu pobiera z bazy jakieś informacje potrzebne jej do pracy (choćby uprawnienia użytkownika, wersję schemy, strukturę, może wykonuje jakieś testy spójności danych etc).

Sugeruję byś sprawdził czego Ci przede wszystkim brakuje, czy CPU czy IO bo niby wątek zaczął się od dysków, ale
  • Odpowiedz
@maniac777: Testowałem tak wiele konfiguracji, że mogę być tylko pewien, że IO nigdy mi nie brakowało, a cpu zawsze miał 100% na jednym rdzeniu.
Sam wątek dotyczył tego czy ktoś miał może doświadczenie z wykastrowaniem macierzy sprzętowej i przejściem na programową na produkcji, a z tym problemem przy logowaniu już się pogodziłem, że raczej nigdy go nie rozwiążę.
Sama baza wytrzymuje przetwarzanie zapytania o tysiące wpisów z wykorzystaniem setek korelacji co
  • Odpowiedz
@carlo497: Czyli generalnie nie masz problemów wydajnościowych, a logowanie to taka przypadłość tej aplikacji - złota zasada, jak działa, to nie naprawiaj :)

Ja nie miałem doświadczenia z ZFS i RAIDZ-2, ale na podstawie pozostałych doświadczeń mogę Ci powiedzieć, że to raczej ślepa uliczka - RAID 10, przyzwoita bmacierz z BBWC będzie lepszym środowiskiem dla bazy danych (przy założeniu że mówimy o podobnej ilości podobnych dysków).

Mam do czynienia tylko z
  • Odpowiedz
  • 0
@maniac777 generalnie potrzebuje dobrej replikacji i uciekam z vmware na proxmoxa, a sam zfs ma genialny system snapshotow po zfsie. O ile prawdziwego ha nie zrobię bo nie mam jak zapewnić fencingu o tyle mam zamiar zrobić 4 nody wymieniajace sie danymi.
  • Odpowiedz
@ManamanaTuriruriru: nie dobijaj leżącego. Pomóż jak się znasz i napisz co ta baza lubi najbardziej.
Developerzy tej aplikacji to idioci. Serio, mogę hacki do ich apki i bazy zrobić bardziej zaawansowane niż oni mają aplikację po 10 latach.
  • Odpowiedz
@carlo497 jak zapytania są #!$%@? to architektura nie zrobi tu szału. Pewnie jest tam masa LIKE i one-to-many, przez co joiny tabel zabijają wydajność. W takiej sytuacji najlepiej by było odwrócić zapytania, ale to dla devów robota. To są problemy indeksowania danych i projektowania bazy. Jakie to oprogramowanie dokładnie? Bym na nie nie wpadł przypadkiem.
  • Odpowiedz