블로그 이미지
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
31

Notice

2011. 1. 7. 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