はじめに
このドキュメントでは、SIPトランクを追加できない場合にCUCMで表示されるエラーメッセージ「Memory allocation failed during query processing(クエリ処理中にメモリ割り当てが失敗しました)」のトラブルシューティング方法について説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- VOS(音声オペレーティングシステム)
- CUCM(Cisco Unified Communications Manager)。
- SIP(セッションインターフェイスプロトコル)。
- Informixデータベース
- CLI(コマンドラインインターフェイス)。
使用するコンポーネント
このドキュメントはCUCMを対象としており、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
背景説明
CUCMサーバにSIPトランクを追加すると、図に示すエラーが表示されることがあります。
問題を再現する前に、次の手順を実行します。
ステップ 1:すべてのCUCMノードでログを詳細レベルに設定します
- CMトレース
- DBレイヤモニタ
- CCMAdmin Webサービス
- CCMUser Webサービス
注:一部のトレースはすでに詳細レベルに設定されていることに注意してください。この設定は、インストールしたCUCMのバージョンによって異なります。
ステップ 2:問題を再現します。SIPトランクを追加し、タスクの実行に失敗した時間をマークダウンします
トラブルシュート
RTMT(Real-Time Monitor Tool)に移動して、次のトレースを取得します。
- CMトレース
- DBレイヤモニタ
- CCMAdmin Webサービス
- CCMUser Webサービス
– イベントビューアアプリケーションログ
– イベントビューアのシステムログ
ログ分析
CCMAdmin Web Serviceログから
SIPトランクがデータベースに挿入されます
2024-03-14 09:51:12,487 DEBUG [http-nio-1027-exec-7] formhandlers.TrunkFormHandler - Insert Trunk
2024-03-14 09:51:12,570 DEBUG [http-nio-1027-exec-7] utilities.DbRead - reading from cache...
2024-03-14 09:51:12,573 DEBUG [http-nio-1027-exec-7] utilities.DbRead - reading from cache...
SIPトランクデバイスが一意のIDで更新されます
2024-03-14 09:51:12,590 DEBUG [http-nio-1027-exec-7] formhandlers.TrunkFormHandler - Updating SIP - devicePkid = e277a39a-1437-84ba-5047-57adddc75a43
...
The SP Trunk starts to be configured within the database
2024-03-14 09:51:12,618 DEBUG [http-nio-1027-exec-7] formhandlers.Device - update initiated
2024-03-14 09:51:12,620 DEBUG [http-nio-1027-exec-7] formhandlers.Device - Insert/update device
...
2024-03-14 09:51:13,449 DEBUG [http-nio-1027-exec-7] utilities.DbRelatedUtil - 1 row(s) affected.
...
2024-03-14 09:51:13,910 DEBUG [http-nio-1027-exec-7] utilities.DbRelatedUtil - 1 row(s) affected.
2024-03-14 09:51:13,913 INFO [http-nio-1027-exec-7] utilities.SIPDeviceUtil - Entering checkSecurityProfilePortDuplicates
...
デバイスの挿入が失敗し、コンフィギュレーションのロールバックが開始されます
2024-03-14 09:51:14,294 ERROR [http-nio-1027-exec-7] formhandlers.Device - insert/update failed. Rollback changes
ハンドル例外がデータベースによってスローされました
2024-03-14 09:51:14,338 ERROR [http-nio-1027-exec-7] formhandlers.TrunkFormHandler - Exception: Memory allocation failed during query processing.
java.sql.SQLException: Memory allocation failed during query processing.
2024-03-14 09:51:14,360 INFO [http-nio-1027-exec-7] actions.BaseAction - SQLException :: -208::java.sql.SQLException: Memory allocation failed during query processing.
2024-03-14 09:51:14,363 DEBUG [http-nio-1027-exec-7] actions.BaseAction - Db Error :: Memory allocation failed during query processing.
2024-03-14 09:51:14,365 DEBUG [http-nio-1027-exec-7] actions.BaseAction - Error could not be mapped using zero :: Memory allocation failed during query processing.
java.lang.NumberFormatException: For input string: "Memory allocation failed during query processing."
2024-03-14 09:51:14,370 DEBUG [http-nio-1027-exec-7] actions.BaseAction - Error Code :: 0
2024-03-14 09:51:14,410 DEBUG [http-nio-1027-exec-7] actions.BaseAction - DBE Error code was not set :: java.sql.SQLException: Memory allocation failed during query processing.
2024-03-14 09:51:14,412 DEBUG [http-nio-1027-exec-7] actions.BaseAction - Parsing Database Specific Error :: java.sql.SQLException: Memory allocation failed during query processing. :: error.add
2024-03-14 09:51:14,414 ERROR [http-nio-1027-exec-7] actions.BaseAction - Caller Specified DatabaseException [error.add] :: java.sql.SQLException: Memory allocation failed during query processing.
CCM Informixログで、これらのエラーのいくつかを確認できます
ERROR Estimate FAILED for table 'ccm12_5_1_16900_48:"informix".
NTPエラーが発生する場合は、特定のシナリオがあります
Mar 14 09:51:23 FXSDCWCMFPUB user 4 platform: Response from 'ntpdate -q': server X.X.X.X, stratum 0, offset 0.000000, delay 0.00000#01214 Mar 09:51:23 ntpdate[8646]: no server suitable for synchronization found.
解決方法
警告:メモリ割り当てをクリアするには、一覧に表示されているサービスを再起動すると音声システムのパフォーマンスに影響を与える可能性があるため、営業時間外にサービスを再起動する必要があります。
注:このプロセスは、CUCMパブリッシャノードでのみ実行する必要があります。
ステップ 1:CLIを使用してCisco Tomcatサービス(utils service restart Cisco Tomcat)を再起動します。
Cisco Tomcatの再起動は、サービスがダウンしている間は、Extension Mobility、セルフケアポータル、CUCM GUI、およびユーザのログインなどの機能にアクセスできないことを意味します。
サービスの再起動後、GUIが使用可能になるまでに約5分かかります。このため、404 Not Foundエラーが発生することが予想されます。
ステップ 2:CUCMにSIPトランクデバイスを追加します。
ステップ 3:ステップ2が正常に完了しない場合、CLI経由でCUCMパブリッシャノードのA Cisco DBサービスを再起動します(utils service restart A Cisco DB)。
パブリッシャでCisco DBを再起動すると、すべてのデータベースが再起動するため、CUCMサーバに機能や設定を設定したり追加したりすることはできません。Cisco DBサービスが再起動モードの場合、サブスクライバのデータベースはすべて読み取り専用になるため、サービスが復旧してすべてのデータベースが再設定された後、サーバでの追加や設定の試行が失われる可能性があることに注意してください。
ただし、この情報はインメモリデータベースに読み取り専用として保存されるため、電話をかけることはできます。Call Managerグループは、再起動するノードに応じてフェールオーバー用に特別に設定でき、電話は登録されたままになります。
ステップ 4:すべてのノードでA Cisco DBサービスを再起動したら、15 ~ 20分ほど待ってから、SIPトランクを追加します。
ステップ 5:パブリッシャのCisco TomcatとCisco DBを再起動した後も問題が解決しない場合は、サブスクライバノードでコール処理用のサービスを再起動します。
注:
この問題は、次のシナリオでも発生する可能性があります。
1. システムでCPU高使用率が発生した、またはまだ発生している場合。
2. ネットワークタイムプロトコル(NTP)が同期されていない場合、すべてのノードのデータベース間で非同期が発生します。
3. 期限切れの証明書がある場合。