Openldap繼續(xù)發(fā)嚴(yán)重問(wèn)題，歡迎大家交流

quakelee

在繼續(xù)的使用中我發(fā)現(xiàn)了一些更加嚴(yán)重的問(wèn)題，我向數(shù)據(jù)庫(kù)中導(dǎo)入了1000萬(wàn)的數(shù)據(jù)，在導(dǎo)入數(shù)據(jù)的時(shí)候已經(jīng)發(fā)現(xiàn)在導(dǎo)入到不到200萬(wàn)條數(shù)據(jù)的時(shí)候slapd已經(jīng)吃到了操作系統(tǒng)允許的進(jìn)程空間的上限，slapd并沒(méi)有死掉，但是客戶端ldapadd已經(jīng)收到了slapd發(fā)送的錯(cuò)誤，拒絕再繼續(xù)添加數(shù)據(jù)。此時(shí)slapd已經(jīng)占用了了520M左右的內(nèi)存。而且一直保持這個(gè)狀態(tài)不釋放內(nèi)存。必須重啟進(jìn)程釋放內(nèi)存后才能繼續(xù)添加數(shù)據(jù)。數(shù)據(jù)添加完畢后在未添加索引的情況下，對(duì)1000萬(wàn)數(shù)據(jù)進(jìn)行遍歷的時(shí)候出現(xiàn)同樣的問(wèn)題。slapd占用了簡(jiǎn)直可以說(shuō)是海量的內(nèi)存，甚至在超過(guò)操作系統(tǒng)進(jìn)程空間限制的情況下被操作系統(tǒng)殺滅了……�，F(xiàn)在我們不確定是不是因?yàn)槭褂胒reebsd 5-stable的問(wèn)題，征求一下大家的使用經(jīng)驗(yàn)，是否也曾經(jīng)遇到過(guò)類似的問(wèn)題，尤其是在linux平臺(tái)上是否也有類似的問(wèn)題出現(xiàn)？

py

是不是ldapadd本身的問(wèn)題，換個(gè)ldapadd版本試試。不知道sun的ldap會(huì)不會(huì)也這樣�？磥�(lái)openldap問(wèn)題不少

quakelee

openldap前兩天剛剛升級(jí)了2.2.18，修正了兩個(gè)內(nèi)存泄漏，但是查看了一下Openldap的ITS系統(tǒng)，backend-bdb還是存在一個(gè)嚴(yán)重的內(nèi)存泄漏沒(méi)有修復(fù)。真是無(wú)窮無(wú)盡的問(wèn)題，以上的情況很有可能是backend-bdb內(nèi)存泄漏造成的

ldapchina

更大的可能是你slapd.conf中設(shè)置的緩沖太大，openldap占用的內(nèi)存幾乎都是緩沖所用
另外，集中導(dǎo)入大量條目(比如初始數(shù)據(jù))應(yīng)該用slapadd在服務(wù)器端進(jìn)行。ldapadd是遠(yuǎn)程客戶端，效率差遠(yuǎn)了

fuwenyu0307

看看~~路過(guò)