MySQL: Sending data oraz Waiting for table level lock

0

Od jakiegoś czasu próbuję rozwiązać kwestię integracji opartej o pliki xml oraz bazę danych MySQL.
Odkąd cała integracja została napisana wszystko działało elegancko, aż do kilku dni wstecz. Z tego co wiem, to po stronie serwera ani bazy kompletnie nic się nie zmieniło.

Przy odpaleniu pliku php przez CRON (lub ręcznie) zawsze wszystkie zapytania zawieszają się ze "statusem" (?) **Sending data ** oraz Waiting for table level lock

Jak wygląda integracja:
Na serwer wpadają pliki xml.
Plik parsuje ten dokument i wykonuje operację na bazie - albo insert, albo update (jeśli plik istnieje ale został zaktualizowany) albo delete.
Ogólnie CRON wywołuje się co 10min, a pliki są wrzucane średnio co 3-5min (ważą max max 1MB)

Przy odpaleniu integracji, w bazie pokazuje się nawet do 60 procesów wywołanych przez integracje wszystkie ze statusem Sending data lub Waiting for table level lock
Co ciekawe pozostają one tak zawieszone do czasu aż ich ktoś nie ubije... Dodam, że w tym czasie serwis, który działa w oparciu o te integracje nie działa (pewnie wyczerpana ilość socketów połączenia?), natomiast inny serwis, który również bazuje na tym samy serwerze bazodanowym ale innej bazie działa bez zarzutów i problemów żadnych nie ma.

Miał ktoś podobną sytuację? Co może być przyczyną, że procesy od razu uzyskują Waiting for table level lock?
Dodam jeszcze, że testowo odpalałem integrację z jednym plikiem xml, w którym były 3 wpisy (czyli 3 produkty) i na tych 3 również wszystko się wieszało.

// całość działa w oparciu o bazę, w której pojedyncza tabela nie posiada więcej niż 1mln rekordów - nie wiem czy to istotne ale piszę:)

Z góry dziękuję za ewentualne sugestie.

0

A indeksy na tabelach które zmieniasz masz?

0

@Panczo - tak, indeksy były nadane.
Dzisiaj podjąłem dość radykalne kroki: Stop CRON, reset serwera, reset serwera bazodanowego.
Po ponownym odpaleniu wszystko załapało i działa poprawnie.

Ciekawe tylko, co było problemem?

0

Tak dla pewności - InnoDB? Sprawdź ten dokument, który był wtedy przetwarzany. Jeżeli optymalizator wybrał plan bez indeksów i chciał zrobić table level lock to przy działających transakcjach na tych samych danych nie mógł się doczekać.

0

@ralf: jest MyISAM - może tutaj tkwi problem?

1

No oczywiście, MyISAM to jakiś archaizm, to coś nawet nie ma normalnych transakcji. Jakakolwiek operacja DML blokuje całą tabelę

0

@ralf: InnoDB będzie najbardziej wydajne dla takich operacji jak Insert/Update/Delete?

1

MyISAM to najstarsza i najprostsza wersja gdzie każda operacja modyfikacji danych blokuje całą tabelę, wszystkie inne sesje muszą czekać. InnoDB to silnik działający tak jak inne współczesne bazy relacyjne, gdzie przy zapisie blokowany jest tylko dany wiersz. Najbardziej jest to widoczne przy dużej ilości danych i wielu równoległych operacjach. Dziwne, że masz u siebie MyISAM bo InnoDB powinno być domyślnym silnikiem od dość dawna.

1 użytkowników online, w tym zalogowanych: 0, gości: 1