Slows down Mac even when nice'd & not generating (?!)

[Osndok]

I'm not sure why, but my computer noticably slows down whenever I have bitcoin open (and it is not set to be generating bitcoins as far as I can tell). I've even re-niced the process using the terminal, but it is still has a noticable effect when just browsing the internet or opening/closing windows.

Other things I've noticed (not sure if related?), bitcoin...
* takes a long time to startup
* draws it's own apple-menu (with associated weirdness in using it)
* takes a long time to quit
* often will have a crash report come up (after telling it to quit)

Any similar experiences here?

Could the slow-down be from it using the graphics card or network? Is the network usage throttled?

[1714118409]

1714118409

[1714118409]

1714118409

[1714118409]

1714118409

[1714118409]

1714118409

[1714118409]

1714118409

[MoonShadow]

Could the slow-down be from it using the graphics card or network? Is the network usage throttled?

Not really, but you might have too many connections open.  If your not generating, you don't need more than a few connections open.  Try limiting your connections and prohibiting outside connections.

And using the graphics card should only effect things if you are generating with the graphics card.

[Osndok]

I don't see an obvious way to limit the number of network connections. 

[Osndok]

Well... I've done some digging and might have narrowed it down.

When bitcoin is exhibiting this slow-down behavior, it appears to be requesting something from the "DirectoryService" process (user name, reading a plist?). I'm not positive asto how to read these stack traces, but the issue seems to be within this block of code (perhaps it is running a lot more often then anticipated, contention over dbenv, or the db system is making ineffecient use of some DirectoryService).

[I'll try to attach the process samples]

Does anyone else use bitcoin on a Mac?

Code:

void CDB::Close()
{
    if (!pdb)
        return;
    if (!vTxn.empty())
        vTxn.front()->abort();
    vTxn.clear();
    pdb = NULL;

    // Flush database activity from memory pool to disk log
    unsigned int nMinutes = 0;
    if (strFile == "addr.dat")
        nMinutes = 2;
    if (strFile == "blkindex.dat" && IsInitialBlockDownload() && nBestHeight % 500 != 0)
        nMinutes = 1;
    dbenv.txn_checkpoint(0, nMinutes, 0);

    CRITICAL_BLOCK(cs_db)
        --mapFileUseCount[strFile];
}

[Osndok]

To clarify a bit....

Whenever bitcoin is running, it takes up 100% of one core, and DirectoryService takes up 50% of the other. So only 1/4 of the cpu power is available for anything else. Once bitcoin is quit, everything returns to 0%. 100% reproducible.

[Osndok]

btw... does anyone know where I can find the function "~wxMessageOutputDebug()", or what it does?

[Gavin Andresen]

When bitcoin is exhibiting this slow-down behavior, it appears to be requesting something from the "DirectoryService" process (user name, reading a plist?). I'm not positive asto how to read these stack traces, but the issue seems to be within this block of code (perhaps it is running a lot more often then anticipated, contention over dbenv, or the db system is making ineffecient use of some DirectoryService).

Is your Library/Application Data/ directory on a network-mounted volume?

Running bitcoin 0.3.13 on my OSX 10.6.4 Mac I'm not seeing any issues (it uses almost zero CPU when it is not generating, and 100%, but nice'ed, when it is).  I don't see any DirectoryService CPU usage.

From what you've said, it looks like disk writes are chewing up lots of CPU time for some odd reason.

[Osndok]

I think you hit rather close to the mark. I have FileVault enabled (which encrypts the home directory). But I would still not expect to see such a problem.

On a whim, I replaced the "debug.log" with a symlink out of the home folder. Not only did the problem vanish, but bitcoin nearly-instantly caught up in the chain!

I'd bet that the debug mechanism is running fsync() for every log entry, when it should never sync at all (it's a bug!).

[Osndok]

Apparently the debug file is closed after *every* printf (causing a flush, and on my system a bunch on crypto overhead).

Since FileVault is a standard option on a Mac, I recommend either not closing the file (os will clean it up), or disabling debugging to a file on macs.

Example patch attached...

Is there a bug tracker for bitcoin?

[davout]

I symlink'd the debug.log to /dev/null

[Gavin Andresen]

Apparently the debug file is closed after *every* printf (causing a flush, and on my system a bunch on crypto overhead).

Since FileVault is a standard option on a Mac, I recommend either not closing the file (os will clean it up), or disabling debugging to a file on macs.

Hmmm....

At some point (bitcoin 0.9?) debug.log should contain only really critical errors/warnings.  Right now it is more of a trace.log.

Flushing it after every write is the correct thing to do-- otherwise critical information about what caused a crash could easily be lost.

Always closing and re-opening it is darn convenient if you've got a log-rotating script running... but working poorly with FileVault is definitely a bug.

[Osndok]

Flushing it after every write is the correct thing to do-- otherwise critical information about what caused a crash could easily be lost.

If this is truly the reasoning behind this pattern I think it's a bit paranoid. The sync-on-every-write isolation is for when the machine crashes or loses power, applications for this might be a database log or filesystem journal; and in those cases they generally write a page at a time for efficiency.

To the best of my understanding the OS will close every open file in the event of a program crash. You see this behaviour all the time with errant programs (they print an error or usage statement then quit). Said another way, the buffer in question is the file system cache (not a cache within user space), wherefrom the os serves multiply-opened files, etc. The OS will periodically sync this cache anyway.

Always closing and re-opening it is darn convenient if you've got a log-rotating script running... but working poorly with FileVault is definitely a bug.

Yes, it does make the code very compact and readable; but I think the proper way to do this would be to either rotate the open file descriptors, or perform a flush-copy-truncate on the open log file.

Is there a way to ensure the developers catch wind of this?

[Gavin Andresen]

Is there a way to ensure the developers catch wind of this?

You already did.

[MoonShadow]

Yes, it does make the code very compact and readable; but I think the proper way to do this would be to either rotate the open file descriptors, or perform a flush-copy-truncate on the open log file.

Is there a way to ensure the developers catch wind of this?

Gavin is one of the developers, I believe.  And more involved in the forum than Satoshi himself.  If anyone can get action for this, I'm sure that it's him.

[manofconstantsorrow]

I am experiencing the same issue. Is there still no fix for this?

[Jessy Kang]

I am experiencing the same issue. Is there still no fix for this?

Same here, slows everything to a crawl. And I'm not much for command line...