New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 792564 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

ContainerId serialization/unserialization seems to take a long time

Project Member Reported by kenobi@chromium.org, Dec 6 2017

Issue description

Anecdotally, the operations of serialization and deserializing the ContainerId when creating Container objects to represent new or existing LXC containers, seems to be slow.

Potential sources of slowness:
- pickle
- to ensure atomicity, IDs are pickled into a temp file and then moved into the container, which necessitates a call to utils.run and involves sudo.


 

Comment 1 by kenobi@chromium.org, Dec 14 2017

Performance is pretty much the same between pickle and json.  It looks to me like the problem isn't the serialization per se, it's the auxiliary code around it for ensuring atomicity and using sudo.

- if I remove the 'sudo' from the serialization/unserialization code, it cuts the runtime in less than half (~1 sec to ~0.4 secs for a save/load cycle)
- if I remove the atomicity requirement (i.e. serialize/deserialize directly in-place rather than to a tmp file and mv-ing it) it speeds things up even more (~0.0006 secs for a save/load cycle)

Comment 2 by kenobi@chromium.org, Dec 14 2017

Well... okay.  json is about twice as fast.

Across 10000 iterations (each iteration is saving and then loading an ID):
pickle - Runtime: 3.853029 (0.000385 per iteration)
json - Runtime: 1.823873 (0.000182 per iteration)

It probably doesn't matter here since we're talking tens of containers.  But json has the added advantage of being human-readable in serialized form.  I'll use that.

Comment 3 by dshi@chromium.org, Dec 14 2017

The atomicity requirement seems to be the main bottleneck. Instead of create the file in temp and call mv, which is an external process, can we just apply a lock on the id file and edit it directly? That should still give us the atomicity while better performance.

Comment 4 by kenobi@chromium.org, Dec 14 2017

Owner: kenobi@chromium.org
Status: Started (was: Untriaged)
I'll do the pythonic thing of asking for forgiveness rather than permission.

No atomicity, just read the file.  If any errors occur we'll treat it as no ID.  That will yield identical behaviour to the current atomic code.
Project Member

Comment 5 by bugdroid1@chromium.org, Dec 15 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/c510e01ce96c2281aadd03bd4b2784be377307d1

commit c510e01ce96c2281aadd03bd4b2784be377307d1
Author: Ben Kwa <kenobi@google.com>
Date: Fri Dec 15 07:57:34 2017

[autotest] Optimize LXC continer IDs.

- Create container directories before lxc-clone is called - this ensures
  that containers belong to the running process and not root.

- Remove sudo and tmpfile auxiliary code around container ID
  serialization - it is no longer needed.  This reduces ID serialization
  times.

- Switch from pickle to json.  The latter is marginally quicker, but
  more importantly it yields a human-readable file.

BUG= chromium:792564 
TEST=container_unittest.py
TEST=container_factory_unittest.py
TEST=lxc_functional_test.py
TEST=Check lxc_pool_service.py, ensure it starts, runs, and shuts down.

Change-Id: Icd04ac6f6d3a8c53441f7005b4a837f826e6dba9
Reviewed-on: https://chromium-review.googlesource.com/827942
Commit-Ready: Jacob Kopczynski <jkop@chromium.org>
Tested-by: Ben Kwa <kenobi@chromium.org>
Reviewed-by: Dan Shi <dshi@google.com>

[modify] https://crrev.com/c510e01ce96c2281aadd03bd4b2784be377307d1/site_utils/lxc/container.py

Comment 6 by kenobi@chromium.org, Dec 22 2017

Status: Fixed (was: Started)

Sign in to add a comment