별표 - 이유 없이 매우 높은 로드 평균

Question

알았어, 알아냈어. 이것은 단지 해결 방법이지만 문제는 허용 가능한 수준으로 떨어졌습니다.

하루 중 원치 않는 재부팅 후에 로드 평균이 크게 떨어지는 것을 발견했습니다! 서버 모니터링 시스템을 확인해 보니 LA는 항상 3~4시간 연속(그리고 안정적인) 로드 속에서 조금씩 올라갔습니다. 전날 재부팅할 수 없었기 때문에 이는 눈에 띄지 않았습니다.

내가 말했듯이, 나는 애플리케이션을 통해 호출되는 몇 가지 Perl 스크립트를 가지고 있습니다 AGI(). 그 중 하나는 h확장 으로 호출됩니다 . 하나의 간단한 DB 쿼리만 실행합니다. 때때로 DB에 약간의 과부하가 발생하는 것으로 나타났습니다. 쿼리는 200-500ms 동안 기다려야 합니다. Asterisk는 Perl 스크립트가 완료될 때까지 기다려야 합니다.

그래서 나는 fork()시작할 때 Perl 스크립트를 사용하여 AGI() 호출이 항상 즉시 반환되도록 했습니다. 이것은 많은 도움이 되었습니다! LA는 많이 안정되었습니다. 이것은 완전한 해결책은 아닙니다. Asterisk의 내부를 여전히 손상시키는 것처럼 보이지만 훨씬 느리기 때문에 거의 문제가 되지 않습니다.

바로 사용할 수 있는 코드 조각을 찾는 사람들의 경우( ing 후에는 fork()액세스할 수 없으므로 ing 전에 모든 변수를 가져오는 것을 잊지 마세요 $AGI):

my $AGI = new Asterisk::AGI;

# get all your variables here
my $var = $AGI->get_variable('var');

undef $AGI;

if (fork) { exit 0; };
open STDIN,  '<', '/dev/null'; # dont forget to free your parent's file handles
open STDOUT, '>', '/dev/null';
open STDERR, '>&STDOUT';

버그인 것 같은데 왜 저 외에는 이런 문제를 겪는 사람이 없는지 궁금합니다.

편집1:음, 통화를 제거한 후 문제가 완전히 사라졌습니다 AGI. 나는 단순히 비동기 처리를 위한 정보를 저장하는 몇 가지 사용자 정의 ODBC함수( func_odbc.conf)를 만들었습니다(나중에 별도의 Perl 데몬에 의해 처리됨). LA는 20-25에서 0.5-0.9(!)로 떨어졌습니다. AGI이렇게 큰 부하가 발생할 수 있다고는 전혀 생각하지 못했습니다 .

Answer 1