hadoop 10노드를 추가하여 20노드에서 대략 30테라 정도의 공간을 확보했다.
jaso님의 도움으로 문제 없이 무난히 확장할수 있었다.
당분간(기껏해야 몇개월?)은 스토리지 문제로 고민하지 않아도 되겠다.
상반기 30대 목표였는데 기타 시스템까지 해서 상반기의 목표는 채웠건만 올해 목표 1백대를 어떻게 채울까? ㅇㅇ
그래도 크롤센터를 향하여 전진 또 전진...
스토리지 full 때문에 replica를 2로 해 놓았었는데
3으로 늘리는 과정에서 또다른 하나의 사실을 확인할 수 있었다.
기존의 테스트에서 1기가 정도의 하둡 namenode메모리는 대략 1천만개(당근 미만)정도의 파일을 관리할수 있을것으로 예상되었다.
그런데 가만히 namenode의 힙사이즈를 보니 계속 해서 올라가는것이 아닌가.
Heap Size is 337.62 MB / 963 MB (35%) . 쭉쭉쭉
효율적인 구조라면 기본 file은 메모리에 관리하고 replica정도는 파일로 관리하는것이 맞을거라 생각되는데 hadoop은 그렇질 않는군..
replica정보까지 메모리에 올리는군...
단순 파일관리시스템이라면 그럴수 있겠지만,
hadoop의 경우는 Map&Reduce까지 고려하기 때문에 replica정보도 메모리에 관리한다고 한다.(jaso님 확인..)
그렇게 본다면 또 현재의 hadoop방식이 이해가 감...
default 파일 뿐 아니라 자기 시스템에 있는 replica도 분배해주는것이 훨 빠르기 때문이다.
이렇게 본다면 namenode의 메모리는 좀 많아야겠다.
최소 2기가에서 많으면 4기가 이상 되는것이 좋겠다...
과정을 지켜보면서 조절해야겠군..
jaso님의 도움으로 문제 없이 무난히 확장할수 있었다.
당분간(기껏해야 몇개월?)은 스토리지 문제로 고민하지 않아도 되겠다.
상반기 30대 목표였는데 기타 시스템까지 해서 상반기의 목표는 채웠건만 올해 목표 1백대를 어떻게 채울까? ㅇㅇ
그래도 크롤센터를 향하여 전진 또 전진...
스토리지 full 때문에 replica를 2로 해 놓았었는데
3으로 늘리는 과정에서 또다른 하나의 사실을 확인할 수 있었다.
기존의 테스트에서 1기가 정도의 하둡 namenode메모리는 대략 1천만개(당근 미만)정도의 파일을 관리할수 있을것으로 예상되었다.
그런데 가만히 namenode의 힙사이즈를 보니 계속 해서 올라가는것이 아닌가.
Heap Size is 337.62 MB / 963 MB (35%) . 쭉쭉쭉
효율적인 구조라면 기본 file은 메모리에 관리하고 replica정도는 파일로 관리하는것이 맞을거라 생각되는데 hadoop은 그렇질 않는군..
replica정보까지 메모리에 올리는군...
단순 파일관리시스템이라면 그럴수 있겠지만,
hadoop의 경우는 Map&Reduce까지 고려하기 때문에 replica정보도 메모리에 관리한다고 한다.(jaso님 확인..)
그렇게 본다면 또 현재의 hadoop방식이 이해가 감...
default 파일 뿐 아니라 자기 시스템에 있는 replica도 분배해주는것이 훨 빠르기 때문이다.
이렇게 본다면 namenode의 메모리는 좀 많아야겠다.
최소 2기가에서 많으면 4기가 이상 되는것이 좋겠다...
과정을 지켜보면서 조절해야겠군..
Prev
Rss Feed