Wysokie obciążenie w środku nocy

[Gość]

Witajcie,

Od około miesiąca obserwuje wysokie użycie MySQL w środku nocy.

Na koncie funkcjonują 3 seokatalogi.

Serwer jest na IQ.pl.

Hasła były zmienione, na FTP nie mam niczego podejrzanego, w "statystykach skryptów" na IQ.pl nie wykonują się obce skrypty.

Tak to wygląda na wykresie:

Jakieś pomysły?

[miz]

może backup bazy sie do tego liczy? jak masz bazę 50 MB+ to jest sporo już orania dla serwera zapis i spakowanie tego.

[Beerbant]

Sprawdź/poproś o logi serwera, bedziesz miał jasność w temacie.

[MaxPan]

tez obstawiam automatyczny backup bazy

[Mion]

Serwer jest na IQ.pl.

Wiec pytaj BOK IQ.pl.

tez obstawiam automatyczny backup bazy

Nie powinien być "robiony z wykorzystaniem jego czasu procesora", ale jednostki centralnej usera root. Chyba, że jest BUG w systemie zliczania.

[Gość]

może backup bazy sie do tego liczy? jak masz bazę 50 MB+ to jest sporo już orania dla serwera zapis i spakowanie tego.

Dziwne, aby backup bazy wykorzystywał nawet 20% procesora (zdarzył się taki wynik 2 tygodnie temu). Nawet przeliczanie łącznie 130 tysięcy tagów w seokatalogu nie spowodowało takiego obciążenia...

Sprawdź/poproś o logi serwera, bedziesz miał jasność w temacie.

Mam dostęp do logów FTP, niczego podejrzanego nie dopatrzyłem się.

Wiec pytaj BOK IQ.pl.

Pytałem się, ze 3 razy - nie wiedzą... w logach MySQL nie zauważyli żadnych 'długich zapytań', twierdzą że powoduje to skrypt w CRON (który wykonuje tylko 1 małe polecenie do SQL - truncate table...).

[Mion]

o 1 małe polecenie do SQL - truncate table...).

Widocznie to polecenie truncate table które usuwa wszystkie dane z tabeli wymaga dużych zasobów .

[FirSoft]

A przypadkiem SeoKatalog nie aktualizuje czegoś dokładnie o tym czasie?.

Wydaje mi się, że to na 100 procent jakieś zaplanowane zadanie cron.

[Gość]

[ Sprawa wyjaśniona z supportem - akurat te 559% obciążenia MySQL wynikało z błędu na serwerze... ]

[kursor]

A co powiecie na to?

Że ładny pik.