Тема: Медленный монитор событий
Добрый день. Пытаемся решить проблему медленного обновления монитора событий в удаленных офисах. В том офисе, в котором стоит ПК с базой все хорошо - данные обновляются на экране у вахтера почти моментально. Но в офисе который связан с ним VPN каналом с зарержкой в районе 100мс данные обновляются через пару минут после того, как человек уже прошел через проходную. Как я понимаю проблем может быть две - канал связи и загрузка центральной базы.
В ходе мониторинга perfomance лога ПК с базой, обнаружил, что время от времени комп загружается на 50-60%, в этот период в мониторе сессий MySQL я вижу выполнение запроса вида:
DELETE FROM arch_events WHERE code = 2 and ((pkey_controller = 28 and controller_channel = 0) or pkey_door = 89)
выполняющегося от компа к которому подцеплены контроллеры в удаленном офисе.
Версия ПО: 7.0.3
Версия железа - SCM-RS и SCM-NET2 (в удаленном офисе)
SMDR - в локальном офисе (в котором все ок)
Соответственно хотелось бы понять почему такой запрос сильно грузит базу и можно ли как то повысить отзывчивость монитора событий в удаленном офисе?
Пришлите резервную копию БД на почту smdr@dipmail.ru, смоделируем ситуацию.
И опишите параметры сервера (ОС, процессор и т.д.), где установлена БД.
К сожалению не могу этого сделать - сами понимаете, высылать базу с данными всех сотрудников компании мягко говоря небезопасно.
Параметры сервера: CPU E2140, 2Gb RAM, Win 2008 Std, SP2.
Добрый день. Пытаемся решить проблему медленного обновления монитора событий в удаленных офисах. В том офисе, в котором стоит ПК с базой все хорошо - данные обновляются на экране у вахтера почти моментально. Но в офисе который связан с ним VPN каналом с зарержкой в районе 100мс данные обновляются через пару минут после того, как человек уже прошел через проходную. Как я понимаю проблем может быть две - канал связи и загрузка центральной базы.
Поясните, это карточку приложили и через пару минут событие отобразилось в удаленном мониторе событий или просто у контроллера и удаленного монитора событий разница во времени в пару минут и соответственно оператор считает, что событие запаздывает на пару минут?
Да, именно человек прикладывает карту и только через две минуты отображается в мониторе.
Время на компьютерах совпадает?
Возвращаясь к этой проблеме:
Время на компьютерах совпадает. В логах заметил, что контроллер пишет в базу по 50-70 одинаковых событий.
17.07.2013 5:54:59 Office8_Belgrade_F1_* Датчик открывания разомкнут на выходе
17.07.2013 5:54:59 Office8_Belgrade_F1_* Датчик открывания разомкнут на выходе
17.07.2013 5:54:59 Office8_Belgrade_F1_* Датчик открывания разомкнут на выходе
17.07.2013 5:54:59 Office8_Belgrade_F1_* Датчик открывания разомкнут на выходе
17.07.2013 5:54:59 Office8_Belgrade_F1_* Датчик открывания разомкнут на выходе
17.07.2013 5:54:59 Office8_Belgrade_F1_* Датчик открывания разомкнут на выходе
17.07.2013 5:54:59 Office8_Belgrade_F1_* Датчик открывания разомкнут на выходе
То же самое про вход-выход сотрудников. О чем может говорить такое поведение?
Параллельно замку не стоит диод или неправильно подключено питание замка.
“-” замка должен быть на той же клемме, что и “-” блока питания, как на схеме подключения. После устранения сделать “сброс событий”(SCM-NET2) или “программирование”(SCM-RS) на проблемной точке доступа.
Спасибо, проверим. Подскажите пожалуйста еще по такому случаю : контроллер NET2
01.01.2070 Office8_Belgrade_F1_TDA 081-00529 / 8501000000510211 / 5308945 8501000000510211 Сброс разблокировки картой ()
01.01.2070 1:12:34 Office8_Belgrade_F1_ 031-61009 / FE010000001FEE51 / 2092625 FE010000001FEE51 Вход
01.01.2070 1:12:34 Office8_Belgrade_F1_ 176-61265 / 0001000000B0EF51 / 1595601 0001000000B0EF51 Вход
01.01.2070 1:12:34 Office8_Belgrade_F1_ 207-61265 / 3201000000CFEF51 / 3627217 3201000000CFEF51 Вход
01.01.2070 1:16:50 Office8_Belgrade_F1_ 232-61265 / C401000000E8EF51 / 5265617 C401000000E8EF51 Вход
01.01.2070 1:16:50 Office8_Belgrade_F1_ 181-61265 / 8101000000B5EF51 / 1923281 8101000000B5EF51 Вход
16.01.2079 19:58:37 Office8_Belgrade_F1_ 000-25486 / 9B0100000000638E / 0025486 9B0100000000638E Вход
При этом в памяти постоянно события, репрограммирование/резет событий не помогают. События он передает вне зависимости есть или нет реальная активность персонала. Дверь при этом открывает нормально.
Вчера удалил миллион событий за 2070 год из базы уже.
Сброс событий не удаляет события из базы, а лишь сбрасывает мусор из памяти событий контроллера, вызванный сбоем по питанию. сбой по питанию происходит в момент каждого открывания двери, если неправильно подключен замок. Можете временно отключить замок, сделать сброс событий, посмотреть будет ли эффект, а уже потом разобраться с замком.
У нас сейчас 2800000 событий, это данные за 3 месяца. Скорость приемлемая. Несколько дней назад было больше 6000000, и перевод одного сотрудника например по департаментам или добавление карточки занимало от 10 минут до бесконечности. Железо 4Гб памяти и двухядерный пентиум 1,6.
Сейчас пытаемся разобраться с контроллером который все заспамил, настораживает, что это не единичный случай.
Железо 4Гб памяти и двухядерный пентиум 1,6.
Слабовато для таких объемов данных, и по современным меркам. Хотя бы i5, не менее 2,5, у него там авторазгон до 3,1, есть недорогие AMD FX 3,8 в ту же цену, и 8Г оперативки. SSD диск с базой тоже будет не лишним, не обязательно, но просто диск современный.
Сделайте сброс событий при отключенном замке. В статистике событий должно показать 0 после этого.
Еще вопрос по таблице arch_events, если мы включим индексацию поля datetime_mysql для ускорения работы скрипта, который перекачивает данные в стороннюю систему, какие возможные негативные последствия это принесет?
Навскидку видится:
1) Замедление записи новых данных от контроллеров (сильное ли?)
2) Необходимость включать индексацию при переходе на новую версию коменданта.
Еще вопрос по таблице arch_events, если мы включим индексацию поля datetime_mysql для ускорения работы скрипта, который перекачивает данные в стороннюю систему, какие возможные негативные последствия это принесет?
Навскидку видится:
1) Замедление записи новых данных от контроллеров (сильное ли?)
2) Необходимость включать индексацию при переходе на новую версию коменданта.
1) Да, конечно это повлияет на скорость записи в БД, но это не критично.
2) Нет, после обновления структуры БД не надо будет включать индексацию заново, т.к. при обновлении индексы не удаляются.
Спасибо большое за консультацию - сегодня включили индексацию, чем ускорили выполнение скрипта в 247 раз 😊
Обновите прошивку у контроллера и проверьте его работоспособность. Возможно поможет.
Прошивка приложена.
SCM-RS2_NET2-7_3-1_152740_16092013.zip (Размер: 10KB - Загрузки: 166)