You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by "Leif Hedstrom (JIRA)" <ji...@apache.org> on 2009/11/13 00:46:39 UTC
[jira] Created: (TS-33) Make the 8GB disk cache partioning
configurable
Make the 8GB disk cache partioning configurable
-----------------------------------------------
Key: TS-33
URL: https://issues.apache.org/jira/browse/TS-33
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Right now, we split the disk cache up into 8GB chunks (which implies 8GB cache evictions). This might not be optimal for all applications, some might want to make it a lot smaller (e.g. with a smaller SSD disk), some maybe even bigger. Making this configurable, via records.config, would be very useful.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-33) Make the 8GB disk cache partioning
configurable
Posted by "John Plevyak (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778499#action_12778499 ]
John Plevyak commented on TS-33:
--------------------------------
I don't think this implies 8bg evictions. I think it implies 8gb max document size though.
Reducing the size is easy, making it bigger has some further implications.
Without reorganizing the directory increasing the size would be easiest if we used a
larger block size (eventually disks will be using a block size of 4096 in any case)
or reduced the number of bits used to prevent collisions
Currently the block size is hard coded (eek) in P_CachePart.h even
though it is detected correctly in Store.XX. It is hard coded at 512 which will
not work forever as disks are already coming out at 4096 and the industry
has indicated that that is where they want to be.
Since the directory addresses by block, increasing the block size would increase
the possible partition size while increasing the minimum write size. Using a
block size of 4096 would increase possible partition size to 64 GB. We should
probably support this in any case.
Alternatively, we currently allocate 12 bits against an 8 way associative cache
for the collision tag resulting in a (max) .4% collision rate, each of which results in
an unnecessary seek. We could steal bits to increase partition size.
Finally, we could reorganize the directory. I would do this as a last resort.
I am not sure where this should be specified, perhaps in storage.config or parititon.config.
Probably storage.config as it would be a function of the physical device.
That fine needs help as the comments are ancient: 8gb disks... wow
> Make the 8GB disk cache partioning configurable
> -----------------------------------------------
>
> Key: TS-33
> URL: https://issues.apache.org/jira/browse/TS-33
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Leif Hedstrom
>
> Right now, we split the disk cache up into 8GB chunks (which implies 8GB cache evictions). This might not be optimal for all applications, some might want to make it a lot smaller (e.g. with a smaller SSD disk), some maybe even bigger. Making this configurable, via records.config, would be very useful.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (TS-33) Make the 8GB disk cache partioning
configurable
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom closed TS-33.
---------------------------
Resolution: Invalid
Closing this, since it's pointless. :)
> Make the 8GB disk cache partioning configurable
> -----------------------------------------------
>
> Key: TS-33
> URL: https://issues.apache.org/jira/browse/TS-33
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Leif Hedstrom
>
> Right now, we split the disk cache up into 8GB chunks (which implies 8GB cache evictions). This might not be optimal for all applications, some might want to make it a lot smaller (e.g. with a smaller SSD disk), some maybe even bigger. Making this configurable, via records.config, would be very useful.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-33) Make the 8GB disk cache partioning
configurable
Posted by "John Plevyak (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778565#action_12778565 ]
John Plevyak commented on TS-33:
--------------------------------
Given that keys are hashed to a partition and each partition has its own write position,
it makes more sense to minimize the number of partiitons.
In order to reach current and projected disk sizes we will need to increase the current directory
entry size from 8 bytes to 10 bytes. That will allow partitions of 0.5PB which should be sufficient
given that you can have a bunch of those.
So, the new proposal is:
10 byte directory entries
not configurable, just use the max size possible
> Make the 8GB disk cache partioning configurable
> -----------------------------------------------
>
> Key: TS-33
> URL: https://issues.apache.org/jira/browse/TS-33
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Leif Hedstrom
>
> Right now, we split the disk cache up into 8GB chunks (which implies 8GB cache evictions). This might not be optimal for all applications, some might want to make it a lot smaller (e.g. with a smaller SSD disk), some maybe even bigger. Making this configurable, via records.config, would be very useful.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.