| Title: | X.500 Directory Services |
| Notice: | Sprt: FORTY2::X500_SUPPORT, Kits: 216.*, try dir/titl=OFFICIAL |
| Moderator: | FORTY2::PULLEN |
| Created: | Tue Jan 30 1990 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1016 |
| Total number of notes: | 4299 |
I have the impression that a memory leak exists within X500 V3.1.5.
I monitored the amount of virtual memory size occupied by dxd_dsad
each hour and I noticed that dxd_dsad is using more and more memory
every day (3Mb each day).
All the customer is doing is binding to a specific DSA server,
requesting needed attributes and unbind.
Is some info cached or not released ? or memory leak ??
Anything I can trace ??
Dany
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1009.1 | a-103.tunnel.crl.dec.com::FORTY2::PALKA | Andrew Palka Altavista Directory | Thu May 22 1997 16:00 | 16 | |
There is one known leak. This happens when a password is checked when it needs to do the password check the slow way (by generating a DAP message). You can look at the counters to see if this is happening. You would observe the 'compare operations' counter is increasing. Each time one of these compare operations is performed the DSA loses 4k bytes. (There may be other, perfectly normal, compare operations done which do not cause a leak). In the case which we have seen we are not sure why the dsa is trying to do a DAP compare operation to check the password. The normal code path can do this much more efficiently by directly accessing the database. Andrew | |||||
| 1009.2 | password is checked | BACHUS::CUYT | Fri May 23 1997 12:43 | 0 | |
| 1009.3 | password is checked | BACHUS::CUYT | Fri May 23 1997 12:44 | 10 | |
There is a password check for each users that uses the X500 based
application. I changed my monitor procedure to include the compare
operations counter and noticed already after 1 hour that the amount
of virtual memory and the amount of compare operations are
increasing.
I guess the leak I see is the one you mentioned in .1
Should I open an IPMT case or are there already patches available ??
Dany
| |||||
| 1009.4 | a-103.tunnel.crl.dec.com::FORTY2::PALKA | Andrew Palka Altavista Directory | Fri May 23 1997 15:18 | 16 | |
I dont think it is worth raising an IPMT case. This is a known problem, and a fix should be included in the next ECO kit (I've no idea when this will be !) There is one thing that is puzzling us. We dont know why these requests are following the code path which includes the memory leak. They should be using a much more efficient code path. It would help if you could trace a single sequence with ncl> test dsa command "set trace osul=15,access=15,auth=15, thread=15,update=15" (all on one line of course!) Andrew | |||||