You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by 张练 <wa...@gmail.com> on 2011/03/15 04:06:34 UTC
SSD support
In https://cwiki.apache.org/TS/ssdsupport.html, we proposed our
demands.
In irc log jplevyakg proposed three ways for supporting ssd cache.
1) attach to the RAM cache to store the objects. That would be lower
CPU and would lean hard on the SSD and would use RAM to get a decent
replacement policy 2) attach to the disk as a front end cache. Again lower
CPU but use less RAM and have a poorer replacement policy. Or 3) go for
full priority queue, best replacement policy, most flexibly, but also the
most work and potentially use more CPU and a go
I was thinking the second option, i wanna select ssd as a transition
cache in sata and ram cache.
1) When an user request arrived, ts first find it in ram cache, if not
hit, then ssd, and then sata.
2) When the request was hit in ram cache or ssd, then return the object
to the user. When the request was hit in sata, then write it to ram cache
following the existing way, at the same time write it to ssd also. When the
request was not hit in all the cache, then the request was send to origin
server, and write the object back to sata.(Because our cache hierachy was
10G ram cache+100G ssd+1TB sata, so write request both in ram cache and ssd
waste at most 10% percent storage)
I reviewed the Part structure, and i think i can use Part for supporting
ssd cache. I wanna keep a special Part member in Cache, and when Cache find
an object, it first find it in ram cache, and if not hit, then find it in
this special Part member, and then the CacheHostTable member. Because i
don't wanna ts do two asynchronous read, so i wanna find the right Part and
do only one read. If not so, i thought there maybe two asynchronous read:
first find in ssd cache, and if false, go to sata. This will also change the
logic of do_cache_open_read and state_cache_open_read in HttpCacheSM.
I have seen the codes of iocore/cache for 2 weeks, but i think if i want
to understand it fully, i need another serveral weeks based on some help. If
you have a better scheme, please tell me. Right now i have to find the fast
way to support ssd asap, because we wanna to put ATS to online usage. I have
not seen the codes related with partition.config and hosting.config, and i
think if let ssd cache works with partition.config, then another more work
will be done, that will delay our plan. But the best thing i wanna do is to
implement it in an general patch for others' usage, so i wanna find a better
scheme, and do some work for current demands, and later, complete another
more demands.
--
Best regards,
Lian Zhang
Re: SSD support
Posted by 张练 <wa...@gmail.com>.
I was not watching the hash build process of the collection of structure
Part, and i think the method proposed need to be improved.
On Tue, Mar 15, 2011 at 11:06 AM, 张练 <wa...@gmail.com> wrote:
> In https://cwiki.apache.org/TS/ssdsupport.html, we proposed our
> demands.
> In irc log jplevyakg proposed three ways for supporting ssd cache.
> 1) attach to the RAM cache to store the objects. That would be lower
> CPU and would lean hard on the SSD and would use RAM to get a decent
> replacement policy 2) attach to the disk as a front end cache. Again lower
> CPU but use less RAM and have a poorer replacement policy. Or 3) go for
> full priority queue, best replacement policy, most flexibly, but also the
> most work and potentially use more CPU and a go
> I was thinking the second option, i wanna select ssd as a transition
> cache in sata and ram cache.
> 1) When an user request arrived, ts first find it in ram cache, if not
> hit, then ssd, and then sata.
> 2) When the request was hit in ram cache or ssd, then return the object
> to the user. When the request was hit in sata, then write it to ram cache
> following the existing way, at the same time write it to ssd also. When the
> request was not hit in all the cache, then the request was send to origin
> server, and write the object back to sata.(Because our cache hierachy was
> 10G ram cache+100G ssd+1TB sata, so write request both in ram cache and ssd
> waste at most 10% percent storage)
> I reviewed the Part structure, and i think i can use Part for
> supporting ssd cache. I wanna keep a special Part member in Cache, and when
> Cache find an object, it first find it in ram cache, and if not hit, then
> find it in this special Part member, and then the CacheHostTable member.
> Because i don't wanna ts do two asynchronous read, so i wanna find the right
> Part and do only one read. If not so, i thought there maybe two asynchronous
> read: first find in ssd cache, and if false, go to sata. This will also
> change the logic of do_cache_open_read and state_cache_open_read in
> HttpCacheSM.
> I have seen the codes of iocore/cache for 2 weeks, but i think if i
> want to understand it fully, i need another serveral weeks based on some
> help. If you have a better scheme, please tell me. Right now i have to find
> the fast way to support ssd asap, because we wanna to put ATS to online
> usage. I have not seen the codes related with partition.config and
> hosting.config, and i think if let ssd cache works with partition.config,
> then another more work will be done, that will delay our plan. But the best
> thing i wanna do is to implement it in an general patch for others' usage,
> so i wanna find a better scheme, and do some work for current demands, and
> later, complete another more demands.
>
> --
> Best regards,
> Lian Zhang
>
>
--
Best regards,
Lian Zhang
Re: SSD support
Posted by 张练 <wa...@gmail.com>.
Thank you, John. The Part keeps two Directory, it explains them as Directory
A and Directory B, each one contain a header of type PartHeaderFooter, a
group of Dir, and a footer of type PartHeaderFooter. I can't understand why
Part need to keep two Directories? What is each one's usage?
On Tue, Mar 15, 2011 at 11:41 PM, John Plevyak <jp...@acm.org> wrote:
> #2 is a very viable option and could be implemented relatively easily.
>
> Here is my proposal. Do not attempt to write full objects into the SSD,
> instead use it like the RAM cache as a fragment cache. The semantics
> of a fragment cache are much easier (i.e. just a simple hash table rather
> than having to ensure that all the fragments of an object are present and
> deleted together, as well as handling the HTTP header vector and groups
> of objects).
>
> Leverage the existing index and directory code for the hash table for the
> SSD. On a fragment hit on disk, write to the SSD. Leave the RAM cache
> alone.
>
> If you write to the RAM cache for every write you will blow it out and
> it will be completely and utterly useless. You might as well throw it
> away. Unless the hot set that fits in RAM (and hence no need for
> a SSD or HD at all) and the RAM cache will get a 0% hit rate.
>
> There is a "hit evacuate" feature which may or may not be fully implemented
> which already has some of the logic... I"ll look into that.
>
> john
>
>
>
> On Mon, Mar 14, 2011 at 8:06 PM, 张练 <wa...@gmail.com> wrote:
>
> > In https://cwiki.apache.org/TS/ssdsupport.html, we proposed our
> > demands.
> > In irc log jplevyakg proposed three ways for supporting ssd cache.
> > 1) attach to the RAM cache to store the objects. That would be lower
> > CPU and would lean hard on the SSD and would use RAM to get a decent
> > replacement policy 2) attach to the disk as a front end cache. Again
> lower
> > CPU but use less RAM and have a poorer replacement policy. Or 3) go for
> > full priority queue, best replacement policy, most flexibly, but also the
> > most work and potentially use more CPU and a go
> > I was thinking the second option, i wanna select ssd as a transition
> > cache in sata and ram cache.
> > 1) When an user request arrived, ts first find it in ram cache, if not
> > hit, then ssd, and then sata.
> > 2) When the request was hit in ram cache or ssd, then return the
> object
> > to the user. When the request was hit in sata, then write it to ram cache
> > following the existing way, at the same time write it to ssd also. When
> the
> > request was not hit in all the cache, then the request was send to origin
> > server, and write the object back to sata.(Because our cache hierachy was
> > 10G ram cache+100G ssd+1TB sata, so write request both in ram cache and
> ssd
> > waste at most 10% percent storage)
> > I reviewed the Part structure, and i think i can use Part for
> supporting
> > ssd cache. I wanna keep a special Part member in Cache, and when Cache
> find
> > an object, it first find it in ram cache, and if not hit, then find it in
> > this special Part member, and then the CacheHostTable member. Because i
> > don't wanna ts do two asynchronous read, so i wanna find the right Part
> and
> > do only one read. If not so, i thought there maybe two asynchronous read:
> > first find in ssd cache, and if false, go to sata. This will also change
> > the
> > logic of do_cache_open_read and state_cache_open_read in HttpCacheSM.
> > I have seen the codes of iocore/cache for 2 weeks, but i think if i
> want
> > to understand it fully, i need another serveral weeks based on some help.
> > If
> > you have a better scheme, please tell me. Right now i have to find the
> fast
> > way to support ssd asap, because we wanna to put ATS to online usage. I
> > have
> > not seen the codes related with partition.config and hosting.config, and
> i
> > think if let ssd cache works with partition.config, then another more
> work
> > will be done, that will delay our plan. But the best thing i wanna do is
> to
> > implement it in an general patch for others' usage, so i wanna find a
> > better
> > scheme, and do some work for current demands, and later, complete another
> > more demands.
> >
> > --
> > Best regards,
> > Lian Zhang
> >
>
--
Best regards,
Lian Zhang
Re: SSD support
Posted by John Plevyak <jp...@acm.org>.
#2 is a very viable option and could be implemented relatively easily.
Here is my proposal. Do not attempt to write full objects into the SSD,
instead use it like the RAM cache as a fragment cache. The semantics
of a fragment cache are much easier (i.e. just a simple hash table rather
than having to ensure that all the fragments of an object are present and
deleted together, as well as handling the HTTP header vector and groups
of objects).
Leverage the existing index and directory code for the hash table for the
SSD. On a fragment hit on disk, write to the SSD. Leave the RAM cache
alone.
If you write to the RAM cache for every write you will blow it out and
it will be completely and utterly useless. You might as well throw it
away. Unless the hot set that fits in RAM (and hence no need for
a SSD or HD at all) and the RAM cache will get a 0% hit rate.
There is a "hit evacuate" feature which may or may not be fully implemented
which already has some of the logic... I"ll look into that.
john
On Mon, Mar 14, 2011 at 8:06 PM, 张练 <wa...@gmail.com> wrote:
> In https://cwiki.apache.org/TS/ssdsupport.html, we proposed our
> demands.
> In irc log jplevyakg proposed three ways for supporting ssd cache.
> 1) attach to the RAM cache to store the objects. That would be lower
> CPU and would lean hard on the SSD and would use RAM to get a decent
> replacement policy 2) attach to the disk as a front end cache. Again lower
> CPU but use less RAM and have a poorer replacement policy. Or 3) go for
> full priority queue, best replacement policy, most flexibly, but also the
> most work and potentially use more CPU and a go
> I was thinking the second option, i wanna select ssd as a transition
> cache in sata and ram cache.
> 1) When an user request arrived, ts first find it in ram cache, if not
> hit, then ssd, and then sata.
> 2) When the request was hit in ram cache or ssd, then return the object
> to the user. When the request was hit in sata, then write it to ram cache
> following the existing way, at the same time write it to ssd also. When the
> request was not hit in all the cache, then the request was send to origin
> server, and write the object back to sata.(Because our cache hierachy was
> 10G ram cache+100G ssd+1TB sata, so write request both in ram cache and ssd
> waste at most 10% percent storage)
> I reviewed the Part structure, and i think i can use Part for supporting
> ssd cache. I wanna keep a special Part member in Cache, and when Cache find
> an object, it first find it in ram cache, and if not hit, then find it in
> this special Part member, and then the CacheHostTable member. Because i
> don't wanna ts do two asynchronous read, so i wanna find the right Part and
> do only one read. If not so, i thought there maybe two asynchronous read:
> first find in ssd cache, and if false, go to sata. This will also change
> the
> logic of do_cache_open_read and state_cache_open_read in HttpCacheSM.
> I have seen the codes of iocore/cache for 2 weeks, but i think if i want
> to understand it fully, i need another serveral weeks based on some help.
> If
> you have a better scheme, please tell me. Right now i have to find the fast
> way to support ssd asap, because we wanna to put ATS to online usage. I
> have
> not seen the codes related with partition.config and hosting.config, and i
> think if let ssd cache works with partition.config, then another more work
> will be done, that will delay our plan. But the best thing i wanna do is to
> implement it in an general patch for others' usage, so i wanna find a
> better
> scheme, and do some work for current demands, and later, complete another
> more demands.
>
> --
> Best regards,
> Lian Zhang
>