Пожалуйста, войдите здесь. Часто задаваемые вопросы О нас
Задайте Ваш вопрос

Утечка памяти

0

Всем доброго утра/дня/вечера/ночи! Давно я не видел утечек памяти в астериске, но тут внезапно появилась такая проблема. И так имеем следующее: 1) FreePBX 2) Кучка кастома для увязки с MSSQL 2012 (ODBC и FreeTDS) и своими скриптами 3) Патченный астер 11.16.0 (Патч https://issues.asterisk.org/jira/browse/ASTERISK-13145) для правильной работы с телефонами Cisco CP-99XX 4) CentOS 6.5 x64 5) Сервер виртуальный на ESXi 5.5, для астера 24 ядра и 12 Гигов оперативки. Выставлен наивысший приоритет на ресурсы. На всем этом память начинает утекать бешеными темпами. Причем не вылетает, дико свопится, начинает тормозить, но в таком состоянии может работать долго (начинается пропадание голоса, заикание). Вопрос, в чем может быть проблема? В патче (код был бегло просмотрен и ничего подозрительно в нем не увидел) или же в самом астере? Прошу помощи у сообщества, уже не знаю что делать.

удалить закрыть спам изменить тег редактировать

спросил 2015-03-23 15:49:11 +0400

Filin Gravatar Filin
9 8 1 5

Comments

не подумали просто разделить на несколько серверов и не валить всё в кучу?

Zavr2008 ( 2015-03-23 17:23:59 +0400 )редактировать

не php ли виновато ? а вообще выкидывайте лишние модули и пробуйте связку без патча

awsswa ( 2015-03-23 20:11:38 +0400 )редактировать

Здесь неплохо было бы вспомнить, после каких действий появились проблемы.

bolshoy_plohish ( 2015-03-24 06:03:19 +0400 )редактировать

Разделить на несколько серверов мысль уже приходила, вот только это очень сильно усложнит и без того не простую схему работы. Телефоны CP-99XX находятся вперемешку с SPA-514g и именно для них накладывался патч, ибо астер из коробки не понимает xml структуру sip от этих телефонов. Лишние модули уже все отключил. На счет кривых php скриптов мысль была, пару раз ошибка была в них, тогда встает вопрос, насколько правильно будет переписывать скрипты от FreePBX? Проблемы начались в самом начале поэтому точки отсчета нет.

Filin ( 2015-03-24 08:00:59 +0400 )редактировать

offtopic. А для скольких абонентов/одновременных разговоров такой монстр?

yks ( 2015-03-24 10:28:54 +0400 )редактировать

около 240, ядер много что бы наверняка процессорного времени хватало и на все ядра процессора был наивысший приоритет.

Filin ( 2015-03-24 11:21:15 +0400 )редактировать

Хмммм... 240 разговоров это не так много, такого железа должно хватать за глаза, даже с излишком, у меня в гораздо более скромной конфе до 500, но там только транзит и рулежка по транкам на обычных текстовых конфигах, значит сам Астер ни при чем. Наиболее вероятная причина - пхп и кривые выборки из скуля.

CheeZ ( 2015-03-24 12:43:21 +0400 )редактировать

Пару раз был краш из-за freetds в результате не отработанного запроса, но запросы тривиальны, ничего сверх большого в них нет. Сейчас заметил, при каждом 'core reload' астер отжирает 0,3% от оперативки.

Filin ( 2015-03-24 13:11:02 +0400 )редактировать

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

CheeZ ( 2015-03-24 13:23:11 +0400 )редактировать

чтото вы ерунду какуюто рассказываете. тоесть у вас каждый релоад ест 0.3% от 12Гб мб или 36мбайт оперативки? может у вас есть какието сверхдлинные скрипты на h-exten?

meral ( 2015-03-24 16:35:52 +0400 )редактировать

meral, именно с каждым релоадом улетает по 0.3%, ну и плюс во время обычной работы, объемы утечки во время звонка сказать не могу, но в целом за неделю все 12 гигов и пару гигов свопа улетает. 2 CheeZ, базы не такие большие, в них хранятся данные о городском номере, мобильном (уже не используется), о транках, CID, email, ФИО, группы вызова, ivr. Все перечисленное лежит по разным таблицам и в каждой таблице не более 700 записей, в итоге при одном запросе данных прилетает копейки, даже если брать всю таблицу целиком. Если предположить что проблема в запросах, не должны ли данные после его отработки выгружаться из ОЗУ? Или же я чего то не докурил?

Filin ( 2015-03-25 12:31:13 +0400 )редактировать

Вопрос не в том сколько прилетает в ответ, вопрос сколько перебирается, с этим еще разбираться нужно - простой запрос еще не значит что это оптимальный по расходу памяти и производительности запрос - это раз, и тут товарищ вам еще правильно подсказывает проверить закрытие соеденений.

CheeZ ( 2015-03-25 15:42:54 +0400 )редактировать

h-exten проверил по всем кастомным файлам ничего не заметил, используется только в одном месте. Все запросы идут через func_odbc, скриптов на текущий момент не используется (если не считать стандартных из freepbx).

Filin ( 2015-03-25 17:06:30 +0400 )редактировать

Смотрел кто ест?

ps aux --sort:rss | less

bolshoy_plohish ( 2015-03-25 18:29:57 +0400 )редактировать
1

да астериск у него ест) он же написал. вообще не вижу проблемы если он локализована(появляется при каждом релоаде). наймите експерта по c/c++ он вам найдет утечку за день. стоить это будет около 1к долларов. других вариантов не вижу.

meral ( 2015-03-25 19:25:31 +0400 )редактировать

Будьте первым, кто ответит на этот вопрос!

Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
[скрыть предварительный просмотр]

Закладки и информация

Добавить закладку

подписаться на rss ленту новостей

Статистика

Задан: 2015-03-23 15:49:11 +0400

Просмотрен: 469 раз

Обновлен: Mar 25 '15

Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией GNU GPL.