Xeraph@NCHOVY

과연 중국어 살아남을 수 있을까... 꼭 필요하긴 한데..

저번에 금*원 데모에서 박살나고 VTune 사다가 최적화 작업을 아직까지 진행 중 -_-;; 

(금방 된다고 한게 벌써 한 달 지났어....ㅠㅠ 쪽팔려)

익시아도 없어서 만들어서 테스트 하는 불쌍한 회사...

10G까지 올려야 되는데..

그나저나 개드립 제네레이터인듯.. -_-;

회사 컴으로는 320M 벌크 로딩할 때 초당 4천 정도로 읽어들이면서 풀텍스트 인덱싱을 안정적으로 수행한다. (약 25~70% CPU 사용) 데이터 소스가 하나라서 그렇지 리소스는 좀 더 여유가 있으니 아마 8천~1만까지는 당장 처리가 될 것 같다.. 나머지는 프로파일링 해가면서 개선하는 수 밖에..

위 화면에선 200만건 로딩 직후 검색해서 40ms 나온걸로 보이지만 사실 입력 도중에도 저 정도 시간 안에 결과 떨어진다.. 인덱스는 초기에 잉여롭게 900M까지 생성되던걸 190M 수준으로 떨어뜨려놨다.. 데이터는 700M 되는데 이건 Value만 있는 로그에 Key가 추가되고 일부 타입정보가 추가되기 때문에 그렇다.. (물론 별도의 파싱/정규화 없이 syslog 그대로 밀어넣고 인덱싱도 가능) 그래서 지금은 입력되면 원본 텍스트 300M -> 900M 되시겠다.. 메모리에 캐시된 인덱스 양은 크라켄에서 강제로 GC 내리고 남은 메모리를 봤을 때 40M 이하인 것 같다..

덤으로 좋은 점은 DB에서 한 번 쓰기 완료되면 파일을 잡고 있지 않기 때문에.. DB 내릴 필요 없이 그냥 파일을 복사/백업하거나 삭제하면 된다.. 날짜별로 잘 분류가 되어있으므로.. 심지어 백업한걸 복구하는 것도 그냥 인덱스랑 데이터 파일 복사만 하면 된다 ㅋㅋㅋ

아무튼 실시간 압축을 해야되는데 머리에 그림은 다 그렸는데 API가 의도한 것과 결과가 자꾸 다르게 나와서 삽질하고 있다.. 적어도 30% 수준으로라도 압축하게 되면 원본 로그와 똑같은 공간을 잡아먹으면서도 풀텍스트 검색을 얻는 효과가 나게 된다..

아무튼 압축~~

----

3시 추가..

원래 190M이던걸 118M 수준으로 실시간 인덱스 압축 가능. 생각보다는 많이 안 내려간다.  아무래도 전체 파일 통압축이 아니라서.. 차라리 differential variable encoding이 나을 수도 있을듯..

이제 실시간 데이터 압축할 차례..

-- 

인덱스 실시간 압축이 뭔가 이상함.. 이번에야말로 제대로 되는 줄 알았더니 압축 스트림 중간쯤 읽다보면 맛이 간다.. Deflater 뭔가 이상해.. 네이티브 쪽에서 메모리도 새길래 우회하긴 했는데 다른 문제도 있는듯.. 일단 롤백함..

---

옛날 낚인 것을 알았을 때 써놨던 글: 파닥파닥

제온 8코어면 나도 1만 이상은 널널하게 나오겠다 클러스터 기능이나 만들자..