Java Heap Space - Qubes #3343
Comments
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
This issue has been automatically closed because of inactivity. Feel free to reopen it if you think it is still relevant. |
ripcurlx
added
is:priority
|
My previous comment can be ignored, I successfully synced a new bisq from scratch and the only requirement is to set Max Memory for the Qube to 6GB and make sure that you have enough memory free. |
|
I confirm this now works (even with max memory for the qube of 4 GB) So I'd say this issue can be closed. |
Update the gradle dependency to JavaFX 14. This brings to Bisq the latest JavaFX fixes and improvements, especially in the areas of UI performance, memory management and security. JavaFX can be upgraded independently of the JDK used to build the application, so this change is modular and does not affect other parts of the build process. Related / likely related to: bisq-network#350 bisq-network#2135 bisq-network#2509 bisq-network#3128 bisq-network#3307 bisq-network#3308 bisq-network#3343 bisq-network#3430 bisq-network#3657 bisq-network#3677 bisq-network#3683 bisq-network#3686 bisq-network#3786 bisq-network#3787 bisq-network#3892 bisq-network#3917 bisq-network#3918 bisq-network#3936
|
6GB should not be needed. 1-2 GB should be more then enough. I guess it is some JVM confirm issue with Qubes and some Linux versions (Arch users report often of those issues). |
|
Can you try out the recommendations at #3918 (comment) ? |
|
@chimp1984 for Qubes, the memory reservation is for the entire OS + applications. I believe it also covers for video RAM, since Qubes has very basic graphics drivers. If a Qube is setup with some RAM limit, and then if the qube reaches the limit, by default Qubes will "borrow" memory from other VMs (or from the unallocated dom0 RAM) and expand dynamically as necessary. However, to do this, it has a service that pings / checks / adjusts the memory allocation every second, which actually slows Bisq down according to my tests. Turns out its better to disable this dynamic memory allocation and just set a high enough value for the entire qube, to cover OS + any service + any application (incl. Bisq). After some experimentation, the settings in #4386 were the most stable and reliable for me. Also, increasing resources beyond that didn't improve Bisq performance (load times, UI responsiveness etc) so those values seem to be the sweet spot. So for Qubes, I'd say 6GB (and with no dynamic memory mgmt) is probably the best option for a debian Qube that runs only Bisq. Of course, would be great if others can test and verify this as well, on their setups. |
Update the gradle dependency to JavaFX 14. This brings to Bisq the latest JavaFX fixes and improvements, especially in the areas of UI performance, memory management and security. JavaFX can be upgraded independently of the JDK used to build the application, so this change is modular and does not affect other parts of the build process. Related / likely related to: bisq-network#350 bisq-network#2135 bisq-network#2509 bisq-network#3128 bisq-network#3307 bisq-network#3308 bisq-network#3343 bisq-network#3430 bisq-network#3657 bisq-network#3677 bisq-network#3683 bisq-network#3686 bisq-network#3786 bisq-network#3787 bisq-network#3892 bisq-network#3917 bisq-network#3918 bisq-network#3936
Closing, as issue is now fixed for OP. For more details about running Bisq on Qubes, see https://bisq.wiki/Running_Bisq_on_Qubes |
Version: 1.1.7 and 0.8.0
OS: Both Debian 9 and Fedora 30
RAM: Up to 4GB, initial set max to 2GB
Log: https://anonfile.com/X8Z2ed78n7/bisq_log
The text was updated successfully, but these errors were encountered: