[ceph-users] Bluestore + erasure coding memory usage

2016-11-02 Thread bobobo1...@gmail.com
I'm running Kraken built from Git right now and I've found that my OSDs eat as much memory as they can before they're killed by OOM. I understand that Bluestore is experimental but thought the fact that it does this should be known. My setup: - Xeon D-1540, 32GB DDR4 ECC RAM - Arch Linux - Single

Re: [ceph-users] Bluestore + erasure coding memory usage

2016-11-04 Thread bobobo1...@gmail.com
> Then you can view the output data with ms_print or with massif-visualizer. > This may help narrow down where in the code we are using the memory. Done! I've dumped the output from ms_print here: http://ix.io/1CrS It seems most of the memory comes from here: 92.78% (998,248,799B) (heap alloca

Re: [ceph-users] Bluestore + erasure coding memory usage

2016-11-07 Thread bobobo1...@gmail.com
Just bumping this and CCing directly since I foolishly broke the threading on my reply. On 4 Nov. 2016 8:40 pm, "bobobo1...@gmail.com" wrote: > > Then you can view the output data with ms_print or with > massif-visualizer. This may help narrow down where in the code we are

Re: [ceph-users] Bluestore + erasure coding memory usage

2016-11-08 Thread bobobo1...@gmail.com
sterday. Any chance you could run > this for longer? It's tough to tell what's going on from this run > unfortunately. Maybe overnight if possible. > > Thanks! > Mark > > > > On 11/08/2016 01:10 AM, bobobo1...@gmail.com wrote: > >> Just bumping this a

Re: [ceph-users] Bluestore + erasure coding memory usage

2016-11-08 Thread bobobo1...@gmail.com
e OSD is up to 4+GB RSS if > you can. I usually kill the valgrind/osd process with SIGTERM to make sure > the output is preserved. Not sure what will happen with OOM killer as I > haven't let it get that far before killing. > > Mark > > On 11/08/2016 10:37 AM, bob

Re: [ceph-users] Bluestore + erasure coding memory usage

2016-11-08 Thread bobobo1...@gmail.com
Ah, I was actually mistaken. After running without Valgrind, it seems I just estimated how slowed down it was. I'll leave it to run overnight as suggested. On Tue, Nov 8, 2016 at 10:44 PM, bobobo1...@gmail.com wrote: > Okay, I left it for 3h and it seemed to actually stabilise at aroun

Re: [ceph-users] Bluestore + erasure coding memory usage

2016-11-09 Thread bobobo1...@gmail.com
Here it is after running overnight (~9h): http://ix.io/1DNi On Tue, Nov 8, 2016 at 11:00 PM, bobobo1...@gmail.com wrote: > Ah, I was actually mistaken. After running without Valgrind, it seems > I just estimated how slowed down it was. I'll leave it to run > overnight as suggest

Re: [ceph-users] Bluestore + erasure coding memory usage

2016-11-11 Thread bobobo1...@gmail.com
Any more data needed? On Wed, Nov 9, 2016 at 9:29 AM, bobobo1...@gmail.com wrote: > Here it is after running overnight (~9h): http://ix.io/1DNi > > On Tue, Nov 8, 2016 at 11:00 PM, bobobo1...@gmail.com > wrote: >> Ah, I was actually mistaken. After running without Valgrind,

Re: [ceph-users] Bluestore + erasure coding memory usage

2016-11-11 Thread bobobo1...@gmail.com
Here's another: http://termbin.com/smnm On Fri, Nov 11, 2016 at 1:28 PM, Sage Weil wrote: > On Fri, 11 Nov 2016, bobobo1...@gmail.com wrote: >> Any more data needed? >> >> On Wed, Nov 9, 2016 at 9:29 AM, bobobo1...@gmail.com >> wrote: >> > Here it is af

Re: [ceph-users] Bluestore + erasure coding memory usage

2016-11-18 Thread bobobo1...@gmail.com
Just to update, this is still an issue as of the latest Git commit ( 64bcf92e87f9fbb3045de49b7deb53aca1989123). On Fri, Nov 11, 2016 at 1:31 PM, bobobo1...@gmail.com wrote: > Here's another: http://termbin.com/smnm > > On Fri, Nov 11, 2016 at 1:28 PM, Sage Weil wrote: > >

Re: [ceph-users] Bluestore + erasure coding memory usage

2016-12-17 Thread bobobo1...@gmail.com
they're restarted, they start at ~1G instead of 500M. On Fri, Nov 18, 2016 at 6:32 PM, bobobo1...@gmail.com wrote: > Just to update, this is still an issue as of the latest Git commit > (64bcf92e87f9fbb3045de49b7deb53aca1989123). > > On Fri, Nov 11, 2016 at 1:31 PM, bobobo1