1. вот первая может быть  .. я так понимаю всякие там crm через ami Общаются с телефонией

Обычно через AMI. В выводе "manager show connected" можно посмотреть пользователя, под которым выполняется подключение, далее глянуть в manager.conf его права. Если у пользователя много привилегий на чтение, причина проблемы может быть в этом (dialplan, call и reporting - самые грузовые привилегии в плане количества событий).

Проблема также может быть вызвана потерей пакетов при передаче AMI-событий (через интернет желательно не делать AMI-подключения).

ну вот .. плагин к crm  работает через интернет

Можно попробовать временно отключить и проверить, пропадёт ли проблема.

вот отключил..

смотрю

спасибо.  кажется дело именно в этом

как думаете  выделение большего количество ресуросов АТС Решит проблему ..или все таки это связано с медленным обменом

и вот еще

таких подключение amocrm около 100 это воообще норм7?

Если при возникновении проблемы ни одно ядро CPU не упирается в 100%, выделение дополнительных ресурсов не поможет.
Нужно постараться минимизировать количество отправляемых AMI-событий - снизить количество привилегий на чтение, и/или убрать ненужные события с помощью параметров eventfilter.

можно как то выставить ограничение на количество AMI подключений ?

authlimit=
в manager.conf

Может там подойдёт развертка AMI прокси?

Если это виджет AsteriskNew - надо в файле amocrm.php (он, скорее всего, будет где-то в /var/www/html) поставить AC_PORT 5038 и закомментировать AC_PREFIX
define('AC_PORT',5038);
#define('AC_PREFIX','/asterisk/');

После этого скрипт будет подключаться напрямую к AMI, а не через AJAM. Так он будет меньше грузить Asterisk и AMI-соединений от него станет гораздо меньше.

Да, в этом файле.

Огромное спасибо !

Только сейчас дошли руки до вебинара. Спасибо, уже 2 года являюсь вашим пассажиром, от качества работы вашей ТП очень доволен, звоню туда редко, но каждый раз ощущение что они моего звонка ждали с нетерпением. Дорогого наверное стоило такую систему построить