Newbie questions about performance

I am a LastPass refugee and Bitwarden newbie. :slight_smile:

I’m converting a family LP subscription to a self-hosted Bitwarden environment running in an Ubuntu VM behind HAProxy using the standard Docker deployment.

The virtualization environment is somewhat constrained and it’s not my favorite hypervisor (QEMU). So, I have some performance tuning questions on which I would appreciate any feedback or wisdom the community cares to provide.

  • Assume no premium features. Do I need to run these containers: bitwarden/sso and bitwarden/attachments? Are there others that I might be able to shed?
  • If I don’t need them, is docker-compose.override.yml the right place to set restart: no?
  • The doc recommends 4GB when using Ubuntu. As you can see in the image below, an 8GB VM with no Bitwarden users active and one account has consumed ~7GB. I’ve noticed that even at 8GB when cold starting SQL Server grabs a ton of memory. One would expect the system to “setttle” a bit after that. But as this shows after running for over 24 hours, that hasn’t happened. What is a realistic memory allocation for a lightly-used (three or four account) deployment?

  • Are there any “knobs” one can play with to try to improve performance?

Thanks.

Hi
i suggest use Light version of bitwarden:

Probably use much less resources.

Thanks.

But I’ll pass for now. It’s in beta and we are new users.

1 Like

If you haven’t used MS SQL Server before, this sort of behaviour may seem strange, but MSSQL is a deliberate resource hog. I learned this when I setup my first organizational instance of MSSQL on a Xeon server with 32 GB of memory - SQL Server took nearly all of it! But it does a good job of releasing that memory if it is needed elsewhere on the system. Typically, SQL Server will use as much as 1 GB less than your total memory, if it can get its hands on it.

I have installed BW Server using the standard docker stack twice - once on an 4GB VM and once on my Linux home server with 8GB RAM. In both instances, SQL Server consumed all the memory it could get its hands on up to about the last GB. I have also run it on a 2GB VM with no issues, although there wasn’t much RAM leftover.

My advice to the OP is to drop your VMs virtual RAM down to 4GB and see how it does. My guess is that it will use about 3GB ram at rest almost all of the time.

Thanks.

One reason I like Bitwarden is because it uses SQL Server. I am very familiar with SQL Server on Windows Server. I work with it at clients all the time.

The question I was really asking – and didn’t do too well explaining – was, is what I am seeing the classic Windows SQL Server behavior (grab all available memory) something one should encourage when in a container (slow virtualization) inside a Linux VM on QEMU (even slower virtualization) on a slow machine?

IOW, while the system requirements say 4GB is more really a good thing (as long as we don’t start swapping)?

I am not a Bitwarden employee or developer, so I can only guess, but the standard Bitwarden server stack was designed for production servers, particularly in enterprise environments. That’s where Bitwarden Inc. makes its money, I suspect.

They have been very kind to also allow any home user or small organization to deploy the same resources for free, but I guess that comes at a cost - you are running enterprise-grade software to support one or perhaps a handful of users, and that’s overkill. But it is free software after all.

What is great is that Bitwarden has decide to cater to that SOHO crowd now by developing their server software as the Bitwarden Unified container installation. This is the lightweight, easy to deploy and maintain package that is meant for the non-enterprise users. As mentioned above, it is in beta release right now, so you will have to wait for it, unfortunately. However, there seems to be lots of good feedback across the web that, if using MSSQL for the db engine, the beta release performs well and is very stable, as long as you are not trying to run enterprise features (e.g., SSO auth).