블로그 이미지
LifeisSimple

calendar

          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Notice

2011.01.07 00:16 Brain Trainning/NoSQL
Linux 32Bit 에서 2G 이상의 파일을 Put 할 경우 Put 하지 못하고 오류가 떨어지는 문제가 있어, 64Bit 에서 테스트 할려고 했으나 구하지 못했습니다. 

그래서 집에 있는 컴으로 테스트를 했습니다. 

테스트 환경은. 
OS : Windows7 64Bit
MEM : Memory 6G
테스트 파일 Size : 4G, 8G

IO 관련 테스트라기 보다는 부하테스트라 HDD의 IO 성능은 논외 입니다. HDD 를 SSD로 사용하면 IO측면에서는 이득이 있을 수 있으나 실 서버 환경에서는 많이 다르기에 그냥 패스

일단. 테스트의 목적은
1. 저장할 수 있는 파일의 Size는?
2. 저장된 파일은 어떤 방식으로 저장되어 지는지
3. Upload 할때와 Download 할때의 부하는 어느 정도? (스트리밍에 적용한다는 가정으로 대용량 파일들을 Up/Down)

Up/Down 테스트입니다. 
4G Test와 8G 테스트와는 큰 차이가 없었습니다. 따라서 간단히 10G에 대한 결과만 확인하도록 하겠습니다. 


파일을 올리게 되면 위의 그림과 같은 형태가 됩니다. Database의 디렉토리에는 2G 단위로 파일이 생성되게 됩니다. 
(32Bit Linux 에서는 512MB 단위로 파일이 생성되었습니다.)

db.fs.files.find() 명령으로 Put 되어진 파일의 리스트를 확인할 수 있습니다. 
4G / 8G 파일이 각각 Insert 가 된것을 확인 할 수 있습니다. 


8G 파일을 Put 했을때 서버의 Log 화면입니다. 다수의 Chunks 로 나누면서 Upload 가 진행됩니다. 


위에서는 간단히 Upload 할때의 화면이었고 이와는 다르게 그래프는 Upload 된 파일을 스트리밍 서비스를 한다는 가정하에 get 명령으로 다운받는 상황입니다. 물론 파일을 일방적으로 Down 받는것과 청크단위로 데이터를 메모리로 가져와 서비스 하는 것은 차이가 있을 듯 합니다. 그렇지만 2G의 동영상을 스트리밍 하는 경우는 이와 비슷한 결과를 보일것 같습니다. 초기 메모리는 사용량이 거의 없습니다. mongod 프로세스를 확인하면 메모리를 거의 사용하지 않고 있는 것을 알수 있습니다. 


그래프나 메모리 사용량을 확인하면 mongod 프로세스가 메모리를 95% 이상 사용하게 됩니다. 그리고, cache 되는 량이 급격하게 줄어들고, Page Fault/Sec 이 급격하게 증가합니다. 이때 시스템 로그를 확인하면 대략 메모리로 Select 한 Chunk들을 올리고 이를 다시 파일에 Write하는 것을 알 수 있습니다. 대용량일수록 Page out 이 많이 발생할 수 밖에 없는 구조이며 이때문에 전체 DB 시스템에 문제가 발생할 소지가 있습니다. 


위의 화면은 상황이 종료된 모습니다.

그럼, 결과를 보면
1. 저장할 수 있는 파일의 Size는? 
 - 8G 까지의 테스트로 보아 제한없이 저장이 가능할 것 같습니다. 

2. 저장된 파일은 어떤 방식으로 저장되어 지는지
 - OS 환경에 따라 다르나 동일 폴더에 특정 사이즈의 파일로 분할되어 저장됩니다.

3. Upload 할때와 Download 할때의 부하는 어느 정도? (스트리밍에 적용한다는 가정으로 대용량 파일들을 Up/Down)
 - MSSQL 에서도 첨부파일등의 데이터를 DB에 Blob 형태로 넣을 것인가 아니면 윈도우 파일 시스템을 활용할 것인가 논의가 되었었습니다. 
결론은 파일 시스템이 직접 처리하도록 하는 것이 좋다.. 이런 것이었습니다. 조각화 현상등 등... MongoDB 테스트에서도 대용량 파일을 전체 Put한 후 Get하는 과정에서 시스템에 엄청난 부하를 주는 것을 확인할 수 있었습니다.

이번 테스트를 통해서 MongoDB 역시 db의 cache를 꼭 활용해야하는 경우가 아닌 경우는 되도록 파일 시스템에 파일을 저장하고 링크를 DB에 저장하는 것이 좋겠다라는 것을 확인하게 되었습니다.

8G의 파일을 파일 시스템에서 Copy 했을 경우 시간 및 시스템 부하 정도가 MongoDB의 그것과 현격하게 차이가  났습니다. 
소량의 데이터 파일들에 대한 테스트는 추후에 다시 한번 진행하겠지만 현재의 상황을 봤을때 대용량 동영상등의 스트리밍에는 활용하기 어려운 것 같습니다. 

전용시스템에 Memory가 아주 충분한 상황이나 혹은 Sharding을 통한 메모리/IO 성능 향상이 있다면 이야기는 달라질 수 있습니다. 


posted by LifeisSimple
TAG ,

댓글을 달아 주세요

  1. 라일 2012.05.17 10:02  Addr Edit/Del Reply

    마지막 결론 부분에서 의문이 생깁니다. 파일시스템에 파일을 저장하고 DB에는 그에 대한 패스를 저장하는 게 좋다는 부분이요. DB 로 파일을 전송하는 데 발생하는 로드와 파일시스템 안에서 copy 했을 때의 차이를 비교하신 의도는 알겠지만, 파일시스템 안에서의 copy 와 DB 로의 파일 저장의 성능 차이를 비교하시려면 로컬머신 안에서 하실 게 아니라 리모트에서 파일을 전송하는 걸로 하셔야 합니다. 실 서비스 환경에서 DB 에 저장될 파일이 있다면 로컬머신안에서 생성되는 경우보다 원격에서 전송받아 저장하는 경우가 훨씬 더 많기 때문이죠. 그렇게 했을 때 시스템이 파일을 전송받아 저장하고, 다시 읽어서 전송해주는 데 서버 로드와 응답시간을 비교했다면 더 도움이 되는 테스트가 되었을 것 같네요.

    • LifeisSimple 2012.07.02 10:56 신고  Addr Edit/Del

      네. 조언 감사드립니다. ^^
      제가 저렇게 테스트한 이유가 대용량 (HD화질 이상의 동영상) 파일에 대해서 어드민에서 Upload하는 경우를 가정한 것이라 로컬에서 Upload하는 것으로 테스트했습니다. (NAS 등에서 바로 끌어 올리는 것으로) 물론 서비스는 Remote에서 받게 되겠지요. 일반적인 케이스에서는 라일님께서 말씀하신 내용이 맞습니다. 혹, 제가 잘못알고 있는 내용이 있다면 말씀부탁드립니다. ^^ 좋은 자료 있으시면 공유해주시면 더욱 감사하겠습니다. 즐거운 하루 되세요.