Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
S
slash
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
uplex-varnish
slash
Commits
68c18b0e
Unverified
Commit
68c18b0e
authored
Apr 07, 2023
by
Nils Goroll
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Polish docs
parent
ea1d9548
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
with
14 additions
and
8 deletions
+14
-8
vmod_slash.man.rst
src/vmod_slash.man.rst
+7
-4
vmod_slash.vcc
src/vmod_slash.vcc
+7
-4
No files found.
src/vmod_slash.man.rst
View file @
68c18b0e
...
@@ -829,7 +829,7 @@ above values over longer time spans. But depending on how the cache is
...
@@ -829,7 +829,7 @@ above values over longer time spans. But depending on how the cache is
used and tuned, that point might well be in the region of 70% and
used and tuned, that point might well be in the region of 70% and
below.
below.
The fact that
fellow
does not, by default, attempt to use each and
The fact that
`fellow`
does not, by default, attempt to use each and
every byte of the available cache is a deliberate decision:
every byte of the available cache is a deliberate decision:
To achieve optimal disk and network I/O throughput, object data should
To achieve optimal disk and network I/O throughput, object data should
...
@@ -840,15 +840,18 @@ better option. Also, it might be better to return a smaller region
...
@@ -840,15 +840,18 @@ better option. Also, it might be better to return a smaller region
than to split a larger region, which could instead be used for a
than to split a larger region, which could instead be used for a
larger object coming in later.
larger object coming in later.
The *cram* parameter
(see `xbuddy.tune()`_) controls this trade off:
The *cram* parameter
controls this trade off: If *cram* allows a
If *cram* allows a smaller segment, it is returned, otherwise the
smaller segment, it is returned, otherwise the allocator needs to wait
allocator needs to wait
for LRU to make room.
for LRU to make room.
While higher absolute *cram* values improve space usage, they lead to
While higher absolute *cram* values improve space usage, they lead to
higher fragmentation and might negatively impact performance. Positive
higher fragmentation and might negatively impact performance. Positive
*cram* values avoid using larger free regions for smaller
*cram* values avoid using larger free regions for smaller
requests. Negative *cram* values do not.
requests. Negative *cram* values do not.
See `xbuddy.tune()`_ for additional explanations on *cram*, tuning for
`fellow` happens through `xfellowy.tune()`_.
Another factor is that the LRU algorithm pre-evicts segments and
Another factor is that the LRU algorithm pre-evicts segments and
objects from cache until ``mem_reserve_chunks`` have been reserved
objects from cache until ``mem_reserve_chunks`` have been reserved
...
...
src/vmod_slash.vcc
View file @
68c18b0e
...
@@ -750,7 +750,7 @@ above values over longer time spans. But depending on how the cache is
...
@@ -750,7 +750,7 @@ above values over longer time spans. But depending on how the cache is
used and tuned, that point might well be in the region of 70% and
used and tuned, that point might well be in the region of 70% and
below.
below.
The fact that
fellow
does not, by default, attempt to use each and
The fact that
`fellow`
does not, by default, attempt to use each and
every byte of the available cache is a deliberate decision:
every byte of the available cache is a deliberate decision:
To achieve optimal disk and network I/O throughput, object data should
To achieve optimal disk and network I/O throughput, object data should
...
@@ -761,15 +761,18 @@ better option. Also, it might be better to return a smaller region
...
@@ -761,15 +761,18 @@ better option. Also, it might be better to return a smaller region
than to split a larger region, which could instead be used for a
than to split a larger region, which could instead be used for a
larger object coming in later.
larger object coming in later.
The *cram* parameter
(see `xbuddy.tune()`_) controls this trade off:
The *cram* parameter
controls this trade off: If *cram* allows a
If *cram* allows a smaller segment, it is returned, otherwise the
smaller segment, it is returned, otherwise the allocator needs to wait
allocator needs to wait
for LRU to make room.
for LRU to make room.
While higher absolute *cram* values improve space usage, they lead to
While higher absolute *cram* values improve space usage, they lead to
higher fragmentation and might negatively impact performance. Positive
higher fragmentation and might negatively impact performance. Positive
*cram* values avoid using larger free regions for smaller
*cram* values avoid using larger free regions for smaller
requests. Negative *cram* values do not.
requests. Negative *cram* values do not.
See `xbuddy.tune()`_ for additional explanations on *cram*, tuning for
`fellow` happens through `xfellowy.tune()`_.
Another factor is that the LRU algorithm pre-evicts segments and
Another factor is that the LRU algorithm pre-evicts segments and
objects from cache until ``mem_reserve_chunks`` have been reserved
objects from cache until ``mem_reserve_chunks`` have been reserved
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment