Здравствуйте. После обновления на 3.66 журнал сервера стал занимать очень много места. Не смотрел, сколько он занимал места на предыдущей версии, но именно после перехода на 3.66 стали появляться ошибки:
"Отсутствуют разрешения на запись в папку /var/LERS. Возможно, часть функций системы будет недоступна. No space left on device : ‘/var/LERS/f0a1bd7e-f724-4ce0-9545-5a59047d47ce’
20 мая была ещё версия 3.65.3, на 3.66.1 перешли 21го мая, 27го поставили 3.66.3. Журнал за 22 и 23 мая был удален так же из-за большого размера. Странно, что 24 мая журнал занимает мало места
В версии 3 66.1 была ошибка обработки подключения/отключения GPRS-модемов. Возможно она приводила к некорректному завершению сеансов опроса, тогда как в текущей версии происходит массовая обработка их завершения, что вызывает рост занимаемого журналом работы Сервера места ввиду множества сообщений о завершении.
Проверьте выборочно сеансы опроса какое подключение в них используется. Если во всех случаях это GPRS, то судя по всему проблема именно в этом и через какое то время после обработки всех сеансов она уйдет сама собой.
Да, все сеансы gprs. Но проблема сохраняется. Когда запись в журнал доходит до последних сеансов за текущий день, сразу начинается запись логов по сеансам за 21.05.2026
Часть журнала за сегодня, на котором видно переход к старым сеансам прикладываю
Он заканчивается на 2026-06-01 10:31:42.5955 т.к. дальше закончилось место. В распакованном виде занимает почти 35Гб. Но по нему видно, что цикл записи логов повторяется каждые 2 секунды
Бэкап БД смогу предоставить позже, т.к. на сколько помню у Вас не получалось развернуть всю нашу копию у себя из-за большого количества данных, нужно его ещё сжать
Просмотрели журнал работы Сервера. В целом массовый вывод данных сообщений не позволяет как либо провести анализ.
Попробуйте перезапустить Сервер и Службу опроса. Проверьте сохранится ли ситуация после этого.
Если ситуация сохранится, то ожидаем ранее запрошенную резервную копию БД. Либо, как вариант, вы можете развернуть отдельно копию вашей БД у себя, и предоставить нам параметры доступа к СУБД с данной копией БД.
Ссылку на копию БД отправил в личные сообщения. Но там все данные, без сжатия. Попробуйте развернуть у себя. В прошлый раз удаление старых данных занимало несколько дней, что требовало временной лицензии, т.к. основной сервер нужен был для работы. Разворачивание копии у себя так же потребует временной лицензии, чтобы оба сервера работали параллельно
Мы попробуем конечно развернуть ее у себя, но это скорее всего завершиться тем же результатом, как в предыдущий раз, так как тестовые машины несколько слабее промышленного Сервера, на котором, как я предполагаю, развернута ваша БД.
Нет, если вы развернете только копию вашей БД у себя в СУБД и предоставите нам параметры подключения к данной БД, то отдельной лицензии для вас это не потребует, так как мы будем подключаться своим Сервером.
Вновь возникают проблемы, аналогичные тем, что возникали в прошлый раз. По завершении распаковки резервной копии архиватор выдает ошибку “Ошибка CRC - Неверный пароль?”. Не совсем понятно что означает знак вопроса в конце сообщения. Возможно это неверное отображение какого то символа, возможно обозначение предположения…
Проверьте, пожалуйста, верно ли указан переданный пароль.
Теперь при распаковке архиватор выдает просто “Ошибка CRC”.
Попробуйте не упаковывать архив резервной копии в zip с разбивкой на части, а просто разбейте сам файл резервной копии на несколько частей, упомянув используемую для разбивки программу. Можно даже попробовать загрузить на файловый хостинг целый файл резервной копии без разбивки на части.
Яндекс диск не дает загружать файлы больше 1гб, пришлось разбивать архиватором. Загрузил на google диск копию бд, без пароля и без разбивки на части, ссылку отправил в ЛС
Вроде бы удалось развернуть приложенную резервную копию. Но при этом возникали ошибки в выполнении команд restrict и unrestrict из дампа. Вроде бы это не критично, так как данные команды используются для задействования и отключения ограниченного режима, но так как база создавалась из этой резервной копии и на нее никто не был настроен, то их применение какой либо роли думаю не играет.
На всякий случай перезапустили заново восстановление резервной копии. Процесс не быстрый, предыдущий занял примерно 5-6 часов.
Мы запустили Сервер, но описанных ошибок при не возникает, во всяком случае с момента запуска их пока не возникло ни одной. Не знаю как долго стоит ожидать воспроизведения ситуации. Просто у нас некоторые точки опрашиваются и это может вызвать проблемы с их опросом у вас. Ранее я писал:
Уточните, пожалуйста, выполняли ли вы данную проверку и, если да, то через какое время после выполнения перезапуска ситуация начала воспроизводится вновь?
Да, это действие было проведено. Но в момент перезапуска сервера и служб опроса на диске не было места для записи логов. Примерно через 10 минут после перезапуска очистили место и сразу логи стали так же циклично записываться на диск
У нас так и не воспроизводится ситуация на присланной копии БД. Проверили таблицу базы “PollSession” с сеансами опроса. В ней нет сеансов с идентификаторами ранее текущей даты. Я остановлю наш тестовый Сервер, так как дальше ожидать воспроизведение ситуации нет смысла.
Попробуйте остановить Сервер, удалить самый ранний журнал работы Сервер, чтобы освободить место, после чего запустите Сервер. Если ситуация все равно продолжит возникать, проверьте в таблице “PollSession” наличие сеансов опроса с идентификаторами, которые будут фигурировать в рассматриваемых сообщениях после запуска Сервера.
