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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ps aux --sort:rss | less

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