> If I understood brick-multiplexing correctly, add-brick/remove-brick
> add/remove graphs right? I don't think the grah-cleanup is in good
> shape, i.e. it should lead to memory leaks etc. Did you get a chance
> to think about it?
I haven't tried to address memory leaks specifically, but most of
> That's weird, since the only purpose of the mem-pool was precisely to
> improve performance of allocation of objects that are frequently
> allocated/released.
Very true, and I've long been an advocate of this approach.
Unfortunately, for this to work our allocator has to be more efficient
than t
Jeff,
If I understood brick-multiplexing correctly,
add-brick/remove-brick add/remove graphs right? I don't think the
grah-cleanup is in good shape, i.e. it should lead to memory leaks etc. Did
you get a chance to think about it?
On Mon, Sep 19, 2016 at 6:56 PM, Jeff Darcy wrote:
> I hav
On 19/09/16 15:26, Jeff Darcy wrote:
I have brick multiplexing[1] functional to the point that it passes all basic
AFR, EC, and quota tests. There are still some issues with tiering, and I
wouldn't consider snapshots functional at all, but it seemed like a good point
to see how well it work
- Original Message -
> From: "Jeff Darcy"
> To: "Gluster Devel"
> Sent: Monday, September 19, 2016 6:56:39 PM
> Subject: [Gluster-devel] Multiplexing - good news, bad news, and a plea for
> help
>
> I have brick multiplexing[1] functional to
> I wonder if we are spending more time in io-threads. Does setting
> idle-time in io-threads to 1 help with anything?
> It might be useful to add instrumentation subsequently to dump
> statistics (number of fops serviced, time spent in servicing) per
> thread. Having the same visibility for our ep
On Mon, Sep 19, 2016 at 2:20 PM, Jeff Darcy wrote:
> FWIW, I did some further experiments. Disabling mem-pool entirely (in favor
> of plain malloc/free) brought run time down to 3:35, vs. 2:57 for the exact
> same thing without multiplexing. Somehow we're still not managing contention
> very
FWIW, I did some further experiments. Disabling mem-pool entirely (in favor of
plain malloc/free) brought run time down to 3:35, vs. 2:57 for the exact same
thing without multiplexing. Somehow we're still not managing contention very
well at this kind of thread count, but the clues and opportu
On 09/19/2016 11:34 PM, Jeff Darcy wrote:
I would like to collaborate in investigating the memory-management, and
also bringing multiplexing to snapshots. For starters, will be going
through your patch(1400+ lines of change, that's one big ass patch :p)
That's nothing. I've seen 7000-line patch
> I would like to collaborate in investigating the memory-management, and
> also bringing multiplexing to snapshots. For starters, will be going
> through your patch(1400+ lines of change, that's one big ass patch :p)
That's nothing. I've seen 7000-line patches go in, without even any
evidence of
On 09/19/2016 06:56 PM, Jeff Darcy wrote:
I have brick multiplexing[1] functional to the point that it passes all basic
AFR, EC, and quota tests. There are still some issues with tiering, and I
wouldn't consider snapshots functional at all, but it seemed like a good point
to see how well it w
I have brick multiplexing[1] functional to the point that it passes all basic
AFR, EC, and quota tests. There are still some issues with tiering, and I
wouldn't consider snapshots functional at all, but it seemed like a good point
to see how well it works. I ran some *very simple* tests with 2
12 matches
Mail list logo