On Sat, Jan 26, 2019 at 8:03 AM Raghavendra Gowdappa
wrote:
>
>
> On Fri, Jan 11, 2019 at 8:09 PM Raghavendra Gowdappa
> wrote:
>
>> Here is the update of the progress till now:
>> * The client profile attached till now shows the tuple creation is
>> dominated by writes and fstats. Note that
On Sat, Jan 26, 2019 at 8:03 AM Raghavendra Gowdappa
wrote:
>
>
> On Fri, Jan 11, 2019 at 8:09 PM Raghavendra Gowdappa
> wrote:
>
>> Here is the update of the progress till now:
>> * The client profile attached till now shows the tuple creation is
>> dominated by writes and fstats. Note that
On Fri, Jan 11, 2019 at 8:09 PM Raghavendra Gowdappa
wrote:
> Here is the update of the progress till now:
> * The client profile attached till now shows the tuple creation is
> dominated by writes and fstats. Note that fstats are side-effects of writes
> as writes invalidate attributes of the
Here is the update of the progress till now:
* The client profile attached till now shows the tuple creation is
dominated by writes and fstats. Note that fstats are side-effects of writes
as writes invalidate attributes of the file from kernel attribute cache.
* The rest of the init phase (which
On Mon, Dec 24, 2018 at 11:30 AM Sankarshan Mukhopadhyay <
sankarshan.mukhopadh...@gmail.com> wrote:
> [pulling the conclusions up to enable better in-line]
>
> > Conclusions:
> >
> > We should never have a volume with caching-related xlators disabled. The
> price we pay for it is too high. We
On Fri 28 Dec, 2018, 12:44 Raghavendra Gowdappa
>
> On Mon, Dec 24, 2018 at 6:05 PM Raghavendra Gowdappa
> wrote:
>
>>
>>
>> On Mon, Dec 24, 2018 at 3:40 PM Sankarshan Mukhopadhyay <
>> sankarshan.mukhopadh...@gmail.com> wrote:
>>
>>> [pulling the conclusions up to enable better in-line]
>>>
>>>
On Mon, Dec 24, 2018 at 6:05 PM Raghavendra Gowdappa
wrote:
>
>
> On Mon, Dec 24, 2018 at 3:40 PM Sankarshan Mukhopadhyay <
> sankarshan.mukhopadh...@gmail.com> wrote:
>
>> [pulling the conclusions up to enable better in-line]
>>
>> > Conclusions:
>> >
>> > We should never have a volume with
On Mon, Dec 24, 2018 at 6:05 PM Raghavendra Gowdappa
wrote:
>
>
> On Mon, Dec 24, 2018 at 3:40 PM Sankarshan Mukhopadhyay <
> sankarshan.mukhopadh...@gmail.com> wrote:
>
>> [pulling the conclusions up to enable better in-line]
>>
>> > Conclusions:
>> >
>> > We should never have a volume with
On Mon, Dec 24, 2018 at 6:05 PM Raghavendra Gowdappa
wrote:
>
>
> On Mon, Dec 24, 2018 at 3:40 PM Sankarshan Mukhopadhyay <
> sankarshan.mukhopadh...@gmail.com> wrote:
>
>> [pulling the conclusions up to enable better in-line]
>>
>> > Conclusions:
>> >
>> > We should never have a volume with
On Mon, Dec 24, 2018 at 3:40 PM Sankarshan Mukhopadhyay <
sankarshan.mukhopadh...@gmail.com> wrote:
> [pulling the conclusions up to enable better in-line]
>
> > Conclusions:
> >
> > We should never have a volume with caching-related xlators disabled. The
> price we pay for it is too high. We
[pulling the conclusions up to enable better in-line]
> Conclusions:
>
> We should never have a volume with caching-related xlators disabled. The
> price we pay for it is too high. We need to make them work consistently and
> aggressively to avoid as many requests as we can.
Are there current
Hi,
I've done some tracing of the latency that network layer introduces in
gluster. I've made the analysis as part of the pgbench performance issue
(in particulat the initialization and scaling phase), so I decided to look
at READV for this particular workload, but I think the results can be
12 matches
Mail list logo
