나는 250 ~ 동시 호출이 많은 대형 전화 교환 원이 있습니다. 큐 로그에 대한 큐 응용 프로그램 플랫 파일. 시스템은 별표 및 Queuemetrics를 사용합니다. 두 서비스는 동일한 서버에서 실행됩니다. 사양은 16 코어 및 64GB RAM입니다. 전체 시스템이 3-4 일 후에 멈추었습니다. I/O 작업이 너무 많아서 확실합니다. 디스크 I/O 플로팅 도구가 있습니까?디스크 I/O 벤치 마킹
평균 통화 시간 (ACD)이 15 초 (예기치 않게) 인 1000 건 (예기치 않은 경우)이 있다고 가정 해 보겠습니다.
So. WORST의 경우 매초마다 1000/15 = 66.66 통화가 종료됩니다.
이제 각 통화에 상담원이 10 명이라고 말합니다.
각 통화마다 queue_log에 2 + 10 + 1 줄의 텍스트가 입력됩니다.
각 행이 1kb라고 가정 해 봅시다 (일반적으로 250 바이트 이하).
그래서 13kb * 66.66 = 865kb가 디스크에 기록됩니다.
디스크가 너무 느린 것으로 생각하십니까?
따라서이 문제는 코어 I/O 병목 현상과 관련이 없습니다. Elastix/FreePBX CDR 테이블은 'datetime'필드를 사용하여 cdrs를 조회합니다. 150 만개의 레코드가있는 간단한 쿼리는 전체 테이블을 조회합니다. 그래서 나는 cdr 테이블과 다른 테이블을 인덱싱하여 db 스키마를 최적화하고 로그 쓰기를 줄였습니다. 이제 NewRelic 포털의 높은 리소스 활용과 관련된 경고는 없습니다. – Faheem
ramdisk를 사용할 수 있습니다.
기록 (record_cache_dir =는/dev/SHM asterisk.conf에서)는/dev/SHM
MySQL은 (메모리 테이블)
왜 당신이 그렇게 생각 (logrotate에 포함)에
로그? 뭐 모니터링 했니? 그것의 긴 실행중인 프로세스가 그것의 IO를 생각하기가 힘들다면. 메모리 사용량을 확인 했습니까? btw. 캔터 = 센터? –
부하 평균은 항상 높습니다. 2.5에서 12까지입니다.로드 평균 증가는 I/O 차단 때문인 것 같습니다. 하나의 Asterisk 프로세스가 디스크에 너무 많은 호출 큐 로그를 기록하고 다른 프로세스 (queuemetrics 응용 프로그램)가 해당 파일을 읽고 mysql db에 로그를 기록합니다. – Faheem
16 코어 시스템의 평균 부하가 16보다 작 으면 아무 것도하지 않는 CPU가 항상 있다는 의미입니다. – arheops