Проблема с потреблением оперативной памяти



  • 0_1523644417146_upload-a1b4d3cc-5ae4-4206-bcd7-96855c2e4060

    Всем привет. Появилась проблема – идет большая потеря оперативной памяти. Раньше этого не было, недавно переделал скрипт и тут понеслось, очень долго его переделывал и обнаружил вот такую штуку – идет потеря озу… куда-то, и в итоге сильно виснет софт (это могут быть НЕ связанные проблемы, сейчас хочу выяснить только про озу).

    Долго разбирался, искал причины. Решил сделать тестовый мини проект куда я внес кратко те действия которые я добавил в основной скрипт, а именно ассоциативные массивы 2 штуки в поток по 100 объектов длинной по 20-30 символов каждый объект.
    Что имеем – тестовый скрипт в любом виде с циклами и метками жрет память. Раньше этого то ли не было то ли я не замечал. Путем исключения я перебирал разные варианты тестового скрипта, и в итоге - просто скрипт с циклом и одним действием (любым) начинает потреблять озу в некуда.

    Если добавить в цикле больше действий, например, чтение базы и изменение записи в базе + работа с ассоциативным массивом (объекты), то потребление озу идет семимильными шагами (то есть так это более заметно).
    Тестов было много – и с несколькими действиями и с одним действие – итог один озу куда-то уходит, разница лишь в скорости ухода.

    Запустились 300 потоков – потребление озу один раз была сумасшедшим - 1300 мегабайт. Далее все 300 потоков делают одинаковые действия в кратком цикле (например получают текущую дата) и с каждой минутой идет увеличение потребления память.
    Очистить память помогает немного перезапуск потока НО память чистится не сразу. Например если я останавливаю скрипт который потребляет 8гб озу, то вся память которая чем-то непонятным занята очистится примерно через 4 минуты.
    Это происходит как на моем ПК с win 10 которая регулярно обновляется, так и с vds под win serv 2012 R2 который никогда не обновляется и антивируса там нет. Но на сервере с основным скриптом чистка срабатывает не всегда почему-то.
    . . .
    Позже после всех этих тестов я решил что наверное придется смириться и все так и должно работать. Решил что попробую запустить свой софт в 3 раза меньше потоков и сделать частый перезапуск потоков что бы как-то освободить озу, но результат плохой.
    По инспектору переменных скрипт содержит: 1 переменную с куками, 2 ассоциативных массива по 100-200 объектов, 1 переменная SAVED_CONTENT куда приходят ответы от get запросов достаточно тяжелая переменная в json но раннее скрипт работал с такими же ответами и все было ок, 50 пустых переменных и еще 20 со всякой небольшой инфой (типа ФИО, id, дата). Node js нет. Ах да, и самое важное – браузер либо не используется, либо 1 раз присутствует в скрипте для получения куки после чего закрывается.
    . . .
    Вопрос – у кого-то еще такое происходит? Это норма?
    проект 0_1523662669641_test bd.xml
    записи из базы 0_1523645261846_test db.csv
    текстовый файл 0_1523645290198_вв.txt

    Минимальный скрипт
    https://drive.google.com/file/d/1Keilcjmw3iznnzHdTx26c5OMW-dOTgUV/view?usp=sharing
    Пример с базой
    https://drive.google.com/file/d/1a1LA1iCekIRtjLRRuJ8FbXcYWYsGLWC2/view?usp=sharing
    Пример с базой и файлом
    https://drive.google.com/file/d/14_gPyGltTdvNXCxIZy22uQrq3_8BZd7n/view?usp=sharing
    Пример с перезапуском потоков. Можно видеть как один раз после завершения первых 300 потоков один раз память очистится
    https://drive.google.com/file/d/1-IGB9IWASqqYtzo6i6u3G1onQKMLGOhy/view?usp=sharing

    Все же решил записать еще и с массивом из объектов.
    https://drive.google.com/file/d/1DHBA6hqDWKM9Q-HDZRqoYwig90DGsrcy/view?usp=sharing
    И с циклами в котором происходит создание массива каждый раз и удаление его же. Разницы нет в целом.
    https://drive.google.com/file/d/11ePgsFoQkhzgV_ufoqA8D7PYavRf8TcP/view?usp=sharing

    0_1523644461570_upload-4f3b8998-e751-4207-a28e-dfb28ca0f1b1
    0_1523644487426_upload-f66b0fb8-7ffa-4c54-8b54-cf40f95079ae
    0_1523644500462_upload-69b88ebc-5b0f-4744-9300-9eb405f6f291



  • @venom777, ну да, у меня тоже 7-9 гигов оперативы обычно отжирает скрипт. И после часов 5и работы уже нет смысла пытаться его завершить штатно, чтобы память очистилась. Проще и раз в 50 быстрее сделать ребут машины. Но у меня там потоки не перезапускаются вообще, а только по очереди уходят в сон. И их 1000 запущено. Одновременно максимум 70 работает. Браузер открывается-закрывается и чистит после себя все данные. Это не помогает особо. И поведение такое минимум с ноября.



  • у меня есть сервак 32 гб оперативы и памяти вообще не жрет даже 10% иногда не съёдает при забитом 100% 8 ядерном процессоре, хотя на браузере и есть также циклы,

    есть еще один комп домашний 1гб всего оперативы и 1 ядро вроде, так у меня работает день и ночь, сложный скрипт а потребление оперативы выше 900 не поднимается!



  • @CaptchaLom, а потоков сколько?
    @venom777, такой же вопрос - сколько потоков?



  • @Antonio обычно работал в 300 потоков, теперь и со 150 потоками беда появилась, раньше проблем не знал и запускал две копии по 300 потоков каждая, уже планировал брать сервак 16-32гб что бы увеличить потоки до нескольких тысяч т.к. нашел решения минимизировать нагрузку на проц

    сейчас раздобуду версию младше 20.7.6 (менял винду недавно) и попробую там скомпилировать проект

    @CaptchaLom у тебя на какой версии баса скрипт работает?



  • @venom777, а раньше - это когда? На каких версиях?
    а несколько тысяч так и так нормально работать не будет. Уже сто раз тут обсуждалось, что лучше на серваке таком поднять несколько виртуалок и запускать несколько скриптов с меньшим количеством потоков.



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

    upd Проверил 20.8.7, 20.7.4, 20.6.4, 20.7.6 - результат на тестовом скрипте одинаковый.
    Важно - тестовой скрипт и основной скрипт это две разные проблемы, сейчас хочу понять нормально ли такое потребление оперативной памяти на простом проекте, а потом уже пойму и сделаю выводы по основному скрипту.

    upd 2
    Все еще продолжаю тестировать...
    Новая партия тестов.

    Пробовал проекты с просто открытым браузером и затем с загруженной страницей - отличий нет (хотя когда загрузил 300 вкладок bablosoft.com то воркеры потребляли изначально 37mb затем во время работы циклов стали потреблять >40, процесс баса так же рос).

    Разницы между: исп. ресурса файла, исп. ресурса базы или не использовании ресурсов - разницы нет. Только более заметно потребление памяти и не более. Если запускать менее чем в сотни потоков, то рост потребления оперативы будет сложно заметить т.к. это будет сотня байт на поток в 30 секунд, наверное и нужно будет ждать часов 5 что бы увидеть потребление.

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

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



  • Минимальный скрипт
    https://drive.google.com/file/d/1Keilcjmw3iznnzHdTx26c5OMW-dOTgUV/view?usp=sharing

    Я не знаю, как работает выделение памяти в js движке, который юзает БАС, но уверен, что оно далеко от того, чтобы просто выделять ее когда создается новая переменная, или освобождать ее, когда она перестает использоваться. Скорее всего там используются пулы или что-то подобное. На видео меньше минуты и это не показатель. Я делаю так - ставлю скрипт на день и смотрю как изменяется набор памяти. Если он монотонно растет, то можно говорить об утечке.
    Сейчас поставил бесконечный цикл с одним действием внутри - сон. Вечером посмотрю что будет.
    Если это действительно утечка, тогда обязательно исправлю.



  • This post is deleted!


  • @venom777 Да, подтверждаю проблему. Сегодня-завтра решу.



  • @aveko Вам нужно запустить профайлер и проверить, что занимает больше всего процессорного времени.
    И создайте, пожалуйста, другую тему.



  • @support Если вы не будете пересматривать весь форум, то хочу обратить внимание на еще одну мою тему где похоже найден баг с node js.



  • @venom777 Нашел 1 утечку памяти и 3 места, где она освобождается несвоевременно.
    В одном случае была моя ошибка, в 3 других ошибка используемых библиотек.
    В каждом случае было найдено решение.
    Одна из утечек была связана с анимацией в трее, поэтому пока ее отключил.

    Тестировал на 2 ваших скриптах и на бесконечном цикле со сном.
    В одном из тестов оставлял скрипт на 12 часов. На протяжении больше 10 часов количество выделенной памяти вообще не менялось, поэтому отключил.
    Если в потоке был бесконечный цикл, то в какой-то момент набор памяти переставал увеличиваться(примерно через 10-15 минут после запуска).
    Если потоки перезапускались, то набор то увеличивался, то уменьшался, но в пределах, которые сами не менялись. Например, SiteVisitor запущенный в 30 поток колебался от 113 до 118 мб.

    Баг критический, поэтому выпустил новую версию 20.9.2.



  • @venom777 said in Проблема с потреблением оперативной памяти:

    @support Если вы не будете пересматривать весь форум, то хочу обратить внимание на еще одну мою тему где похоже найден баг с node js.

    Я постараюсь посмотреть на все темы, но предпочтение буду отдавать тем, которые хорошо оформлены, имеют проект и детальное описание.


Log in to reply
 

  • 7
  • 6
  • 14
  • 4
  • 1
  • 3
  • 2
  • 2