Understanding local/remote hit rate

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Understanding local/remote hit rate

abellina
Hello

I have a workload that should be completely cached in alluxio (either ram or ssd). I am running with short-circuit on, and I see my spark executors taking advantage of it as the Short-circuit Read throughput metrics indicate most of my reads are short-circuit (73% of them)

That said, the cache percentages don't seem to line up. For Alluxio local, I get 38% for the hit rate and for Alluxio Remote I get 60%. I also have a 2% miss rate.

Given most of my reads are short-circuit, shouldn't the local cache % be close to 100%?

Thanks

Alessandro

--
You received this message because you are subscribed to the Google Groups "Alluxio Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding local/remote hit rate

Andrew Audibert
Hi Alessandro,

That does sound strange. The local cache hit % is calculated by dividing total short-circuit throughput by the total number of bytes read from anywhere (local + remote + ufs). How are you calculating the 73%?

- Andrew

On Wed, Aug 22, 2018 at 9:09 AM abellina via Alluxio Users <[hidden email]> wrote:
Hello

I have a workload that should be completely cached in alluxio (either ram or ssd). I am running with short-circuit on, and I see my spark executors taking advantage of it as the Short-circuit Read throughput metrics indicate most of my reads are short-circuit (73% of them)

That said, the cache percentages don't seem to line up. For Alluxio local, I get 38% for the hit rate and for Alluxio Remote I get 60%. I also have a 2% miss rate.

Given most of my reads are short-circuit, shouldn't the local cache % be close to 100%?

Thanks

Alessandro

--
You received this message because you are subscribed to the Google Groups "Alluxio Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
--

--
You received this message because you are subscribed to the Google Groups "Alluxio Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding local/remote hit rate

abellina
Hi Andrew

I divided total read throughput from short-circuit vs remote for the last minute. I assume the cache hit rate is also for the last minute?

On Wed, Aug 22, 2018 at 11:28 AM Andrew Audibert <[hidden email]> wrote:
Hi Alessandro,

That does sound strange. The local cache hit % is calculated by dividing total short-circuit throughput by the total number of bytes read from anywhere (local + remote + ufs). How are you calculating the 73%?

- Andrew

On Wed, Aug 22, 2018 at 9:09 AM abellina via Alluxio Users <[hidden email]> wrote:
Hello

I have a workload that should be completely cached in alluxio (either ram or ssd). I am running with short-circuit on, and I see my spark executors taking advantage of it as the Short-circuit Read throughput metrics indicate most of my reads are short-circuit (73% of them)

That said, the cache percentages don't seem to line up. For Alluxio local, I get 38% for the hit rate and for Alluxio Remote I get 60%. I also have a 2% miss rate.

Given most of my reads are short-circuit, shouldn't the local cache % be close to 100%?

Thanks

Alessandro

--
You received this message because you are subscribed to the Google Groups "Alluxio Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
--

--
You received this message because you are subscribed to the Google Groups "Alluxio Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding local/remote hit rate

Andrew Audibert
Ah, that explains it. The cache hit percentages are based on total IO size, not the last minute of IO.

On Wed, Aug 22, 2018 at 9:47 AM Alessandro Bellina <[hidden email]> wrote:
Hi Andrew

I divided total read throughput from short-circuit vs remote for the last minute. I assume the cache hit rate is also for the last minute?

On Wed, Aug 22, 2018 at 11:28 AM Andrew Audibert <[hidden email]> wrote:
Hi Alessandro,

That does sound strange. The local cache hit % is calculated by dividing total short-circuit throughput by the total number of bytes read from anywhere (local + remote + ufs). How are you calculating the 73%?

- Andrew

On Wed, Aug 22, 2018 at 9:09 AM abellina via Alluxio Users <[hidden email]> wrote:
Hello

I have a workload that should be completely cached in alluxio (either ram or ssd). I am running with short-circuit on, and I see my spark executors taking advantage of it as the Short-circuit Read throughput metrics indicate most of my reads are short-circuit (73% of them)

That said, the cache percentages don't seem to line up. For Alluxio local, I get 38% for the hit rate and for Alluxio Remote I get 60%. I also have a 2% miss rate.

Given most of my reads are short-circuit, shouldn't the local cache % be close to 100%?

Thanks

Alessandro

--
You received this message because you are subscribed to the Google Groups "Alluxio Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
--
--

--
You received this message because you are subscribed to the Google Groups "Alluxio Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.