|
안녕하세요?
크고 빠르게 수집되는 데이터가 있습니다. 로그 같은건 아니고 사용자 데이터인데 크롤입니다.
원래는 PostgreSQL로 했었는데 데이터가 1억2천만건을 넘어가니까 조인하고 정렬하고 이런게 성능이 안나와서 distribute된 저장소를 생각하다가
6년만에 LDAP을 만졌는데요. OpenLDAP 2.4.11 입니다.
장비는 테스트 장비 3대고요. 옵테론이고 코어는 2개, 램은 7기가 입니다. 하드는 420G * 2를 RAID 0으로 묶어놨습니다.
각각을 A, B, C라고 하고요. A가 최상위이고 B, C는 A의 중간 노드의 referral입니다.
데이터가 쌓이는 양은 B가 제일 많고 그다음이 C, A인데 B에 비하면 A와 C는 별로 쌓이지 않아서 별 문제가 없습니다.
B에 엔트리가 50만건 정도 쌓였습니다.
요청은 모두 A에게 날아가고 아래 노드로 내려가다가 B로의 referral을 만나면 자동으로 referral하게 되어서 처리하게 되어 있습니다.
이 B의 성능이 지금 너무 안나오는데요. 초당 400건은 써야 하는데 초당 30건도 채 못 쓰면서 시스템 로드는 20정도 가르키고 있습니다..
검색 속도도 느리고요.
B의 엔트리 구조입니다.
B가 담당하는 최상위 ------- 약 백만개 이상의 엔트리 -------- 약 수천의 엔트리
인덱스는 잘 걸려있습니다.
입력할 때 엔트리가 있는지 확인해보고 없으면 집어넣고 하는데 데이터를 집어넣기 시작하면 램은 거의 사용하지 않고 시스템 로드만 계속 올라갑니다. ㅠ
설정 내용입니다.
olcToolThreads: 10
olcThreads: 100
dn: olcDatabase={1}bdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=XXXXXXX,dc=com
olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=admin,cn=config
" write by anonymous auth by self write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by dn="cn=admin,cn=config" write by * read
olcLastMod: TRUE
olcDbCheckpoint: 32768 1
olcDbConfig: {0}set_cachesize 0 536870912 1
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbConfig: {4}lg_bsize 67108864
structuralObjectClass: olcHdbConfig
entryUUID: 9585f404-9af1-102d-8e5c-ad511d2e3bce
creatorsName: cn=admin,cn=config
createTimestamp: 20090301211341Z
olcDbIndex: objectClass,sg,p,tid,g,uid,url eq
olcDbLinearIndex: TRUE
olcDbNoSync: TRUE
olcDbSearchStack: 1024
olcDbCacheSize: 1000000
entryCSN: 20090304091330.915032Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20090304091330Z
인터넷 보고 이거저거 고친다고 해봤는데 상태가 좋아지지 않습니다. 인덱스 관련 바꿀때마다 slapindex는 해줬습니다.
db_stat 결과 중 윗 부분입니다.
2MB 514KB 24B Total cache size.
1 Number of caches.
2MB 520KB Pool individual cache size.
3 Requested pages mapped into the process' address space.
46M Requested pages found in the cache (97%).
1331259 Requested pages not found in the cache.
18626 Pages created in the cache.
1331259 Pages read into the cache.
389580 Pages written from the cache to the backing file.
1118951 Clean pages forced from the cache.
230501 Dirty pages forced from the cache.
0 Dirty pages written by trickle-sync thread.
522 Current total page count.
522 Current clean page count.
0 Current dirty page count.
257 Number of hash buckets used for page location.
49M Total number of times hash chains searched for a page.
33 The longest hash chain searched for a page.
111M Total number of hash buckets examined for page location.
103M The number of hash bucket locks granted without waiting.
668 The number of hash bucket locks granted after waiting.
363 The maximum number of times any hash bucket lock was waited for.
5166228 The number of region locks granted without waiting.
1435 The number of region locks granted after waiting.
1350227 The number of page allocations.
2728140 The number of hash buckets examined during allocations
319 The max number of hash buckets examined for an allocation
1349452 The number of pages examined during allocations
156 The max number of pages examined for an allocation
답변 부탁드립니다 ㅠㅠㅠㅠ
수고하세요~
|
