7:05 a.m.
Why does close sometime take a long time?
mdb_env_close (in sync7320902242508427276.so) + 69 [0x112e37d35]
mdb_env_close0 (in sync7320902242508427276.so) + 248 [0x112e37948]
close (in libsystem_kernel.dylib) + 10 [0x7fff8bf900c2]
Usually, happens when I have killed the process the last time.
System: Mac OS X
Thanks,
Venkat Murty
8 a.m.
On 05/19/2014 04:05 PM, Venkat Murty wrote:
Why does close sometime take a long time?
mdb_env_close (in sync7320902242508427276.so) + 69 [0x112e37d35]
mdb_env_close0 (in sync7320902242508427276.so) + 248 [0x112e37948]
close (in libsystem_kernel.dylib) + 10 [0x7fff8bf900c2]
Usually, happens when I have killed the process the last time.
System: Mac OS X
Do you mean when the last existing process using the enviornment
is exiting? If so, that makes sense:
On BSD systems, mdb_env_close() attempts to upgrade the readlock
on the lockfile to a writelock. If that succeeds, it deletes
its semaphores since this is the last process using them.
But if you mean you killed the process, started another and then
close takes a long time, I don't know why.
--
Hallvard
8:29 a.m.
Hallvard Breien Furuseth wrote:
On 05/19/2014 04:05 PM, Venkat Murty wrote:
> Why does close sometime take a long time?
> mdb_env_close (in sync7320902242508427276.so) + 69 [0x112e37d35]
> mdb_env_close0 (in sync7320902242508427276.so) + 248 [0x112e37948]
> close (in libsystem_kernel.dylib) + 10 [0x7fff8bf900c2]
>
> Usually, happens when I have killed the process the last time.
>
> System: Mac OS X
Do you mean when the last existing process using the enviornment
is exiting? If so, that makes sense:
On BSD systems, mdb_env_close() attempts to upgrade the readlock
on the lockfile to a writelock. If that succeeds, it deletes
its semaphores since this is the last process using them.
But if you mean you killed the process, started another and then
close takes a long time, I don't know why.
It seems he's talking specifically about the close(2) syscall taking a long
time. Someone would have to peek inside the MacOSX kernel source code to
answer that question.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8:46 a.m.
On 05/19/2014 05:29 PM, Howard Chu wrote:
It seems he's talking specifically about the close(2) syscall
taking a long time. Someone would have to peek inside the MacOSX kernel source code to
answer that question.
Right... Though I can think of one non-kernel possibility:
Previous process wrote something and got killed - maybe while
fsyncing the changes. Then rapidly open and closed another mdb
env - and close(sync descriptor) waits for the old changes to be
synced in order to decide whether to return success or failure.
--
Hallvard
8:55 a.m.
Hallvard Breien Furuseth wrote:
On 05/19/2014 05:29 PM, Howard Chu wrote:
> It seems he's talking specifically about the close(2) syscall taking a
> long
time. Someone would have to peek inside the MacOSX kernel source code to
answer that question.
Right... Though I can think of one non-kernel possibility:
Previous process wrote something and got killed - maybe while
fsyncing the changes. Then rapidly open and closed another mdb
env - and close(sync descriptor) waits for the old changes to be
synced in order to decide whether to return success or failure.
That's nonsense.
POSIX defines no such behavior for close(). In particular, close()'s
success/failure result cannot depend on some other process's state.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9:22 a.m.
On 05/19/2014 05:55 PM, Howard Chu wrote:
Hallvard Breien Furuseth wrote:
> Right... Though I can think of one non-kernel possibility:
> Previous process wrote something and got killed - maybe while
> fsyncing the changes. Then rapidly open and closed another mdb
> env - and close(sync descriptor) waits for the old changes to be
> synced in order to decide whether to return success or failure.
That's nonsense.
POSIX defines no such behavior for close(). In particular, close()'s
success/failure result cannot depend on some other process's state.
There is no other process. The point would be that the system's
only descriptor to a file with outstanding syncs is being closed.
And I wasn't thinking of POSIX particular, just trying to think
of reasons an OS might want to wait in close().
But "non-kernel" I said was wrong, more like it might be found
in some spec and not just the source.
Anyway, it was just a loose guess about what to look for, I'll
survive being proved wrong:-)
--
Hallvard
9:48 a.m.
Hallvard Breien Furuseth wrote:
On 05/19/2014 05:55 PM, Howard Chu wrote:
> Hallvard Breien Furuseth wrote:
>
>> Right... Though I can think of one non-kernel possibility:
>
>> Previous process wrote something and got killed - maybe while
>> fsyncing the changes. Then rapidly open and closed another mdb
>> env - and close(sync descriptor) waits for the old changes to be
>> synced in order to decide whether to return success or failure.
>
> That's nonsense.
>
> POSIX defines no such behavior for close(). In particular, close()'s
> success/failure result cannot depend on some other process's state.
There is no other process.
You just said "previous process wrote something and got killed while fsyncing"
- so you assumed there was another process.
The point would be that the system's
only descriptor to a file with outstanding syncs is being closed.
But close() in the current process cannot report success/failure of that sync,
because the current process didn't initiate the sync. Doing so would be an
information leak, and violates the process model.
Anyway, there's no point in speculating. Anyone interested should dig into
MacOSX and find the answer there.
--
-- 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:53 p.m.
It would be stuck in the same system call for 5 mins (wall time) for a database of size
250GB.
-venkat
On May 19, 2014, at 10:18 PM, Howard Chu <hyc(a)symas.com> wrote:
Anyway, there's no point in speculating. Anyone interested should
dig into MacOSX and find the answer there.
3418
days inactive
3418
days old
openldap-technical@openldap.org
8 comments
3 participants
participants (3)
-
Hallvard Breien Furuseth -
Howard Chu -
Venkat Murty