database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
ㆍLDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
LDAP Q&A 2414 게시물 읽기
No. 2414
쓰기 성능이 나오지 않습니다..
작성자
신기배(소타)
작성일
2009-03-05 01:35
조회수
5,616

안녕하세요?


크고 빠르게 수집되는 데이터가 있습니다. 로그 같은건 아니고 사용자 데이터인데 크롤입니다.

원래는 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


답변 부탁드립니다 ㅠㅠㅠㅠ

수고하세요~

이 글에 대한 댓글이 총 2건 있습니다.

서진디에스에이(www.seojindsa.kr) 의 송상준입니다.

일단 referral을 쓰신다고 하셨는데 이걸 쓰면 클라이언트 입장에서는 한 Operation을 위해 서버를 두번 갔다 오게 되는거겠지요? 그래서 거기서 속도가 느려지는거고요. 그리고 버클리 구조는 검색 위주지 쓰기 위주는 아닌거 같습니다.

예전 SKT관련해서 테스트좀 하려고 2000천만 정도 사용자 정보를 만들어 테스트 해본 결과 이때는 refferral을 이용하지 않고 두대에 Replication을 이용하고 L4를 통해 두대에 검색과 쓰기를 한 결과를 알려드리면

버클리 데이터베이스 크기가 150G정도 되었고요. 

검색속도는 15000건/초당 , 쓰기는 120건/초당 정도가 나왔습니다.  쓰기를 많은 작업에 OpenLDAP을 쓰시는것은 아니라고 생각이 듭니다. 

                      

                                            L4

                                          /    \
                                         /      \
                                        /         \
                                 LDAP1      LDAP2

로 구성했습니다. CPU와 RAM은 비슷한 사양을 사용했던것으로 생각이 듭니다.

Search할때 램과 CPU를 많이 사용하고, 쓰기때는 디스크를 사용하지요.

그럼 수고하세요. 위 사양을 잘 튜닝한다면 검색은 20000건/초, 쓰기 200건/초이면 잘나오는 결과입니다.

송상준(sjsong)님이 2009-03-05 16:09에 작성한 댓글입니다.
이 댓글은 2009-03-05 16:10에 마지막으로 수정되었습니다.

답변 감사합니다 ^^;

LDAP가 읽기에 좋고 쓰기에 약하다는 건 알고 있었지만 자체적으로 distribute되고 신뢰할만한 솔루션 찾아서 테스드들 해보다가.. ㅠ

LDAP 테스트로 올린 장비들은 내려야겠습니다 ㅠㅠㅠ 이거 구성과 테스트에 4일이나 썼는데 아깝네요 ㅠ

나중에 이런 용도가 필요하면 꼭 LDAP를 써야겠습니다. 너무 좋네요 ^^;

그럼 수고하세요~

신기배(소타)님이 2009-03-05 17:59에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
2418ldap에 대해 공부려합니다. [1]
이재훈
2009-03-15
5923
2417ldapadd의 오류 ㅠㅠ [1]
김성목
2009-03-12
5075
2416LDAP 페이징 처리는 어떻게 하나요? [1]
염준헌
2009-03-11
5463
2414쓰기 성능이 나오지 않습니다.. [2]
신기배
2009-03-05
5616
2413SunOnLdap 5.2의 자료를 오라클로 이동.. [4]
박홍우
2009-02-27
5949
2412ldaps 와 startTLS의 차이점은 무었인가요? [2]
나종현
2009-02-20
6251
2411PHPLDAPADMIN [2]
최영길
2009-02-19
5156
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2020 DSN, All rights reserved.
작업시간: 0.044초, 이곳 서비스는
	PostgreSQL v13.0으로 자료를 관리합니다