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
used and tuned, that point might well be in the region of 70% and
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:
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
than to split a larger region, which could instead be used for a
larger object coming in later.
The *cram* parameter
(see `xbuddy.tune()`_) controls this trade off:
If *cram* allows a smaller segment, it is returned, otherwise the
allocator needs to wait
for LRU to make room.
The *cram* parameter
controls this trade off: If *cram* allows a
smaller segment, it is returned, otherwise the allocator needs to wait
for LRU to make room.
While higher absolute *cram* values improve space usage, they lead to
higher fragmentation and might negatively impact performance. Positive
*cram* values avoid using larger free regions for smaller
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
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
used and tuned, that point might well be in the region of 70% and
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:
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
than to split a larger region, which could instead be used for a
larger object coming in later.
The *cram* parameter
(see `xbuddy.tune()`_) controls this trade off:
If *cram* allows a smaller segment, it is returned, otherwise the
allocator needs to wait
for LRU to make room.
The *cram* parameter
controls this trade off: If *cram* allows a
smaller segment, it is returned, otherwise the allocator needs to wait
for LRU to make room.
While higher absolute *cram* values improve space usage, they lead to
higher fragmentation and might negatively impact performance. Positive
*cram* values avoid using larger free regions for smaller
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
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