Found a 1vyrain advanced BIOS setting to explicitly inform the BIOS that an SSD is installed. Activated that. It seems to have helped a little, but not much.
Seeing just how much RAM Qubes alone consumes, with no apps open, I wonder if it would be a good idea to substantially increase the recommended amount of RAM for Qubes. Personally, from what I can see so far, while 16 GB is enough to run Qubes, it does not really allow one to actually use any apps of any noteworthy size. Just food for thought.
It is possible that I am completely overlooking something here, some way in which I can improve the situation that I am describing in my above posts in a meaningful way.
But I have to admit that I’m starting to lose hope that it will be possible to actually use Qubes in real life on an X230 i7 with 16 GB RAM.
The minimum that I need to be able to do is work on my mindmaps in Freeplane, and have say a dozen browser tabs open; and for both that to work without major amounts of freezing or sluggishness.
So far it doesn’t look to me like that’s possible. I am getting the feeling that I might not be able to use Qubes after all.
Running out of ideas what else I could try to make this work.
Any input on what else I could try very welcome, when you have the time.
I’ll respond to your Freeplane content later, probably in a day or two.
This normal behavior. The standard Qube/VM is configured with a minimum and maximum amount of RAM. Qubes OS defaults to assigning the max amount of RAM then dynamically decreasing Qube RAM as needed.
This is handled by the qmemman service.
To view an individual Qube’s RAM usage, you would need to use a tool running on that Qube to view system resource usage. (You might be able to get this from dom0, but I am less familiar with this aspect.) For example, instead of opening Freeplane in a Qube, select the
Run Terminal from the menu and run something like
I just made a qube with Freeplane 1.11.1-pre28 from their website.
Cloned debian-11 to debian-11-freeplane
In debian-11-freeplane use the command
sudo apt install freeplane
Download and copy the 1.11.1-pre28 deb package from the freeplane website to the debian-11-freeplane template.
Install the 1.11.1 with
sudo dpkg -i freeplane_1.11.1-pre28_upstream-1_all.deb
Make a appVM with the debian-11-freeplane as template and whonix as netvm.
Start the appVM and from the commandline you can start freeplane with the command
This worked for me.
Thank you sm95, that would be great. I’ll wait.
Btw I may tend to reply quickly, but I am only doing that so anyone who happens to have some time to read my reply and respond to it can do so when they next have the opportunity, not to imply “hey hurry up” or anything!
Also thank you for explaining that RAM management behaviour, that is helpful to know, and now that I know this, it actually makes sense.
So if I understand you correctly, Qubes assigns the maximum amount of RAM to any given VM by default, and only decreases it if and when other VMs need more RAM and thus there isn’t as much left to go around.
If I understand that correctly, the RAM usage display that I get when clicking on the blue Qubes Domains icon at the top right of screen would only tell me how much RAM each Qube is currently using, but would not be meaningful for the purpose of telling how much RAM there really is “left” for opening another additional VM, correct?
So I was using that tool try to get information that it isn’t suitable for, which is useful to know.
Hi @cayce, thank you for joining my little odyssey of figuring this out here!
Yeah I have noticed that Java is a hungry little thing.
If there was a suitable non Java alternative to Freeplane I would definitely prefer that, but there isn’t - not one that has the functionality that Freeplane has, not even close. Paralleled only by a few communication apps in importance, for me, Freeplane is pretty much the most important software that I use. There is no substitute that will do. Believe me, I have tried everything. If you are a power user of mind mapping, Freeplane completely plays in a league of its own.
So I do need to figure out a way to make Freeplane work well.
I have to admit that if RAM is the issue here in my case, and if the X230 would accept more than the 16 GB that I have already put in, I would probably throw more RAM at it as my first response - it can never hurt the machine anyway, and if that would make my problem go away, it would be worth it for me.
Alas I can’t, so yes, troubleshooting it is. Still clinging to some hope…
But does this really sound like a RAM issue to you? I’m not entirely sure anymore.
As @sm95 explained above, Qubes allocates maximum RAM to each Qube as the default, and decreases that to balance things when additional VMs get started that need more RAM.
Knowing that now, and seeing that the Freeplane VM only ever seemed to use 400 to at most 600 MB of RAM, does it really look like this freezing issue is due to lacking RAM?
Also, I have used Freeplane extensively for over ten years, frequently with very (very!) large mindmaps, and it has never been particularly RAM hungry at all, and has in fact been software that has performed extremely reliably as well, for example on Ubuntu or Mint, with 8 GB, on an X200.
What else could it be but RAM? This question is above my pay grade to answer.
I have set initial memory in the Freeplane AppVM to 600 MB, max is 6000 (inherited from its template VM that I created).
I know 6000 is very high, I just wanted to see how much Freeplane would really grab if I let it.
But the Freeplane VM has never used much more than 600 MB.
Doesn’t that suggest that this is not a RAM issue?
@cayce I don’t know if Freeplane is managing heap.
I’ll try manually specifying heap sizes as you described and report back.
@renehoj Thank you for going through the effort of setting up Freeplane yourself, I really appreciate it.
Unless I’m missing something here, that’s pretty much exactly how I have installed Freeplane on my Qubes; with the only difference being that I have usd the stable version.
If you still have it installed, can I ask whether it performs reliably if you keep creating new mindmap branches, typing a bit in them, copy/pasting random branches around in the mind map, etc, for say two or three minutes?
I am asking because at fist I also thought “awesome, Freeplane is sorted”. It started up just fine and everything looked ok, and it felt pretty snappy too. Then I started using it beyond the first few seconds, and after a minute or so the freezes started to happen.
Something you could do to test is create maybe a hundred or so individual branches in the map, simply by copy/pasting to multiply them, or something like that; and then write random stuff in a few different branches for a minute or two.
Can I also ask what the main system specs are of the machine that you have tried this on? Just so I can compare.
Thank you for your patience with me, everyone. I really appreciate it a lot. I hope you all are having a peaceful day!
I probably need to correct myself. Am I right to say that the Qubes Domains tool at the top right shows how much memory currently is allocated to each running VM, but does not give (much) information about how much memory each of those VMs actually currently needs?
So if for example the Qubes Domains tool shows that a given VM currently has e.g. 600 MB allocated, all I can derive from that is that either a) that VM is not currently needing more than 600 MB or b) 600 MB is the maximum that Qubes is currently able to allocate to that VM due to the need to balance memory between all running VMs.
Is that correct?
If so, how / where can I find out how much RAM a given VM would take / need if there were more available?
Or is the only way to find out if a VM would need more RAM by observing its behaviour and watching whether it runs well or not?
I can keep pasting the map without the application crashing.
I’m running it on a 12900K, the vm has 2 GB memory, and it was using around 1 GB.
You can use the command
free -h in the terminal to see the memory usage.
Thank you! That sounds positive.
Do you think the processor makes a major difference here?
Free -h shows 430 Mi used.
But it also shows 316 Mi swap!
If it’s using swap that would explain the constant accessing of the SSD, even when I’m not saving files and no automatic backup process of Freeplane is running (I disabled it for now).
Why would it use swap though?
As best as I can see, there seem to be three issues here:
- Freeplane is constantly very briefly accessing the SSD
Why is Freeplane constantly accessing the SSD? The hard drive light of the laptop blips for a fraction of a second at almost every single little input I make. With the exception of typing letters into map branches, every hover on a menu item, every highlighting of a branch etc make the hard drive light blip. Is this normal, and I just never saw it on the X200 because SSD access was so fast there that I didn’t see the light come on? Why would Freeplane do that though?
- Freeplane is periodically accessing SSD for about 15 seconds and freezes
Why does Freeplane seem to periodically access the SSD every few minutes for about 15 seconds when I’m not saving any mindmap and no auto save is going on either, freezing the app during that time?
- Saving Freeplane files is insanely slow and freezes as well
Why is access to the SSD so insanely slow for Freeplane? This is exclusively a problem with Freeplane: I tested saving a 40 MB text file, that took ten seconds. Saving a 40 MB mindmap takes a full two minutes, during which the app is frozen. For reference, on the X200 on Mint, saving Freeplane files of the same size took under a second or thereabouts, on this exact same SSD.
I don’t know if these are distinct separate problems, or different manifestations of the same problem. I would love to find out.
Free -h also shows total memory to be only 544 Mi for the Freeplane AppVM.
I don’t understand why that is, since initial memory is set to 600, and max memory is set to 6000 MB.
Unless this has something to do with it:
I just noticed that max memory is set to 6000 in the Freeplane template VM. But when I check in the Freplane AppVM, while max memory also reads 6000, that is greyed out.
Why is that, and does this mean it’s stuck at 600, the initial memory setting? Or does it being greyed out just mean it can’t be altered in the AppVM, only in the template VM?
One more test:
Even if I shut down all VMs except dom0 and the Freeplane AppVM (which Qubes Domains then reports to have allocated exactly 4080 and 600 MB of memory to), nothing changes at all.
To me this seems to suggest that the Freeplane freezing issue doesn’t have to do with the amount of physically installed RAM - since in this test, only 4.68 GB of the existing 16 GB RAM are actually being used.
It looks to me like there’s plenty of unused RAM, but Freeplane isn’t able to access it for some reason - and thus writes every little thing I do in Freeplane into swap on the disk - which for some (second?) reason also is extremely slow.
- SOLVED * * * * *
So through following one little clue after another I finally found the culprit, and it was… me myself. Good old fashioned user error, plus a dose of not seeing the forest for all the trees. Mea culpa…
I almost don’t want to tell you what it was because it’s such a stupid mistake to hang me up for days and keep you busy trying to help me figure out what I did wrong. But ok here it is:
In the settings of the Freeplane AppVM, I had selected 600 MB of initial memory, and 6000 GB of maximum memory… except that for some reason I had unchecked the box “include in memory balancing”.
I can not remember why I did that, I must have been trying something out there fairly early on, forgot to undo it, and never noticed that the tick was missing any time after, until just now.
The way I understand it this has led to the Freeplane AppVM being capped at the 600 MB that I had set for initial memory.
That was clearly not enough at all, so Freeplane had no other choice but to constantly do everything in swap on the SSD.
Sooo I have now set initial memory to 2000 MB and max memory at 80000 MB (because I have now observed that those numbers work well for Freeplane with my large mindmaps), and tadaa - Freeplane starts up and loads six different large mindmaps very quickly, there are no more freezes nor any sluggishness anymore, and even saving mindmaps now happens in under a second again!
I feel really stupid right now. I’m so sorry all of you that I didn’t notice this sooner!
I will pay it forward, promise.
I now believe that Qubes can actually really, truly work for me as a daily driver. This means that I will keep using it and learn more about it, and sooner or later I will inevitably start helping others to switch to Qubes. It’s the least I can do for all your efforts and patience.
I’m sure I will pop back into the forums now and then both to see if I can maybe help out a little bit anywhere with the few specific things that I may have some experience with - like X230 related matters, for example - and probably also with my own questions again now and then.
But the big killer deal breaker issue seems to be really solved now, and I can’t tell you how happy I am about that. I would have shed a few tears if I would not have been able to use Qubes, for so many reasons.
TLDR: I made a silly mistake, it took me ages to notice, the issue is solved now, and I am super super grateful for all of your support that got me here!
I hope you have a wonderful day (and if not, that you’ll kick butt anyway)!
Catch you another time again
I wanted to mark several of your answers as the solution, but apparently I can only select one, sorry! That doesn’t quite reflect your help though because a number of your answers together led me to the solution, and you helped me solve more than one thing in this thread as well. Just letting you know that I appreciate you all.
Good you solved problem.
With that out of the way I hope you find Qubes productive and worthwhile