[
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.
