go
/
gvisor
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Drop confusing kvm-bare syscall time 

The difference is only due to different machines.
This commit is contained in:
Adin Scannell 2019-05-13 15:12:03 -07:00 committed by Adin Scannell
parent 5b3f25047f
commit 9ea68ce165
2 changed files with 7 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
content/docs/architecture_guide/performance.md
View File

@ -85,22 +85,21 @@ For many use cases, fixed memory overheads are a primary concern. This may be
because sandboxed containers handle a low volume of requests, and it is
therefore important to achieve high densities for efficiency.
{{< graph id="density" url="/performance/density.csv" title="perf.py density --runtime=runc --runtime=runsc" log="true" y_min="100000">}}
{{< graph id="density" url="/performance/density.csv" title="perf.py density --runtime=runc --runtime=runsc" log="true" y_min="100000" >}}
The above figure demonstrates these costs based on three sample applications.
This test is the result of running many instances of a container (typically 50)
and calculating available memory on the host before and afterwards, and dividing
the difference by the number of containers.
> Note: the above technique is used for measuring memory usage over the
> `usage_in_bytes` value of the container cgroup because we found that some
> container runtimes, other than `runc` and `runsc` do not use an individual
> container cgroup.
the difference by the number of containers. This technique is used for measuring
memory usage over the `usage_in_bytes` value of the container cgroup because we
found that some container runtimes, other than `runc` and `runsc`, do not use an
individual container cgroup.
The first application is an instance of `sleep`: a trivial application that does
nothing. The second application is a synthetic `node` application which imports
a number of modules and listens for requests. The third application is a similar
synthetic `ruby` application which does the same. In all cases, the sandbox
synthetic `ruby` application which does the same. Finally, we include an
instance of `redis` storing approximately 1GB of data. In all cases, the sandbox
itself is responsible for a small, mostly fixed amount of memory overhead.
## CPU performance

1
static/performance/syscall.csv
View File

@ -2,4 +2,3 @@ runtime,metric,result
runc,syscall_time_ns,1939.0
runsc,syscall_time_ns,38219.0
runsc-kvm,syscall_time_ns,763.0
runsc-kvm-bare,syscall_time_ns,455.0
1 runtime metric result
2 runc syscall_time_ns 1939.0
3 runsc syscall_time_ns 38219.0
4 runsc-kvm syscall_time_ns 763.0
runsc-kvm-bare syscall_time_ns 455.0