Bitcoin Forum
September 25, 2016, 02:00:33 PM *
News: Latest stable version of Bitcoin Core: 0.13.0 (New!) [Torrent]. Make sure you verify it.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Slows down Mac even when nice'd & not generating (?!)  (Read 1476 times)
Osndok
Newbie
*
Offline Offline

Activity: 8


View Profile
October 13, 2010, 06:27:57 PM
 #1


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?
1474812033
Hero Member
*
Offline Offline

Posts: 1474812033

View Profile Personal Message (Offline)

Ignore
1474812033
Reply with quote  #2

1474812033
Report to moderator
1474812033
Hero Member
*
Offline Offline

Posts: 1474812033

View Profile Personal Message (Offline)

Ignore
1474812033
Reply with quote  #2

1474812033
Report to moderator
1474812033
Hero Member
*
Offline Offline

Posts: 1474812033

View Profile Personal Message (Offline)

Ignore
1474812033
Reply with quote  #2

1474812033
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1474812033
Hero Member
*
Offline Offline

Posts: 1474812033

View Profile Personal Message (Offline)

Ignore
1474812033
Reply with quote  #2

1474812033
Report to moderator
1474812033
Hero Member
*
Offline Offline

Posts: 1474812033

View Profile Personal Message (Offline)

Ignore
1474812033
Reply with quote  #2

1474812033
Report to moderator
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
October 13, 2010, 06:37:25 PM
 #2



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.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
Osndok
Newbie
*
Offline Offline

Activity: 8


View Profile
October 13, 2010, 07:29:30 PM
 #3

I don't see an obvious way to limit the number of network connections.  Huh
Osndok
Newbie
*
Offline Offline

Activity: 8


View Profile
October 27, 2010, 06:50:25 PM
 #4

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
Newbie
*
Offline Offline

Activity: 8


View Profile
October 27, 2010, 06:56:54 PM
 #5

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
Newbie
*
Offline Offline

Activity: 8


View Profile
October 27, 2010, 06:59:48 PM
 #6

btw... does anyone know where I can find the function "~wxMessageOutputDebug()", or what it does?
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
October 27, 2010, 08:28:32 PM
 #7

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.

How often do you get the chance to work on a potentially world-changing project?
Osndok
Newbie
*
Offline Offline

Activity: 8


View Profile
October 28, 2010, 09:55:52 PM
 #8

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
Newbie
*
Offline Offline

Activity: 8


View Profile
November 03, 2010, 09:17:16 PM
 #9


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
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
November 03, 2010, 09:41:14 PM
 #10

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

Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
November 03, 2010, 11:04:28 PM
 #11

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.

How often do you get the chance to work on a potentially world-changing project?
Osndok
Newbie
*
Offline Offline

Activity: 8


View Profile
November 04, 2010, 04:31:37 PM
 #12

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
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
November 05, 2010, 04:31:31 PM
 #13

Is there a way to ensure the developers catch wind of this?
You already did.

How often do you get the chance to work on a potentially world-changing project?
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
November 05, 2010, 06:19:02 PM
 #14


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.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
manofconstantsorrow
Newbie
*
Offline Offline

Activity: 1


View Profile
June 09, 2011, 07:30:11 AM
 #15

I am experiencing the same issue. Is there still no fix for this?
Jessy Kang
Newbie
*
Offline Offline

Activity: 28



View Profile WWW
June 15, 2011, 09:50:58 AM
 #16

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...
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!