Discuss.FOLIO.org is no longer used. This is a static snapshot of the website as of February 14, 2023.

The issue of FOINO consuming virtual machine memory

kzeng
11 Oct '21

Hi team,

Who can tell me how much memory it takes to run the full-featured version of FOLIO (folio-release-v1.0.0-20210928.7046) in the VM?

I’ve allocated 13GB of memory and the module still doesn’t seem to be fully booted.

The foolowing is my Vagrantfile, allocate 13 GB memory

config.vm.provider "virtualbox" do |v|
  v.memory = 13312
  v.cpus = 2
end

Show memory on VM:

vagrant@vagrant:~$ free -h
              total        used        free      shared  buff/cache   available
Mem:           12Gi        12Gi       148Mi        37Mi       336Mi       222Mi
Swap:         979Mi       260Mi       719Mi

Thanks,
Kai

ncovercash
12 Oct '21

folio/snapshot@5.0.0-20211011.7110 takes about 4-5 GB:

              total        used        free      shared  buff/cache   available
Mem:           19Gi       4.3Gi        13Gi        33Mi       1.3Gi        14Gi
Swap:         979Mi          0B       979Mi

If you’re having issues with it “fully booting,” note that it often takes a few minutes for everything to get fully up and running, even once the system itself has booted. Does Stripes show at all for you (localhost:3000 on the host)?

I’ve also had some issues where the Vagrant box will not fully boot to the OS, so if that’s what you mean (although I doubt it since you can access the shell to run free), I found the issue has something to do with cryptography/RNG stalling the kernel. Not sure what the issue is, I’d imagine something super niche to my setup, but if you’re experiencing something like this where Vagrant insists it didn’t boot, try starting it in VirtualBox first to avoid the timeouts (be sure to do it headless (shift + clicking the Start button), otherwise you won’t be able to close it).

Even the little bit of entropy from having the console open there can get it un-stuck.

The release version doesn’t use much memory either, only a few gigs:

              total        used        free      shared  buff/cache   available
Mem:           11Gi       2.9Gi       7.3Gi        35Mi       1.4Gi       8.5Gi
Swap:         979Mi          0B       979Mi
ncovercash
12 Oct '21

Try using sudo ps aux --sort=-pmem | head -n 12 to list running processes in order of memory usage (the first twelve lines, as not to have a huge output). That might help narrow down the module causing issues.

kzeng
13 Oct '21

Hi ncovercash,

  • Yes, I can access localhost: 3000, just wait a long time and can’t log in.
  • I started the shell through vagrant ssh, I will try to boot from VirtualBox.

Thank you for giving so much good advice, I’ll keep trying.
Thank you.

ncovercash
13 Oct '21

Gotcha. If you haven’t, let it sit for a solid five or ten minutes when accessing localhost:3000 – I found it took that long on my workstation for everything to get initialized (it was giving weird HTTP errors when trying to login otherwise)

kzeng
13 Oct '21

You are right ! :grinning_face_with_smiling_eyes: :grinning_face_with_smiling_eyes: :grinning_face_with_smiling_eyes:

zburke
13 Oct '21

Anecdotally, when running a local VM, I watch my CPU monitor and wait for it to settle before attempting to login. It’s not scientific, but it’s been a useful rule of thumb.

I run Stats on macOS to show a CPU sparkline in the menubar. The Windows Performance Monitor, minimized, used to display similarly in the start bar IIRC.

kzeng
13 Oct '21

Monitor the cpu, memory occupancy until the modules are fully started, which is a good experience.

I have a way too, to share it.

In Chrome browser, open the http://localhost:3000 page, refresh the login page, open Chrome-> devtools->Inspect, if http://localhost:9130 request no errors.

This is login should be no problem.