MajorDoMo

Доброго времени суток!
Повисло время в меню (17-12 вчера) , причем сервер работает, все управляется, например временные данные об изменении свойств пишутся правильные
Периодически падает и восстанавливается основной цикл, перезапуск сервера не помогает
Куда копать?
Папка htdocs\debmes в облаке
https://cloud.mail.ru/public/42Y9DtfsSX ... 1%2017-07/

Похоже, что-то с базой данных. Нужно зайти через phpmyadmin и проверить целостность таблиц.

Сделал... не помогает. Есть еще идеи?
Все таблицы ОК кроме, типа восстановление не поддерживаю.
db_terminal.cached_values repair note The storage engine for the table doesn't support repair

У меня похожая проблема. Несколько раз переустанавливал МДМ, всегда один и тот же результат. Всё работает где то пол дня, потом останавливается время, ещё через какое-то время пропадают элементы меню, затем исчезают объекты и частично пропадают пункты в панели управления. Понятно, что крашится база данных, но вот как найти причину этого?

Отправлено с моего GT-N7100 через Tapatalk

Там при перезапуске включается из cmd проверка таблиц и так... делал через phpmyadmin4, т.е. перезапуск при краше таблиц должен был помочь
Сергей, помогите, срез логов в облаке на нерабочий момент

Дайте в личку доступ к TeamViewer, я попробую посмотреть.

Тоже после обновления. Часы стоят

Забыл сказать, что у меня Ubuntu 14.04

Отправлено с моего GT-N7100 через Tapatalk

lysyy писал(а):Там при перезапуске включается из cmd проверка таблиц и так... делал через phpmyadmin4, т.е. перезапуск при краше таблиц должен был помочь
Сергей, помогите, срез логов в облаке на нерабочий момент

Дело было в огромной таблице phistory_queue -- эта таблица служит для временного хранения истории значений свойств, т.е. получается очередь для записи в основную таблицу истории. Процедура переноса из очереди производится в основном цикле и он падал из-за того что очередь была просто огромной (24 млн записей). Из-за чего такое произошло, мне сложно сказать -- судя по данным там действительно добавлялось десятки значений в секунду. Возможно, настал момент, когда за одну минуту (период переноса данных в очередь) скопилось данных столько, что система не смогла уже держать их в памяти и вошла в ступор -- очередь росла без возможности её обработать. Сейчас я добавил защитный механизм на такой случай, но может быть так же имеет смысл посмотреть динамику роста истории -- мало ли вдруг не нужно так часто сохранять данные для истории.

Это про данный конкретный случай, про другие надо смотреть -- попробуйте проверить насколько большая указанная выше таблица, может быть тоже с этим связано. При нормальной работе там должно быть минимум значений, а зачастую и просто ноль.

Большое спасибо!
Я эту таблицу очищал транкейтом несколько недель назад...

т.е. надо обновиться?
03/10/2016 16:31 Main cycle history queue processing fix (by sergejey

А это не могло быть причиной торможения из-за pChart-графиков? мне пришлось просто убить папку pchart (((
хотя скорее всего графики из phistory строятся..скучно без них)