приложен диагностический архив, доступен только сотрудникам поддержки
(2,6 МБ)
Добрый день. Раньше сильно не обращал внимание на рост используемой оперативной памяти. После перезагрузки контроллер потребляет 350-400 мб, и в итоге после почти 14 дней аптайма оперативная память загружена на 1200+ мб. После перезагрузки контроллера опять начинается с 350+ мб и продолжает линейно расти. Никаких сторонних программ не установлено, только штатные .Единственно прокинут мост MQTT с параметром “+/# both”, но так было с самого
запуска контроллера. Контроллер 8.5, последнее stable обновление wb2606. Проблем в работе с контроллером нет никаких, но что будет с памятью когда контроллер отработает например 6 месяцев без перезагрузки. Раньше точно так не росла оперативная память. Это нормальная ситуация?
Ну это на сейчас после перезагрузки контроллера вчера. На скрине который приложил, видно что используемая оперативная память дошла до 1200+ мб, После чего я перезагрузил контроллер и оперативная память стартанула с 350+ мб и растет вверх, после нескольких дней посмотрим. Это нормальное поведение?
Добрый день. Прошло 3d 17h с момента загрузки контроллера. Использование оперативной памяти увеличилось почти в два раза, после рестарта контроллер потреблял 330 мб оперативной памяти, сейчас 630 мб. Контроллер практически не нагружен. Из нештатного подключены к брокеру MQTT несколько клиентов и один мост с параметром “+/# both”. График показывает что стабильно идет рост
приложен диагностический архив, доступен только сотрудникам поддержки
(2,4 МБ)
потребления оперативной памяти. Как я понял потребляет оперативку 127 процесс /lib/systemd/systemd-journald
Это нормальная ситуация? Или смотрим дальше?
Я не понял что Вы имели ввиду, поясните пожалуйста.
Я сужу по контролу metrics/ram_used и из команды free -h used Mem: Значение увеличивается линейно. Из этого я делаю вывод что загрузка оперативной памяти постоянно растет вверх и не падает.
Тут надо точно делить - ожидается ли увеличение. Если да - то чем оно обусловено. То есть просто “использование” - ни о чем, в общем, не говорит, ну отдано часть под кэш - и хорошо.
Объясните пожалуйста на пальцах. Допустим через пару месяцев после старта контроллера контрол показывает загрузку ОЗУ на 2 гб, хотя при старте я знаю что он потреблял 330 мб ОЗУ. Как мне понять что ОЗУ забилась кэшем или это какой-то сервис контроллера начал поджирать ОЗУ? Что из чего надо вычесть, что бы получить данные по реальной загрузке ОЗУ сервисами и приложениями?
Вопросы:
Сколько будет набираться кэш в ОЗУ?
Есть какие то ограничения по кэшированию?
Можно это изменить/отключить? Ведь с началом изучения контроллера, я точно помню что контрол “исп. ОЗУ” точно показывал график похожий на реальную загрузку ОЗУ.
Жёсткого лимита у page cache нет. Ядро отдаёт под кэш всю свободную RAM и освобождает её мгновенно, как только память нужна приложениям. Поэтому «размер кэша» ограничен не настройкой, а тем, сколько физической памяти в данный момент не занято под что-то более приоритетное.
Управлять размером - да, можно. Но для чего? Я не так долго использую libux, но до сих пор подобное нужно не было.
А не используется ли **Timer и прочее в скриптах? С весны, примерно, нашёлся баг в таймерах и до сих пор не отмечен решённым - замените все Timer функции на setTimeout/setInterval для проверки
Получается моя ситуация штатная? Контрол metrics/ram_used получается не несет нужной информации и показывает какие условные цифры не имеющие отношение к текущей загрузке? Странно конечно. Планировал в будущих проектах на WB выводить на HMI два важных параметра (CPU и RAM) для оперативного мониторинга состояния контроллера. Если Вы считаете что моя ситуация штатная, то закрывайте тему. Спасибо.
А в реале вижу какие то непонятные цифры стремящиеся в бесконечность. И как мне среди этих цифр отделить мух от котлет (реальное потребление сервисами и кэш) мне не понятно. И еще раз повторюсь,раньше такой линейный рост оперативной памяти не наблюдался.
Для информации, вдруг окажется что не штатная работа.
В htop увидел закономерность потребление оперативки сервисом wb-mqtt-opcua
После ввода команды systemctl restart wb-mqtt-opcua график использованной оперативки стал такой
