Problem z bazą po awarii zasilania

[Radomił Ząbik 308]

Mieliśmy w zeszły piątek awarię zasilania, chwilowy skok, który jakimś cudem ominął nasze zabezpieczenia prądowe i spowodował wyłączenie się zasilania na serwerze. Serwer uruchomił się normalnie, RAID nie wykazał żadnych problemów, SQL się uruchomił bez problemu, NEXO nic nie wykazało. Jedyne co się wydarzyło, to spowolnienie niektórych procesów w bazie danych, które najłatwiej mi wyśledzić poprzez aplikację Sferyczną. Na przykład, przed awarią, niżej wymieniony kod, wykonywał się sekundę, teraz jak dobrze pójdzie, wykonuje się 7 sekund. Przekombinowaliśmy co mogliśmy, wszystkie ustawienia RAM dla SQL, kopię na DEV, oczyszczanie pliku z logami itp. Niestety, dalej mamy odczuwalne spowolnienia.

 

Funkcja aktualizująca termin realizacji pozycji:

Console.WriteLine(DateTime.Now.ToString("yyyy-MM-dd H:mm:ss")+" - zmiana terminu realizajci w ZK.");
// pobranie danych
IZamowieniaOdKlientow zamowienia = sfera.PodajObiektTypu<IZamowieniaOdKlientow>();
int id; id = results.id; int pid; pid = results.pos;
Console.WriteLine(DateTime.Now.ToString("yyyy-MM-dd H:mm:ss")+" - pobrano dane zamówień.");
var zkDoEdycji = zamowienia.Dane.Wszystkie().Where(z => z.Id == id).FirstOrDefault();
Console.WriteLine(DateTime.Now.ToString("yyyy-MM-dd H:mm:ss")+" - wybrano zamówienie.");
if(zkDoEdycji==null) {}
else using (IZamowienieOdKlienta zamowienie = zamowienia.Znajdz(zkDoEdycji))	
  {
  Console.WriteLine(DateTime.Now.ToString("yyyy-MM-dd H:mm:ss")+" - zmiana terminu realizacji, dla pozycji w zamówieniu: "+zamowienie.Dane.NumerWewnetrzny.PelnaSygnatura);
  var poz = zamowienie.Dane.Pozycje.Where(p => p.Id == pid).SingleOrDefault();
  Console.WriteLine(DateTime.Now.ToString("yyyy-MM-dd H:mm:ss")+" - modyfikacja pozycji: "+poz.AsortymentAktualny.Nazwa);
  // modyfyikacja temrinu
  string dateString = results.term+" 07:00:00,000";
  DateTime posTerm = DateTime.ParseExact(dateString,"yyyy-MM-dd HH:mm:ss,fff",System.Globalization.CultureInfo.InvariantCulture);
  poz.Termin = posTerm;
  
  if(zamowienie.Zapisz())  { Console.WriteLine(DateTime.Now.ToString("yyyy-MM-dd H:mm:ss")+" - zmienione termin pozycji: "+poz.Termin);  response = "{ \"id\":\""+zamowienie.Dane.Id+"\" }"; }
  else { Console.WriteLine(DateTime.Now.ToString("yyyy-MM-dd H:mm:ss")+" - błąd przy zmianie terminu ZK!"); response = "{ \"error\":\""+zamowienie.Bledy+"\" }"; zamowienie.WypiszBledy(); }
  }	

A jej faktyczne wykonywanie wygląda tak:

Funkcja zajmuje prawie cały czas zużywa na otwarciem dokumentu do edycji. Pozostałe rzeczy, łącznie z zapisaniem, zajmują milisekundy.

Podobne spowolnienia odczuwamy przy przetwarzaniu pozycji ZK w WZ, przetwarzaniu WZ do FS, dopisywaniu informacji do pól własnych FZ.

Tworzenie PW/RW, o dziwo chodzi w miarę normalnie, jest to lekkie spowolnienie, nawet nieodczuwalne, tak jakby problemem były bardziej zaawansowane dokumenty i nie chodzi tutaj o rozbicie partii, bo jest ono stosowane w obu przypadkach - może to rozrachunki, podmioty.

Spowolnień nie odczuwamy na dodawaniu czy modyfikowaniu asortymentu, działaniach związanych z urlopami.

 

Powyższy przypadek sprawdziłem też profilerem. W trakcie otwierania do edycji ZK, zapytania lecą praktycznie od ręki, ale są notorycznie przerywane przez Audit logout, z wartościami ponad 2 000 000 odczytów i trwających nawet do kiluset ms, nijako opóźniających następny proces.

 

Jakieś sugestie, gdzie szukać problemu? Bazę odpaliliśmy tez na innej instancji na tym serwerze, problem dalej występuje.

[Andrzej Kubik 1 098]

Czy zrobił Pan odbudowę indeksów?

[Radomił Ząbik 308]

A przepraszam, pisałem ten referat dłuższą chwilę - tak, oczywiście zrobiłem konserwację bazy danych

Dodatkowo, na kopii, na której też kiepsko działa:

- zrobiłem konserwacje skryptem SQL

- usunąłem (po walce z wielkością plika logu) całą zawartość śladu rewizyjnego

- skompaktowałem bazę

- zrobiłem znowu konserwację

- nawet dodałem dodatkowy plik Data do bazy danych

Żadne z powyższych efektu wydajnościowego nie przyniosło, no może kilkanaście procent.

[Andrzej Kubik 1 098]

Kompaktowanie to akurat mogło tylko spowolnić...

[Radomił Ząbik 308]

Wiem, dlatego próby przeprowadzałem na kopii. Tonący brzytwy się chwyta.

[Paweł Szczygieł 36]

Próbował Pan uruchomić tą bazę na innej maszynie  na innej instancji SQLa?

[Radomił Ząbik 308]

Na maszynie są dwie instancje i na tej drugiej także jest to spowolnienie, ale tak, w planach na weekend mamy odpalenie na innej maszynie - tylko nie wiadomo jak z efektem, bo jednak maszyna na której stoi to 2 procesorowy serwer, z 128GB RAM z zapisem na dyskach rzędu 11 GB/s. Przy okazji tego zabiegu, będziemy też sprawdzać RAID, bo jest 40% różnica między działaniem na czysto po instalacji, a obecnej, co prawda z obciążeniem, w postaci około 40%, aczkolwiek, dziwne jakby z tego wynikało spowolnienie rzędu kilkuset procent

 

Przed:

Po:

 

Nie ukrywam, że zbieram jakieś sugestie, co jeszcze moglibyśmy sprawdzić, co przegapiliśmy. Zapewne nie jedna osoba, nie raz już jakieś problemy miała, więc może podpowie. Baza chodzi, ale widząc skok wydajności w niektórych zadaniach, jest to wręcz wkur ....

 

 

Mnie osobiście intryguje jeszcze zachowanie się użycia RAM przez maszynę. Główna instancja ma ustawione blokowanie stron pamięci, i wyświetla go dopiero jak się wejdzie głębiej, ale z drugiej strony, druga instancja developerska nie ma tego ustawienia i działa tak samo wolno.

Produkcja z Lock Pages na dole, Devka z ustawionym na twardo limitem 10GB na górze.

 

 

[Łukasz Czarnowski 17]

1) Jeżeli jest taka możliwość - dołożyć dysk/i (najlepiej oddzielny kontroler / inny interface) i na nim posadzić instancję testową

2) Załadować ostatni backup na w/w

[Radomił Ząbik 308]

Instalacja na osobnym dysku NVME 2GB/s, daje analogiczne efekty.

Generalnie po jakiś testach, odnosimy wrażenie, że samo SQL działa dobrze.

Problem jest podczas wchodzenia w edycję ZK/WZ/FS/ZD/PZ/FZ. Na tym serwerze mamy jeszcze kilka podmiotów, co prawda z zdecydowanie mniejszymi bazami, ale po zrobieniu testów na nich, działa wszystko szybko, otwarcie do edycji trwa 1 sekundę. Więc jest to jakaś kwestia wydajnościowa, tylko czemu akurat diametralne odczucie zaraz po tej awarii.

W tym tygodniu, postawimy jeszcze na innej maszynie, i ewentualnie w weekend reinstalacja serwera.

[Wojciech Szopiński 227]

Czy polecenie:

DBCC CHECKDB

zwraca jakieś błędy?

[Radomił Ząbik 308]

Nie, albo coś przegapiłem - załącznik.

checkbazy.txt

 

Dla takiej kombinacji:

dbcc checkdb ('Nexo_InvestTech') WITH NO_INFOMSGS, ALL_ERRORMSGS

... mamy to ...

Commands completed successfully.

 

[Wojciech Szopiński 227]

Poprosimy o wygenerowanie danych diagnostycznych (Ctrl + Shift + H -> Eksportuj dane diagnostyczne) i wysłanie do nas. Może być w wiadomości prywatnej.

Proszę jeszcze sprawdzić zawartość tabeli mox.application_session gdy nikt nie pracuje na programie. Jeśli okaże się, że będą tam jakieś wpisy to proszę wykonać taką komendę:

delete from mox.application_session;