私は250〜同時呼び出しで大規模なコールキャンターを持っています。キューログのキューアプリケーションフラットファイル。システムはアスタリスクとキューメトリクスを使用します。両方のサービスは同じサーバー上で実行されます。仕様は16コアと64 GB RAMです。 システム全体が3〜4日後にスタックしたが、あまりにも多くのI/O操作が原因であると確信している。 ディスクI/Oプロットツールはありますか？ディスクI/Oベンチマーキング
たとえば、平均コール時間（ACD）が15秒（やりがいはない）で1000コールあります。
So. WORSTの場合、毎秒1000/15 = 66.66コールが終了します。
ここで、各コールが10のエージェントを呼び出すとします。
各コールごとに2 + 10 + 1行のテキストをqueue_logに入れます。
たとえば、各行は1kbです（通常は250バイト以下です）。
したがって、毎秒13kb * 66.66 = 865kbがディスクに書き込まれます。
本当にあなたのディスクはとても遅いと思いますか？
この問題は、コアI/Oのボトルネックに関連していませんでした。 Elastix/FreePBX CDRテーブルは、 'datetime'フィールドを使用してcdrsを検索します。 150万のレコードを持つ簡単なクエリは、テーブル全体を検索します。だから私は、dbrスキーマを最適化し、cdrテーブルや他のテーブルをインデックス化し、ログの書き込みを減らしました。現在、NewRelicポータルでのリソース使用率に関する警告はありません。 – Faheem
ramdiskは、 （logrotateを持つ）は/ dev/shmをへ
録音（record_cache_dir =は/ dev/shmをasterisk.conf中）
ログは
のmysql（メモリテーブル）
は、なぜあなたはそう思うだろうか？あなたは何かを監視しましたか？その長い実行中のプロセスはその種類のIOを考えるのは難しい場合。メモリ消費量を確認しましたか？ btw。カンター=センター？ –
負荷平均は常に高いです。 2.5から12の範囲です。負荷平均の増加はI/Oブロッキングによるものだと思います。 1つのアスタリスクプロセスがディスクに多くのコールキューログを書き込み、queuemetricsアプリケーションである他のプロセスがそのファイルを読み込み、mysql dbにログを書き込みます。 – Faheem
16コアシステムの負荷平均<16の場合は、何もしないCPUが常にあることを意味します。 – arheops