- openldap-bugs - openldap.org

(ITS#9214) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) 555

1 0

(ITS#9212) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) 555

1 0

(ITS#9210) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) 555

1 0

(ITS#9208) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) 555

1 0

(ITS#9206) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) 555

1 0

(ITS#9204) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) 555

1 0

(ITS#9202) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) 555

1 0

(ITS#9200) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) 555

1 0

(ITS#9198) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) 555

1 0

(ITS#9196) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) 555

1 0

(ITS#9194) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) 555

1 0

(ITS#9192) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) 555

1 0

(ITS#9190) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) ð''ð""

1 0

(ITS#9188) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) ¿'¿"

1 0

(ITS#9186) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) JyI=

1 0

(ITS#9184) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) @@LKtOz

1 0

(ITS#9182) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) 1

1 0

(ITS#9180) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) \

1 0

(ITS#9178) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) 1'"

1 0

(ITS#9176) 1
by sample＠email.tst 20 Feb '20

20 Feb '20

Full_Name: tsSLAueP OS: 1 URL: ftp://ftp.openldap.org/incoming/ Version: 1 Submission from: (NULL) (178.238.229.54) 555

1 0

RE: Re: (ITS#9017) Improving performance of commit sync in Windows
by kriszyp＠gmail.com 18 Feb '20

18 Feb '20

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta ht= tp-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta name= =3DGenerator content=3D"Microsoft Word 15 (filtered medium)"><style></style></head><body lang=3DEN-CA link=3Dblue vlink=3D"#954F72"><div cla= ss=3DWordSection1>Looking into the APIs, I would guess= that CreateFileMapping=E2=80=99s dwMaximumSizeHigh and dwMaximumSizeLow ar= guments are mapped to NtCreateSection=E2=80=99s MaximumSize argument (4<sup= >th argument). In LMDB=E2=80=99s 0.9 CreateFileMapping call, the size= is provided (since it is required), whereas NtCreateSection has MaximumSiz= e as optional, and in LMDB (mdb.master), it is not provided. Passing the si= ze in (with MaximumSize argument) to NtCreateSection seems to result in the= same behavior as CreateFileMapping of preallocating a file size equivalent= to the max/mapping size, rather than dynamically growing.<o:p> </o:p>It is challenging to read= ily test for the performance issues; it took a fair bit of effort and load = testing to trigger the long-duration performance/freezing issues we had see= n before on Azure. However, in some more isolated tests, providing a Maximu= mSize to NtCreateSection does seem to perform better than leaving it unspec= ified (specifically the system CPU usage seems to about be about twice as m= uch with dynamic growth than fixed file size), and the performance seems ab= out the same as CreateFileMapping. And I think we both had suspected that i= t was likely due to the overhead or inefficiencies in how Windows was dynam= ically growing the (size of the) mapped file, and having Windows used a pre= defined fixed file size, whether through NtCreateSection or CreateFileMappi= ng, probably would prevent these slowdown issues.<= o:p> </o:p>But, whether we use NtCreateSectio= n or CreateFileMapping, we are still faced with the same trade-off of wheth= er to use dynamic Windows-controlled file growth (convenient since the map = size can be set arbitrarily large), or using pre-specified file size (to av= oid the slowing/freezing that seems to sometimes result from dynamic Window= s growth). So I assume it would still be reasonable to offer a compile time= option, so users could opt-in to using a fixed file size (provide the Maxi= mumSize to NtCreateSection)? Fortunately this would be a trivial addition, = just a few lines of code to use the preprocessor switch to supply this argu= ment.<o:p> </o:p><a = href=3D"http://undocumented.ntinternals.net/index.html?page=3DUserMode%2FUn= documented%20Functions%2FNT%20Objects%2FSection%2FNtMapViewOfSection.html">= http://undocumented.ntinternals.net/index.html?page=3DUserMode%2FUndocument= ed%20Functions%2FNT%20Objects%2FSection%2FNtMapViewOfSection.html</a><p= class=3DMsoNormal><o:p> </o:p>Thanks, Kri= s<o:p> </o:p><div style=3D'mso-element:pa= ra-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm = 0cm 0cm'>From: </= b><a href=3D"mailto:hyc@symas.com">Howard Chu</a> Sent: February = 18, 2020 8:15 AM To: <a href=3D"mailto:kriszyp@gmail.com">Kris Zy= p</a> Cc: <a href=3D"mailto:openldap-its@openldap.org">openldap-i= ts(a)OpenLDAP.org</a> Subject: Re: (ITS#9017) Improving performance= of commit sync in Windows</div><o:p> </o:p><= /p>Kris Zyp wrote:> Yes, I= will work on upgrading this patch to 1.0.> </p= >> However, I believe in order to realize optimal W= indows performance without regression/slow-downs, I will also need to disab= le the use of NTDLL (and use direct> CreateFile= Mapping memory maps instead), as mentioned  http://www.openldap.org/li= sts/openldap-bugs/201902/msg00009.html. You had mentioned in that thread th= at> the NTDLL code wasn't destined for release,= is that still the case (it is still in the mdb.master branch)? If you are = intending to release (1.0) with the> NTDLL-base= d memory maps (which is understandable, can certainly be an easier path for= Windows users getting started), I will also need to add the compiler<p= class=3DMsoNormal>> option to disable it. Anyway, I will work on creati= ng a PR with both these patches.<o:p> </o:p><= /p>Might be interesting to investigate why the behavio= r with NTDLL is so much slower on Azure. Sincethe = Win32 APIs are implemented on top of the NT APIs, you would expect them to = perform identically.Perhaps there's some additiona= l flag that the Win32 API is passing to NT that is needed on Azure.<o:p> </o:p>> > Thanks,> Kris> > On Mon, Feb 17, 2020 at 8:14 A= M Howard Chu <hyc(a)symas.com <mailto:hyc@symas.com>> wrote:<= p class=3DMsoNormal>> >=C2=A0=C2=A0=C2=A0=C2= =A0 Kris Zyp wrote:>=C2=A0=C2=A0=C2=A0=C2=A0 &g= t; Sorry to keep pestering, but just pinging about this patch again, as I s= till think this fix could benefit windows users. And at this point, I think= I can>=C2=A0=C2=A0=C2=A0=C2=A0 say we>=C2=A0=C2=A0=C2=A0=C2=A0 > have tested it pretty wel= l, running on our servers for almost a year :).&gt= ; >=C2=A0=C2=A0=C2=A0=C2=A0 Looks like this pat= ch is against the 0.9 release branch. I hit a bunch of conflicts>=C2=A0=C2=A0=C2=A0=C2=A0 trying to apply it to mdb.master= . We'll be stopping work on 0.9 soon, and getting&= gt;=C2=A0=C2=A0=C2=A0=C2=A0 LMDB 1.0 out the door finally, so can you pleas= e verify that your changes will work>=C2=A0=C2= =A0=C2=A0=C2=A0 on mdb.master as well?> >=C2=A0=C2=A0=C2=A0=C2=A0 > Thanks,>=C2=A0=C2=A0=C2=A0=C2=A0 > Kris&gt= ;=C2=A0=C2=A0=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2= =A0=C2=A0 > On Wed, Sep 18, 2019 at 12:56 PM Kris Zyp <kriszyp(a)gmail.= com <mailto:kriszyp@gmail.com> <mailto:kriszyp@gmail.com <mailt= o:kriszyp@gmail.com>>> wrote:>=C2=A0= =C2=A0=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2=A0=C2= =A0 >     Checking on this again, is this still a possibi= lity for merging into LMDB? This fix is still working great (improved perfo= rmance) on our systems.>=C2=A0=C2=A0=C2=A0=C2= =A0 >     Thanks,>=C2=A0=C2= =A0=C2=A0=C2=A0 >     Kris>= =C2=A0=C2=A0=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2= =A0=C2=A0 >     On Mon, Jun 17, 2019 at 1:04 PM Kris Zyp = <kriszyp(a)gmail.com <mailto:kriszyp@gmail.com> <mailto:kriszyp@g= mail.com <mailto:kriszyp@gmail.com>>> wrote:>=C2=A0=C2=A0=C2=A0=C2=A0 >>=C2=A0= =C2=A0=C2=A0=C2=A0 >         Is this still bein= g considered/reviewed? Let me know if there are any other changes you would= like me to make. This patch has continued to yield>=C2=A0=C2=A0=C2=A0=C2=A0 >         signifi= cant and reliable performance improvements for us, and seems like it would = be nice for this to be available for other Windows users.>=C2=A0=C2=A0=C2=A0=C2=A0 >>=C2=A0= =C2=A0=C2=A0=C2=A0 >         On Fri, May 3, 201= 9 at 3:52 PM Kris Zyp <kriszyp(a)gmail.com <mailto:kriszyp@gmail.com&gt= ; <mailto:kriszyp@gmail.com <mailto:kriszyp@gmail.com>>> wro= te:>=C2=A0=C2=A0=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2=A0=C2=A0 >        &= nbsp;    For the sake of putting this in the email thread (other = code discussion in GitHub), here is the latest squashed commit of the propo= sed patch (with>=C2=A0=C2=A0=C2=A0=C2=A0 >&n= bsp;            the on-demand, retained overl= apped array to reduce re-malloc and opening event handles):>=C2=A0=C2=A0=C2=A0=C2=A0 >        &nbsp= ;    https://github.com/kriszyp/node-lmdb/commit/726a9156662c703b= f3d453aab75ee222072b990f>=C2=A0=C2=A0=C2=A0=C2= =A0 >> > >=C2=A0=C2=A0=C2=A0=C2=A0 -- = >=C2=A0=C2=A0=C2=A0=C2=A0   -- Howard Chu&= gt;=C2=A0=C2=A0=C2=A0=C2=A0   CTO, Symas Corp.      &nb= sp;    http://www.symas.com>=C2=A0=C2= =A0=C2=A0=C2=A0   Director, Highland Sun     http://hig= hlandsun.com/hyc/>=C2=A0=C2=A0=C2=A0=C2=A0 &nbs= p; Chief Architect, OpenLDAP  http://www.openldap.org/project/> <o:p> </o:p><o:p> </o:p>-- =C2=A0=C2=A0-- Howard Chu=C2=A0 CTO, Syma= s Corp.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://= www.symas.com=C2=A0 Director, Highland Sun=C2=A0= =C2=A0=C2=A0=C2=A0 http://highlandsun.com/hyc/=C2= =A0 Chief Architect, OpenLDAP=C2=A0 http://www.openldap.org/project/<o:p> </o:p></div></body></html>=

1 0

Re: (ITS#9017) Improving performance of commit sync in Windows
by hyc＠symas.com 18 Feb '20

18 Feb '20

Kris Zyp wrote: > Yes, I will work on upgrading this patch to 1.0. >=20 > However, I believe in order to realize optimal Windows performance with= out regression/slow-downs, I will also need to disable the use of NTDLL (= and use direct > CreateFileMapping memory maps instead), as mentioned=C2=A0 http://www.o= penldap.org/lists/openldap-bugs/201902/msg00009.html. You had mentioned i= n that thread that > the NTDLL code wasn't destined for release, is that still the case (it = is still in the mdb.master branch)? If you are intending to release (1.0)= with the > NTDLL-based memory maps (which is understandable, can certainly be an e= asier path for Windows users getting started), I will also need to add th= e compiler > option to disable it. Anyway, I will work on creating a PR with both th= ese patches. Might be interesting to investigate why the behavior with NTDLL is so muc= h slower on Azure. Since the Win32 APIs are implemented on top of the NT APIs, you would expect th= em to perform identically. Perhaps there's some additional flag that the Win32 API is passing to NT = that is needed on Azure. >=20 > Thanks, > Kris >=20 > On Mon, Feb 17, 2020 at 8:14 AM Howard Chu <hyc(a)symas.com <mailto:hyc@s= ymas.com>> wrote: >=20 > Kris Zyp wrote: > > Sorry to keep pestering, but just pinging about this patch again,= as I still think this fix could benefit windows users. And at this point= , I think I can > say we > > have tested it pretty well, running on our servers for almost a y= ear :). >=20 > Looks like this patch is against the 0.9 release branch. I hit a bu= nch of conflicts > trying to apply it to mdb.master. We'll be stopping work on 0.9 soo= n, and getting > LMDB 1.0 out the door finally, so can you please verify that your c= hanges will work > on mdb.master as well? >=20 > > Thanks, > > Kris > > > > On Wed, Sep 18, 2019 at 12:56 PM Kris Zyp <kriszyp(a)gmail.com <mai= lto:kriszyp@gmail.com> <mailto:kriszyp@gmail.com <mailto:kriszyp@gmail.co= m>>> wrote: > > > >=C2=A0 =C2=A0 =C2=A0Checking on this again, is this still a possib= ility for merging into LMDB? This fix is still working great (improved pe= rformance) on our systems. > >=C2=A0 =C2=A0 =C2=A0Thanks, > >=C2=A0 =C2=A0 =C2=A0Kris > > > >=C2=A0 =C2=A0 =C2=A0On Mon, Jun 17, 2019 at 1:04 PM Kris Zyp <kris= zyp(a)gmail.com <mailto:kriszyp@gmail.com> <mailto:kriszyp@gmail.com <mailt= o:kriszyp@gmail.com>>> wrote: > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Is this still being considered/r= eviewed? Let me know if there are any other changes you would like me to = make. This patch has continued to yield > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0significant and reliable perform= ance improvements for us, and seems like it would be nice for this to be = available for other Windows users. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, May 3, 2019 at 3:52 PM K= ris Zyp <kriszyp(a)gmail.com <mailto:kriszyp@gmail.com> <mailto:kriszyp@gma= il.com <mailto:kriszyp@gmail.com>>> wrote: > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For the sake of pu= tting this in the email thread (other code discussion in GitHub), here is= the latest squashed commit of the proposed patch (with > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the on-demand, ret= ained overlapped array to reduce re-malloc and opening event handles): > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://github.com= /kriszyp/node-lmdb/commit/726a9156662c703bf3d453aab75ee222072b990f > > >=20 >=20 > --=20 > =C2=A0 -- Howard Chu > =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0htt= p://www.symas.com > =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0http://highlandsun= .com/hyc/ > =C2=A0 Chief Architect, OpenLDAP=C2=A0 http://www.openldap.org/proj= ect/ >=20 --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#9017) Improving performance of commit sync in Windows
by kriszyp＠gmail.com 18 Feb '20

18 Feb '20

--000000000000ce7c35059edab753 Content-Type: text/plain; charset="UTF-8" Yes, I will work on upgrading this patch to 1.0. However, I believe in order to realize optimal Windows performance without regression/slow-downs, I will also need to disable the use of NTDLL (and use direct CreateFileMapping memory maps instead), as mentioned http://www.openldap.org/lists/openldap-bugs/201902/msg00009.html. You had mentioned in that thread that the NTDLL code wasn't destined for release, is that still the case (it is still in the mdb.master branch)? If you are intending to release (1.0) with the NTDLL-based memory maps (which is understandable, can certainly be an easier path for Windows users getting started), I will also need to add the compiler option to disable it. Anyway, I will work on creating a PR with both these patches. Thanks, Kris On Mon, Feb 17, 2020 at 8:14 AM Howard Chu <hyc(a)symas.com> wrote: > Kris Zyp wrote: > > Sorry to keep pestering, but just pinging about this patch again, as I > still think this fix could benefit windows users. And at this point, I > think I can say we > > have tested it pretty well, running on our servers for almost a year :). > > Looks like this patch is against the 0.9 release branch. I hit a bunch of > conflicts > trying to apply it to mdb.master. We'll be stopping work on 0.9 soon, and > getting > LMDB 1.0 out the door finally, so can you please verify that your changes > will work > on mdb.master as well? > > > Thanks, > > Kris > > > > On Wed, Sep 18, 2019 at 12:56 PM Kris Zyp <kriszyp(a)gmail.com <mailto: > kriszyp(a)gmail.com>> wrote: > > > > Checking on this again, is this still a possibility for merging into > LMDB? This fix is still working great (improved performance) on our systems. > > Thanks, > > Kris > > > > On Mon, Jun 17, 2019 at 1:04 PM Kris Zyp <kriszyp(a)gmail.com <mailto: > kriszyp(a)gmail.com>> wrote: > > > > Is this still being considered/reviewed? Let me know if there > are any other changes you would like me to make. This patch has continued > to yield > > significant and reliable performance improvements for us, and > seems like it would be nice for this to be available for other Windows > users. > > > > On Fri, May 3, 2019 at 3:52 PM Kris Zyp <kriszyp(a)gmail.com > <mailto:kriszyp@gmail.com>> wrote: > > > > For the sake of putting this in the email thread (other code > discussion in GitHub), here is the latest squashed commit of the proposed > patch (with > > the on-demand, retained overlapped array to reduce re-malloc > and opening event handles): > > > https://github.com/kriszyp/node-lmdb/commit/726a9156662c703bf3d453aab75ee22… > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --000000000000ce7c35059edab753 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Yes, I will work on upgrading this patch to 1.0.<div> <= /div><div>However, I believe in order to realize optimal Windows performanc= e without regression/slow-downs, I will also need to disable the use of NTD= LL (and use direct CreateFileMapping memory maps instead), as mentioned=C2= =A0 <a href=3D"http://www.openldap.org/lists/openldap-bugs/201902/msg00009.html= ">http://www.openldap.org/lists/openldap-bugs/201902/msg00009.html</a>. You= had mentioned in that thread that the NTDLL code wasn't destined for r= elease, is that still the case (it is still in the mdb.master branch)? If y= ou are intending to release (1.0) with the NTDLL-based memory maps (which i= s understandable, can certainly be an easier path for Windows users getting= started), I will also need to add the compiler option to disable it. Anywa= y, I will work on creating a PR with both these patches.</div><div> </di= v><div>Thanks,</div><div>Kris</div></div> <div class=3D"gmail_quote"><di= v dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 17, 2020 at 8:14 AM Howard C= hu <<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote: </d= iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord= er-left:1px solid rgb(204,204,204);padding-left:1ex">Kris Zyp wrote: > Sorry to keep pestering, but just pinging about this patch again, as I= still think this fix could benefit windows users. And at this point, I thi= nk I can say we > have tested it pretty well, running on our servers for almost a year := ). Looks like this patch is against the 0.9 release branch. I hit a bunch of c= onflicts trying to apply it to mdb.master. We'll be stopping work on 0.9 soon, a= nd getting LMDB 1.0 out the door finally, so can you please verify that your changes w= ill work on mdb.master as well? > Thanks, > Kris > > On Wed, Sep 18, 2019 at 12:56 PM Kris Zyp <<a href=3D"mailto:kriszy= p(a)gmail.com" target=3D"_blank">kriszyp(a)gmail.com</a> <mailto:<a href=3D"= mailto:kriszyp@gmail.com" target=3D"_blank">kriszyp(a)gmail.com</a>>> w= rote: > >=C2=A0 =C2=A0 =C2=A0Checking on this again, is this still a possibility= for merging into LMDB? This fix is still working great (improved performan= ce) on our systems. >=C2=A0 =C2=A0 =C2=A0Thanks, >=C2=A0 =C2=A0 =C2=A0Kris > >=C2=A0 =C2=A0 =C2=A0On Mon, Jun 17, 2019 at 1:04 PM Kris Zyp <<a hre= f=3D"mailto:kriszyp@gmail.com" target=3D"_blank">kriszyp(a)gmail.com</a> <= mailto:<a href=3D"mailto:kriszyp@gmail.com" target=3D"_blank">kriszyp@gmail= .com</a>>> wrote: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Is this still being considered/review= ed? Let me know if there are any other changes you would like me to make. T= his patch has continued to yield >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0significant and reliable performance = improvements for us, and seems like it would be nice for this to be availab= le for other Windows users. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, May 3, 2019 at 3:52 PM Kris Z= yp <<a href=3D"mailto:kriszyp@gmail.com" target=3D"_blank">kriszyp@gmail= .com</a> <mailto:<a href=3D"mailto:kriszyp@gmail.com" target=3D"_blank">= kriszyp(a)gmail.com</a>>> wrote: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For the sake of putting= this in the email thread (other code discussion in GitHub), here is the la= test squashed commit of the proposed patch (with >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the on-demand, retained= overlapped array to reduce re-malloc and opening event handles): >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"https://gith= ub.com/kriszyp/node-lmdb/commit/726a9156662c703bf3d453aab75ee222072b990f" r= el=3D"noreferrer" target=3D"_blank">https://github.com/kriszyp/node-lmdb/co= mmit/726a9156662c703bf3d453aab75ee222072b990f</a> > -- =C2=A0 -- Howard Chu =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= ct/</a> </blockquote></div> --000000000000ce7c35059edab753--

1 0

Re: (ITS#9174) Openldap configuration
by ryan＠openldap.org 18 Feb '20

18 Feb '20

Quanah already told you, in your previous ticket, where to ask for help. Please don't open more tickets as help requests. Thank you.

1 0

(ITS#9174) Openldap configuration
by biswas.raju＠gmail.com 18 Feb '20

18 Feb '20

Full_Name: Raju Biswas Version: 2.4.44 OS: RHEL7.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (103.195.203.107) My requirement is to add the posixGroup and groupofNames object class together. To achieve this, I used the link https://devopsideas.com/openldap-linux-client-ldap-integration/ I need help on this. If you need more info kindly mail me so that I can provide more information. I added the customposixGroup and then added the group as dn: cn=server_dev,ou=graylog,ou=rgroup,dc=rad,dc=com objectclass: customposixGroup objectclass: groupOfNames cn: server_dev gidNumber: 7000 description: Server Dev Group member: uid=aron.francis,ou=People,dc=rad,dc=com User added as dn: uid=aron.francis,ou=People,dc=rad,dc=comcn: aron.francis givenName: aron.francis sn: useruid: aron.francis uidNumber: 7001gidNumber: 7000 homeDirectory: /home/aron.francis objectClass: top objectClass: posixAccount objectClass: shadowAccountobjectClass: inetOrgPerson objectClass: organizationalPerson objectClass: personloginShell: /bin/bash userPassword: {SHA}Gf3pq4puDhvQ/KIgE7c1QQixnM4= memberOf: cn=server_dev,ou=graylog,ou=rgroup,dc=rad,dc=com Configured the sssduid=7001(aron.francis(a)rad.com) gid=7000 groups=7000 Help I wanted help on why the group name is not getting displayed when I use the id command from the LDAP client. But if I use posixGroup alone and not groupOfName object class then the group name is getting displayed. I need to use both posixGroup and groupOfNames [root@rad testing_dev]# ldapsearch -H ldaps:// -x -b "dc=rad,dc=com" "uid=aron.francis" "member=uid=aron.francis,ou=People,dc=rad,dc=com" # extended LDIF # # LDAPv3 # base <dc=rad,dc=com> with scope subtree # filter: uid=aron.francis # requesting: member=uid=aron.francis,ou=People,dc=rad,dc=com # # aron.francis, People, rad.com dn: uid=aron.francis,ou=People,dc=rad,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@radisys testing_dev]# ldapsearch -H ldaps:// -x -b "dc=rad,dc=com" "member=uid=aron.francis,ou=People,dc=rad,dc=com" # extended LDIF # # LDAPv3 # base <dc=rad,dc=com> with scope subtree # filter: member=uid=aron.francis,ou=People,dc=rad,dc=com # requesting: ALL # # server_dev, graylog, rgroup, rad.com dn: cn=server_dev,ou=graylog,ou=rgroup,dc=rad,dc=com objectClass: top objectClass: aposixGroup objectClass: groupOfNames cn: server_dev gidNumber: 7000 description: Server Dev Group member: uid=aron.francis,ou=People,dc=rad,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@rad testing_dev]#

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs