Jak zidentyfikować źródło dużego obciążenia dysków na serwerze Firebird?

Witam.

Od piątku zauważyłem bardzo duże obciążenie dyków w serwerze (kontroler RAID 1 dwa dyski Sata HOT-SWOP).
Na serwerze znajdują się bazy danych głównie firebird - 10 baz, baza SQL, użytkowników ok. 20. Procesor Xeon 4 x 2.0 Ghz, 4 GB RAM, Server 2003 STD 32 bity. Firebird 2.1.3 Superserwer, do wczoraj Classic - przejście nie pomogło.

Od piątku obserwuje w systemowym narzędziu wydajności komputera że skala użycia dysku prawie cały czas oscyluje na poziomie 60-100%, wcześniej nie więcej niż 30 %. Pamięć i procesor praktycznie bez obciążenia. Po godzinach pracy jest ok.

Jak sprawdzić kto lub co powoduje takie obciążenie dysku?

Jeśli chodzi o udziały to nic się nie dzieje na folderze udostępnionym.

gg: 2267554, PILNE

Jeżeli serwer pracuje pod Windowsem, ściągnij i użyj narzędzia Process explorer. Będziesz tam miał wypisane wszystkie procesy, w ich właściwościach będą szczegółowe dane o operacjach dyskowych, coś w style I/O albo Performance. Możesz też włączyć ich podgląd wybierając View -> Select Columns.

na podstawie tego programiku widać że firebird znacząco wpływa na dysk ale w tej chwili dysk nie jest przeciążony. Mam problem z tym, kto obciąża, ponieważ są takie luki gdzie obciążenie dysku jest niewielkie i czasem trwa to nawet pół godziny. Początkowo odłączałem klientów stopniowo i obserwowałem ale to się nie sprawdza ponieważ, ciężko wyczuć czy odłączenie pomogło czy po prostu w tej chwili jest lepiej.

W takim razie albo ktoś wykonuje jakieś zasobożerne zapytania do bazy, albo sam firebird wykonuje jakieś operacje (przebudowa indeksów, kompresja danych - nie znam Firebirda na tyle żeby się wypowiedzieć).
Powinien mieć jakieś narzędzie do analizy bazy i zapytań do niej - czasu wykonywania zapytań, odwołań do dysku etc. Tutaj pada kilka nazw programów, które myślę że warto wypróbować (co prawda shareware, ale powinny wystarczyć).
Niemniej niech się wypowie ktoś, kto miał z tym styczność

Zainstalowałem Synatica. Nie wiem o co chodzi z "Awaiting GC" bo jest bardzo wysokie w tej bazie, natomiast w innej go niema, za to jest ponad 200 MB odczytu:



Nie bardzo jestem zorientowany w tym programie, ktoś pomoże?

Dodano po 5 [minuty]:

I jeszcze pytanie w Synatica pokazuje Cache w GB/s obok Disk MB/s, i cache sięga niekiedy 1 GB/s, jak to wpływa na pracę dysku?

Zasady dodawania fotografii znajdziesz tu: Zasady. Proszę to poprawić. - arnoldziq

Jak tak patrzę na te zdjęcia, to ponad 100.000 oczekujących transakcji wydaje się o wiele za dużo. Co prawda nie wiem co to za baza/aplikacja jest, ale prawdopodobieństwo że korzysta z niej 100.000 osób jednocześnie wydaje się mało prawdopodobne.
Cytując producenta:

Cytat:

4. What does the number "Awaiting CG" mean?
It is the total number of transactions that cannot be visited by the Garbage Collector.
If some transaction is open for too long, the Garbage Collector cannot advance. The number of transactions awaiting GC, thus, grows.
Also, if this number grows too big, database performance will be severely affected. You may want to review you transaction management code to guarantee no transaction will be left open for too long. Sinática Monitor may help you with that. Configure Sinática Monitor's Stuck Transactions Alarm to be alerted about problems with transaction management in your database.

Popatrz czy zakładki Transactions, Sql lub Statement coś więcej pokazują?
Bo to wygląda na problem z aplikacją korzystającą z tej bazy, która otwiera transakcje, ale z jakiegoś powodu ani ich nie zatwierdza, ani nie wycofuje. Jeżeli w transakcjach będziesz miał multum ze statusem Active z jakąś starą datą otarcia, to może być to.

w transactions mam dwa Active, z 50 finished, i tyle samo Idle.

Dodano po 38 [minuty]:

To wygląda ciekawie, ale czemu te transakcje nie są czyszczone



Zasady dodawania fotografii znajdziesz tu: Zasady. Proszę to poprawić. - arnoldziq

udało mi się ustalić że winien jest firebird, a dokładnie obciążenie jakie generuje na dysk. Z moich testów wynika że Firebird w wersji Classic lepiej radzi sobie z procesorem (rozkłada obciążenie na 4 rdzenie) ale bardziej obciąża dysk. Wczoraj zrobiłem przejście na Firebird Superserver i zaobserwowałem poprawę pracy dysku, problem dotyczył wówczas procesora, ponieważ jeśli ktoś zapuścił sobie w programie jakieś sprawozdanie to jeden rdzeń procka obciążony był w niemal 100% a trzy wcale. Dziś znów przeszedłem na Firebird Classic, procek ładnie równomiernie obciążony ale dysk w najlepszym przypadku wygląda tak:


Nadal nie wiem co zrobić z AWAITING GC bazy pokazanej powyżej, dziś od godziny 7.00 do 8.30 jest już 7000 oczekujący, w pozostałych bazach jeśli na chwile pojawi się Awaiting GC to po chwili jest skutecznie czyszczony do zera. Pomysł?

A jak dla jednej, wybranej transakcji, która utknęła, wybierzesz View Statements View Transactions albo View Attachements, to co widać? Może zachodzi zjawisko wzajemnego blokowania rekordów (deadlocks)? Co piszą w tych Suggestions z obrazka, których nie widać??