mongodb profiling 과 AWS EBS IOPS에대한 고찰이라고나 할까?

http://docs.mongodb.org/manual/administration/monitoring/

프로파일링 하고자하는 DB를 선택해서

db.setProfilingLevel(1)

셋팅을 해주고

db.system.profile.find( { millis : { $gt : 100 } } )

이런식으로 찾으라고 되어있다.

하지만 millis는 그냥 자신의 쿼리가 얼마나 오래 걸린지만 나타낼뿐, 자신이 기다린 db read/write lock time이 얼마나 되며 자신이 수행되는동안 db read/write lock time을 얼마나 잡았는지는 포함되지 않는다.

profile doc 내부에 보면 아래와 같은 lock에 대한 정보가 추가로 있는데

system.profile.lockStats.timeLockedMicros

system.profile.lockStats.timeAcquiringMicros

timeLockedMicros는 자신이 lock을 얼마나 잡았는지, timeAcquiringMicros는 자신이 lock을 잡기위해 기다린 시간을 뜻한다.

따라서 client측에서의 총 기다린 시간은 millis + 자기가 기다린 lock시간이 되겠다. 그리고 자기가 잡은 lock은 그다음 쿼리에 영향을 미칠거고..

만약 자기가 lock을 잡기위해 기다린 시간이 엄청 길다면 앞에 있는 쿼리가 lock을 걸고 기다렸거나 아니면 다른 리소스에서 디스크자원을 써서 기다리는 시간이 길어졌다고 볼수 있다.

보통은 millis로만 검색해서 실제로 lock이 얼마나 있었는지 못보고 지나갈 수도 있는데 이 lock타임으로 검색하거나, 특정 시간때에 몽고디비가 이상 현상이 있었다면 그시간때 ts로 profile doc을 검색해보는 것이 좋을 듯하다.

* 참고로 아마존을 사용할때 EBS Volumes에 Read/Write Bandwidth 그래프를 보고 언제 갑자기 read/write량이 몰렸었는가를 볼 수 있으니 위 내용과 관련해서 같이 보면 좋다. 이런걸 보고 몇 IOPS가 필요한지 판단할 수 있을 듯하고, 그리고 가끔 보면 튀는게 있는데 아마도 클라우드 서비스라 그런지 다른 곳과 총 bandwidth를 나눠쓸거 같다는 생각이 들고 그러다보면 순간적으로 우리쪽에 Disk I/O 기다림이 생길수 있어서 이때 쌓였던 I/O들이 한번에 몰리면서 튀는현상을 만들어 내지 않았나 가정을 해본다.

env:200KDAU500GB1500IOPS