Hi Dustin, All,
01.12.2017 02:15, Dustin Wenz пишет:
> bhyve will quickly grow to use all available system memory
I'd say that some logs/stats/values should help here.
JFYI: I've just got a success importing of an earth base
OSM/nominatim/postgis at bhyve guest (CentOS-7.3, 14 CPU,
36GB RAM, 1T
On 01/12/2017 13:43, Allan Jude wrote:
> On 2017-11-30 22:10, Dustin Wenz wrote:
>> I am using a zvol as the storage for the VM, and I do not have any ARC
>> limits set. However, the bhyve process itself ends up grabbing the vast
>> majority of memory.Â
>>
>> I’ll run a test tomorrow to get the
2017-12-01 17:53 GMT+08:00 Shane Ambler :
> On 01/12/2017 13:43, Allan Jude wrote:
> > On 2017-11-30 22:10, Dustin Wenz wrote:
> >> I am using a zvol as the storage for the VM, and I do not have any ARC
> >> limits set. However, the bhyve process itself ends up grabbing the vast
> >> majority of m
Here's the top -uS output from a test this morning:
last pid: 57375; load averages: 8.29, 7.02, 4.05
On 12/01/2017 12:42, Dustin Wenz wrote:
> Here's the top -uS output from a test this morning:
>
> last pid: 57375; load averages: 8.29, 7.02, 4.05
>
>
bargs -A -H -P -S
The -S flag to bhyve wires guest memory so it won't be swapped out.
later,
Peter.
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To
Yep, and that's also why bhyve is getting killed instead of paging out. For
some inexplicable reason, chyves defaulted to setting -S on new VMs. That has
the effect of wiring in the max amount of memory for each guest at startup.
I changed the bargs option to "-A -H -P" instead of "-A -H -P -S".
I've been running a database stress test on my VMs for the last few hours
without issue, and I've noticed no unexpected memory usage. Prior to changing
the wired option, this would never have run as long. I haven't limited the ARC
size yet, but I probably will since it sounds like best practice
On 02/12/2017 08:11, Dustin Wenz wrote:
>
> The commit history shows that chyves defaults to -S if you are
> hosting from FreeBSD 10.3 or later. I'm sure they had a reason for
> doing that, but I don't know what that would be. It seems to an
> inefficient use of main memory if you need to run a l
One thing to watch out for with chyves if your virtual disk is more
than 20G is the fact that it uses 512 byte blocks for the zvols it
creates. I ended up using up 1.4TB only half filling up a 250G zvol.
Chyves is quick and easy, but it's not exactly production ready.
-M
On Thu, Nov 30, 2017 at
> On 02/12/2017 08:11, Dustin Wenz wrote:
> >
> > The commit history shows that chyves defaults to -S if you are
> > hosting from FreeBSD 10.3 or later. I'm sure they had a reason for
> > doing that, but I don't know what that would be. It seems to an
> > inefficient use of main memory if you nee
On Fri, Dec 1, 2017 at 20:02 Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > On 02/12/2017 08:11, Dustin Wenz wrote:
> > >
> > > The commit history shows that chyves defaults to -S if you are
> > > hosting from FreeBSD 10.3 or later. I'm sure they had a reason for
> > > doing tha
I have noticed significant storage amplification for my zvols; that could very
well be the reason. I would like to know more about why it happens.
Since the volblocksize is 512 bytes, I certainly expect extra cpu overhead (and
maybe an extra 1k or so worth of checksums for each 128k block in th
On Fri, Dec 1, 2017 at 9:23 PM, Dustin Wenz wrote:
> I have noticed significant storage amplification for my zvols; that could
> very well be the reason. I would like to know more about why it happens.
>
> Since the volblocksize is 512 bytes, I certainly expect extra cpu overhead
> (and maybe an e
14 matches
Mail list logo
