Building requires >1GB memory #6658
Comments
|
I don't think an ICE is really our concern. I assume clang manages ok? |
|
Hmm? I'd say it being impossible to build Bitcoin Core by default on many VPSes is our concern. On September 11, 2015 12:24:16 AM EDT, Cory Fields notifications@github.com wrote:
|
|
Internal Compiler Errot
|
|
@TheBlueMatt Try using CXXFLAGS="--param ggc-min-expand=1 --param ggc-min-heapsize=32768" |
|
The ICE in question is OOM killer eating g++. On September 11, 2015 12:29:35 AM EDT, Pieter Wuille notifications@github.com wrote:
|
|
@luke-jr: I can get it to build fine (--disable-tests), I just care that we fix the actual issue. On September 11, 2015 12:31:36 AM EDT, Luke-Jr notifications@github.com wrote:
|
|
I'd be concerned if no compiler could build on that VPS. However, I'd be willing to bet that it's just a matter of an inefficient gcc version. If clang dies the same way, I'll buy you a beer this weekend :) |
|
@TheBlueMatt Memory use is not an issue, if it correctly builds with the appropriate CXXFLAGS... IMO |
|
This is a default gcc on a relatively recent Debian. I really don't think the response to "I can't build Bitcoin Core on a vps with 1GB of memory with default parameters" should be "oh, but if you set these flags you can!" On September 11, 2015 12:34:57 AM EDT, Cory Fields notifications@github.com wrote:
|
|
0.11 does require more RAM and in my experience |
|
Any instrumentation on why script_test takes so much memory? Would prefer to discern "why" before taking any action. In general we should be able to build Bitcoin Core on a 1GB VPS. |
|
Y'all being overly pedantic. Matt identified a usability problem: User obtains and attempts to compile the software with normal instructions on a common and reasonable platform type, and it crashes. If you want to suggest that the docs should have instructions with low mem cflags or whatnot, OKAY, but without that it doesn't stop being an issue because just us experts can work around it. Our memory usage is kind of obnoxious during compile time IMO, and if we could do some minor tweaks to reduce the peak that would be nice too-- but at the very least we should provide some instructions. |
|
This is actually known and documented: https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#system-requirements (feel free to add the recommendation for low-memory build flags tho!) I would have expected that no longer using boost::spirit (for JSON) and boost::asio (for RPC) would reduce compilation memory usage - unfortunate to hear that it became worse. Anyhow: cross compilation and pseudo-static compilation is extremely easy with the depends system, I'd recommend using that. |
|
Oh wait, the compilation of that file uses more than 1GB of memory? |
|
Yes, the VPS in question has a total of 1.5GB memory (1GB ram + .5 swap), and nothing else of note was running at the time. |
|
I measured using gcc 4.8.4 (64 bit): Top 10 memory usage during build:
Will try with clang some other time. |
|
Same information, but for clang 3.6.0 (also 64-bit):
The contenders are the (mostly) same, although it is faster and uses significantly less memory in all cases. So we should add a recommendation to use clang on lower-memory systems. |
|
I'm not sure why it is this "bad". Possibly it has to do with embedding the test data as includes: |
|
@laanwj I suspect you're right about the test data. Maybe older gcc re-reads that each time it's needed and balloons in size as a result. @TheBlueMatt Could you test with theuni@1a107da and see if that helps? That moves the test data into cpps instead. |
|
Hmm, the VPS has since been upgraded to have more memory (yay pruning means I get more memory and less disk space...) and doesnt kill script_tests anymore :( What may have been happening is the host may have been retroactively killing processes after some other process had casued the VM to hit some high memory bar. In any case, it is just Debian Jessie, so gcc 4.9.2-10. |
|
Still, main max resident of 1.2GB will probably not build on most VPSes today, but sadly thats a harder one to fix, and probably a very long-term thing. |
|
Rather than recommending clang (which would send more hosts into a less tested and potentially consensus inconsistent config) we could recommend compiler flags that reduce memory usage. |
|
I ran a comparison test yesterday measuring the peak memory consumption of the Bash shell session in which I was working. gcc - 835 MB, clang - 823 MB (32-bit Raspbian OS). Not a big saving. (I don't know how @laanwj measured RAM consumption, otherwise I would have used his approach). People low on RAM could use binary builds if they don't have enough RAM to build, or build without tests. Not everyone should be able to build from source on their system (or, in most hosting environments, they can upsize their RAM, build, and then downsize?). |
|
@gmaxwell Possibly both - we're using clang for OSX builds already, so it's not that much of an unknown. I've switched to clang for my run-of-the-mill builds on Linux to save time. @cfields The solution in https://stackoverflow.com/questions/5479691/is-there-any-standard-way-of-embedding-resources-into-linux-executable-image to use the which can just be compiled with @unsystemizer see https://gist.github.com/laanwj/108877a28ec03836568a In general I recommend to use cross-compiling to build for resource-constrained systems. This a) avoids having a compiler toolchain on the target b) is much faster c) Bitcoin Core's depends system makes this easy. |
|
After tripping up on this initially, I succeeded in applying Luke-jr's On a Raspberry Pi 2 building with a single core: The memory use seemed to stay below 500 MB throughout, but I didn't measure |
|
I'm looking at Armian builds, since I might as well just build the rest of the OS - and sync the chain - along with cross compiling bitcoind :-) |
|
Considering that Should I create a pull for this? |
@gmaxwell said above:
|
|
well if clang, a compiler many, many people use, generates consensus incompatible code, bitcoin has a huge problem. (to be clear, no, I don't think this is an issue worrying about here - let's focus on finding configurations that reduce memory usage) |
|
To be honest, I myself use clang (along with ccache) but that's only because all my work involves running in regtest, so I don't have to worry about consensus compatibility. |
|
I mean, it might have been a good argument in 2012, but at this point, many platforms are clang-only (MacOSX, FreeBSD, OpenBSD, at least). There's nothing that binds bitcoin to gcc specifically. |
|
Just wanted to leave an update here, that building Bitcoin Core v0.16.2 is possible¹ on Raspberry Pi Zero W, which has 512MB RAM + default of 100MB SWAP. ¹ It did take a very long time. |
|
@meeDamian hahaha nice, that's quite a thing, building with less than a GB RAM+SWAP |
|
As noted in this issue we are currently using significantly more compile-time memory than we technically have to. I plan to address this and you can see steps being taken in #16273 and #16278 (the latter is a subset of the former limited to tests only). People who care about compile-time memory usage might be interested in reviewing those PR:s :-) |
|
These are the 25 worst offenders in terms of compile-time memory usage:
Measured using |
|
People interested in enabling builds on low memory machines might be interested in reviewing and testing #16312:
|
|
Chasing {concept,approach} ACK/NACKs for #16331 which tackles this issue. Let me know if this issue is no longer relevant :-) |
|
It doesn't seem that proposed solutions to this attract much, or any
attention. Most notably, no one building on 1GB menory systems seems to be
helping testing.
So my conclusion would be it's either not relevant anymore or very very low
priority, and will only become less so as systems with so little menory
become rarer.
Sorry for the wasted effort :/
…On Sat, Aug 10, 2019, 09:00 practicalswift ***@***.***> wrote:
Chasing concept ACK or NACKs for #16331
<#16331> which tackles this issue.
Let me know if this issue is no longer relevant :-)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6658?email_source=notifications&email_token=AAA65NSZXEEQVXG6PXRHVK3QDZRPLA5CNFSM4BPNRUDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4AHRHA#issuecomment-520124572>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAA65NVIG2C2TOST5EDXBCTQDZRPLANCNFSM4BPNRUDA>
.
|
|
I'm not sure if I'm not missing something here, but bitcoind was already building on RBP zero (512MB ram with just 100MB swap). Plus, I've just built v0.18.1 on RBP3 (1GB ram, no swap) a few days ago without problems even before applying any PRs. It does take its time, however 😅. So I for once, am not sure what else/how to test? |
|
@meeDamian does the new PR work without those extra config flags? |
|
It is a bit concerning that the unit test have to be disabled to compile on low memory machines |
|
On a fresh Raspbian on RBP3, running (with or without Crashes with: Running the same on bitcoin |
|
Actually… bitcoin |
|
@meeDamian did you try with |
|
I'm afraid |
fa7789f doc: Mention other ways to conserve memory on compilation (MarcoFalke) Pull request description: Related to: * Building requires >1GB memory #6658 ACKs for top commit: instagibbs: ACK fa7789f kristapsk: ACK fa7789f Tree-SHA512: 828593de9cfa9f9027c6c8e97abe95e3fad9f2ff50e6512808a8950de4a1f9ea901e724edfb96d7119224c3e38a136e60cb798b34ef682c585a7951e02124a3a
|
The docs are updated and mention that |
CXX test/test_test_bitcoin-script_tests.o
g++: internal compiler error: Killed (program cc1plus)
script_tests requires more than 1GB memory to build, killing a lot of VMs.
The text was updated successfully, but these errors were encountered: