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
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 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.
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 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.
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 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.
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@symas.com wrote:
Anyway, there's no point in speculating. Anyone interested should dig into MacOSX and find the answer there.
openldap-technical@openldap.org
-
Hallvard Breien Furuseth -
Howard Chu -
Venkat Murty