Bitcoin is strangling my computer

[OutputKnight]

I have similar problem, computer freezes for a moment (15s) when BitCoin client is open. CPU usage is not high, physical memory is still available. What resource is it starving my poor computer of?

What o/s, cpu, and amount of ram do you have?

My low-end laptop runs particularly bad when I combine Skype, Chrome, XChat plus the Bitcoin client (on Ubuntu 11.04).  When using a different browser or without Skype and XChat running simultaneously the problem doesn't seem to occur.  I haven't upgraded to Bitcoin v0.6 yet.

Windows XP
1GB RAM but only 672 MB are used
Pentium 4 3.00 GHz buy only 5-7% are used
I use Firefox. Practically everything else is closed. That is the first thing I have done to eliminate interference.

IO that is possible. However, BitCoin should compete with other applications for IO and never get more than 50% when something else is doing IO. That should not lock up the computer.

[1713942942]

1713942942

[1713942942]

1713942942

[Foxpup]

IO that is possible. However, BitCoin should compete with other applications for IO and never get more than 50% when something else is doing IO. That should not lock up the computer.

There's no such thing as a "percentage" of disk I/O. A hard drive can physically only access one file at a time. If one program is accessing file A, and another program wants to access file B, and files A and B are both on the same disk, the second program will not be able to continue running until the first program has finished what it's doing. There's no way for each program to get "50%" of the disk, that just doesn't make sense.

[OutputKnight]

[...]
There's no such thing as a "percentage" of disk I/O. A hard drive can physically only access one file at a time. If one program is accessing file A, and another program wants to access file B, and files A and B are both on the same disk, the second program will not be able to continue running until the first program has finished what it's doing. There's no way for each program to get "50%" of the disk, that just doesn't make sense.

It is true that a hard drive can read only one allocation block at a time. However, it takes only a fraction of a second. Then it moves to serve another IO request. Reading a file consists of a lot of IO requests. You can read many files concurrently without problem. As you type, OS has dozen of different files open for reading, including registry and all dlls.

There are mechanisms in OS to prohibit concurrent modification of the same file. However, what file BitCoin is using that Windows or Firefox needs?

[Foxpup]

[...]
There's no such thing as a "percentage" of disk I/O. A hard drive can physically only access one file at a time. If one program is accessing file A, and another program wants to access file B, and files A and B are both on the same disk, the second program will not be able to continue running until the first program has finished what it's doing. There's no way for each program to get "50%" of the disk, that just doesn't make sense.

It is true that a hard drive can read only one allocation block at a time. However, it takes only a fraction of a second. Then it moves to serve another IO request. Reading a file consists of a lot of IO requests. You can read many files concurrently without problem. As you type, OS has dozen of different files open for reading, including registry and all dlls.

There are mechanisms in OS to prohibit concurrent modification of the same file. However, what file BitCoin is using that Windows or Firefox needs?

Having a file open for reading simply means that the OS will prevent other programs from trying to write to that file, and has nothing to do with the physical operation of the hard drive. The hard drive is not actually doing anything when a file is "open". It only actually reads data from the disk when the file is first opened, after that it is free to do other things. Normally it only takes a fraction of second to actually read the data, but extremely large files take a lot longer.

[nybble41]

I was having similar performance issues myself. I've been running the official Bitcoin client since the blockchain was only a hundred MB or so, and it was taking several minutes just to get past the splash screen. Defragmenting the blockchain database reduced that to a few seconds. Apparently growing a file by over a gigabyte in small increments, over a long period of time, leads to very inefficient access patterns. Who would have thought? 

Anyway, to defragment the files I just made copies of blk0001.dat and blkindex.dat in the wallet directory ($HOME/.bitcoin by default on Unix platforms), and then renamed the copies over the original files. To avoid corruption, be sure the program isn't running at the time.

[nybble41]

Having a file open for reading simply means that the OS will prevent other programs from trying to write to that file, and has nothing to do with the physical operation of the hard drive. The hard drive is not actually doing anything when a file is "open". It only actually reads data from the disk when the file is first opened, after that it is free to do other things. Normally it only takes a fraction of second to actually read the data, but extremely large files take a lot longer.

This is incorrect. Opening a file merely returns a reference to it; the contents of the file are not read into memory. At most a few blocks from the beginning of the file (at most a few MB) might be read in under the expectation that the application will ask for them next. The rest of the data is only read from the hard disk due to requests from the application. Once the data has been read into memory, future requests for the same data may not require access to the disk--but there is a limit to how much can be cached. In general, the total sizes of all the open files add up to much more than the amount RAM available to cache them. If the data isn't in the cache it will have to be re-read from the disk.

Requests from multiple applications can be interleaved, and a good I/O scheduler will make sure that requests from one application do not completely prevent other applications from accessing the disk. There will be a impact on performance, of course, since the disk is shared, and if a lot of seeking is required to access both files the slowdown can be significant compared to linear reads. Minimizing seeking by grouping nearby requests is also part of the I/O scheduler's job.

[corourke]

I noticed this too! My FPS for games was getting killed JUST running bitcoin. No mining involved. Thanks for all the useful info

[Red Emerald]

blockchain.info is a web wallet that gives you full control of the private keys if you don't want a full desktop app.

[rvbfreak]

Why is the actual bitcoin client so cumbersome?Without having the 'generate' function turned on, it seems pretty lightweight to me.

[Red Emerald]

Why is the actual bitcoin client so cumbersome?Without having the 'generate' function turned on, it seems pretty lightweight to me.

I usually find just the initial blockchain download cumbersome.  After that, my system runs fine, but I also have a pretty powerful system.

Each block has to be verified, and doing this requires a bunch of math that can slow a CPU down.