최근 몇일의 시행착오 과정에 다른 이들의 경험을 참고했던 것처럼 다른 이들도 참고하고, 혹시 아직 남은 궁금증에 대해서 알려주는 사람이 있기를 기대하며 메모를 남김.
미디어위키에 일라스틱서치 인스턴스를 붙여서 사용중.
미디어위키, CirrusSearch, Elastica, Elasticsearch의 관계는
- 미디어위키에 변경 사항이 생김.
- CirrusSearch에서 업데이트할 사항을 결정하고,
- Job queue에 관련 사항이 추가됨.
- runJobs.php가 돌아갈 때 정보가 ES로 넘어가서 기록됨.
문제점
- crontab 이용하여 10분에 한번씩 rubJobs.php를 돌리게 만듬.
- 12시간 정도 지나면 서버가 거의 먹통이 되어 버림.
- AWS의 인스턴스를 정지하였다가 다시 시작해야 진정되었음. (restart로는 해결되지 않음)
- 이런 상황을 겪고 나면 케바케인데 ES쪽에 인덱스가 날아가버리는 상황이 발생함.
- /extension/CirrusSearch/Saneitize.php를 돌리면 job count만 엄청나게 올라가고 runJobs.php가 오래 돌아가야 하는 문제가 반복됨.
해결 방안 (현재까지)
- 내가 쓰는 AWS 인스턴스(t2,micro) 수준에서 runJobs.php를 계속 돌리면 load average 값이 15~17까지 올라가며 상황이 수습되지 않음.
- runJobs.php에 –maxjobs, –memory-limit, –maxtime 등의 파라메터를 넣어서 해봤는데 –maxtime이 제일 안정적이었음.
- 테스트하는 동안 top 으로 load average를 확인.
- 일라스틱서치쪽에는 curl -s localhost:9200/_cat/indices?v 로 인덱스별로 store.size가 증가하는 것을 확인.
- maxtime을 30초로 했을 때 load average는 0.9까지 올라감. (물론 인스턴스 사양이 좋으면 결과가 다를 것으로 생각함)
- 그래서 10분 단위로 maxtime=10으로 runJobs.php를 돌리는 것으로 결정.
남들이 된다고 해도 내 시스템에서 되는가는 다른 얘기임.
부수적으로 알게된 사항들
Localsettings.php에서 $wgRunRate=0.1로 설정하면 웹서버에 request가 10개 들어올 때 Job 1개를 처리하는 것임. 이것을 10 정도로 하면 MW에서 페이지 열 때 느려짐. 0으로 하면 터미널로 접속해서 실행하기 전에는 runJobs를 돌리지 않음.
ES 서버에 인덱스들이 만들어짐. (디비이름)_general_first, (디비이름)_content_first, (디비이름)_archive_first, (디비이름)_metastore_first 등임.
ES 인스턴스에 문제가 생겼을 때 인덱스가 없어지는 상황이 있었는데 원인은 오리무중.
ES 인덱스가 없어지면 MW에서는 검색 오류가 발생함. 이때 /extension/CirrusSearch/maintenance/CheckIndex.php를 해볼 것.
그리고 나서는 Metastore.php, UpdateSearchIndexConfig.php 등을 실행시키면 ES 쪽에 인덱스가 만들어짐. ES에서 curl -s localhost:9200/_cat/indices?v 로 확인 가능.
MW의 job은 maintenance/showJobs.php로 알 수 있음. 여기에 –group 옵션을 주면 job type 별로 조회할 수 있음.
cirrusSearchElasticaWrite 항목은 무시해도 됨. 3번 해보고 안되면 없어진다는 얘기가….
쓰레기가 쌓여서 job count만 엄청나게 올라간 경우에는 mysql에서 job 테이블의 내용을 날려버리는 것이 좋다. 그 이후에 saneitize.php를 돌려서 업데이트할 문서 정보를 job에 추가해야 함.
crontab 관련 사항
- crontab -e, sudo crontab -e, vi /etc/crontab 이 결과가 다름.
- 이번에 성공한 것은 sudo crontab -e 였음. 이것은 root 권한으로 실행됨.
- /etc/crontab 수정하는 것은 사용자를 지정해야 함.
여러가지 삽질을 해본 결과, ES쪽의 인덱스가 날아가도 runJobs.php로 한번에 처리할 수 없으므로 번거롭지만 다시 만들고 정리하면 되기는 하다.
MW에서 검색이 안될 때 확인할 사항들
- curl localhost:9200으로 일라스틱서치가 돌아가는지 확인
- 이거는 jps | grep Elasticsearch로도 알 수 있음.
- curl -s localhost:9200/_cat/indices?v로 인덱스 상태를 확인
- MW쪽에서 /extensiton/CirrusSearch/maintenance/CheckIndex.php 확인
현재 남은 잡 개수는 5358개. 아마 서버 폭주하는 문제가 재발하지 않으면 내일쯤이면 job count 0이 되고, 검색도 잘되겠지… 다른 문제였다고 여기에 업데이트하는 일이 없으면 좋겠다.
Memo 5 
뭔가 다른 놈이 있는건가? load average가 16까지 올라가서 crontab 다 죽였으나, 30분째 내려가지 않고 있다. 물론 ES 쪽 인덱스도 망가져 버렸다. ㅠㅠ
선후 관계는 어떻게 되는걸까?
인덱스가 없어져서 runjobs가 폭주하는가?
아님 폭주해서 인덱스가 날아가는건가?
인덱스가 말끔히 없어지는 이유가 뭘까?
23시간만에 다시 폭주. 현재 load average = 16.37
아파치, php, mysql을 중단시키고 있는데 한참 걸리는군.
다행히 이번에 일라스틱서치쪽 인덱스는 살아 있는데….
대체 왜 자꾸 이렇게 폭주하는지… 답답하다.
미디어위키 쓰면서 systemlog까지 뒤지게될 줄이야…
sudo /opt/bitnami/ctlscript.sh stop 하는데 한참 걸리는데, stop 시킨 다음에 load average가 떨어지는 것을 확인했고, ctlscript.sh start 시킨 다음에 정상적으로 열리는 것을 확인.
인스턴스 중지/시작까지 하지 않아도 상황은 해결할 수 있다.
시스템로그에서 폭주하는 원인을 찾을 수 있으면 좋겠다.
매번 삽질의 연속이다. ctlscript.sh start 하고 돌아가는 것 같더니 지금 보니 다시 load average가 15수준으로 올라감. 아마 이전에 남아 있던 것들이 다시 실행되는 모양임. 인스턴스 정지시키는 것과 이런 부분이 다름.
crontab에서 runJobs.php를 실행시킬 때 현재 load average가 얼마인지 확인하고 문제 없으면 실행시킬 수 있을까?
뭔지 상황은 정확히 이해할 수 없으나, 뭔가 실행하다가 문제가 생겨서 (느려져서) 잡이 큐에 쌓이고 있는데 runJobs.php가 반복되면서 폭주하는 상황이 되는 것이 아닌가 하고 의심하고 있음.
AWS 인스턴스를 새로 만들고 elasticsearch를 새로 설치한 다음에 검색 인덱스 사라지는 문제는 해결된 것 같고, runJobs.php가 폭주하는 문제는 crontab에서 runJobs.php 실행 주기를 47분으로 바꾼 다음에 개선된 것 같다. 한두번 폭주해서 AWS 인스턴스를 정지시켰다 시작한 경우가 있었는데 당장은 재발하지 않고 있다.