Difference between revisions of "Page server"
(started) |
(moar good contents) |
||
| Line 3: | Line 3: | ||
== Rationale == | == Rationale == | ||
| − | For process tree migration, the biggest part of transfer data is the memory used by the processes. Therefore, optimizing this memory transfer would | + | For process tree migration, the biggest part of transfer data is the memory used by the processes. Therefore, optimizing this memory transfer would be beneficial. |
| + | [[Image:Memory_migration_without_page_server.png|thumb|500px|right|Memory migration without page server]] | ||
Without the page server, migrating the user memory pages consists of: | Without the page server, migrating the user memory pages consists of: | ||
| − | * dumping the memory to files on disk; | + | * dumping (writing) the memory to files on disk; |
| − | * | + | * reading the files and sending the data over the network to the destination host; |
| + | * receiving files on the destination host, writing to files on disk; | ||
* restoring by reading the files into memory. | * restoring by reading the files into memory. | ||
| − | + | In other words, all the memory is written to the disk twice, and read from the disk also twice. It incurs significant I/O overhead and slows down the migration. The overhead is further multiplied when using <code>criu pre-dump</code> (such as for [[iterative migration]]), as in this case memory is dumped not once but a few times. | |
| + | |||
| + | A way to mitigate the disk I/O overhead is to use [[wikipedia:tmpfs|tmpfs]], a filesystem that use RAM as a storage (see [[Disk-less migration]] for details). This eliminates the disk I/O, but not the double read/write. To eliminate it, a page server mechanism was implemented. | ||
| + | <br clear="both"/> | ||
== Operation == | == Operation == | ||
| − | + | [[Image:Memory_migration_with_page_server.png|thumb|500px|right|Memory migration with page server]] | |
| + | When using page server, the memory is dumped not to disk, but directly to network, thus eliminating any disk reads/writes on the source. On the destination system, a page server runs, receiving the data from network and writing it to files on disk or tmpfs. | ||
| + | |||
| + | === Pages deduplication === | ||
| + | |||
| + | When iterative memory dumping feature (<code>criu pre-dump</code>) is used, memory is sent to page server a few times. The page server can automatically deduplicate pages, by punching holes in a parent images where child is replacing the page. This functionality is turned on by <code>--auto-dedup</code> option of <code>criu page-server</code> command. | ||
| + | <br clear="both"/> | ||
| + | |||
| + | == Usage == | ||
| + | |||
| + | See https://asciinema.org/a/15847. | ||
| + | |||
| + | == See also == | ||
| + | |||
| + | * [[P.Haul]] | ||
| + | * [[Live migration]] | ||
| + | * [[Lazy migration]] | ||
| + | |||
| + | == External links == | ||
| + | |||
| + | * Using page server: https://asciinema.org/a/15847 | ||
[[Category: HOWTO]] | [[Category: HOWTO]] | ||
[[Category: Development]] | [[Category: Development]] | ||
Revision as of 00:27, 30 August 2016
Page server is a component of CRIU that allows to copy (rather than dump) user memory to a destination system during the course of live migration. It is also used for lazy migration.
Rationale
For process tree migration, the biggest part of transfer data is the memory used by the processes. Therefore, optimizing this memory transfer would be beneficial.
Without the page server, migrating the user memory pages consists of:
- dumping (writing) the memory to files on disk;
- reading the files and sending the data over the network to the destination host;
- receiving files on the destination host, writing to files on disk;
- restoring by reading the files into memory.
In other words, all the memory is written to the disk twice, and read from the disk also twice. It incurs significant I/O overhead and slows down the migration. The overhead is further multiplied when using criu pre-dump (such as for iterative migration), as in this case memory is dumped not once but a few times.
A way to mitigate the disk I/O overhead is to use tmpfs, a filesystem that use RAM as a storage (see Disk-less migration for details). This eliminates the disk I/O, but not the double read/write. To eliminate it, a page server mechanism was implemented.
Operation
When using page server, the memory is dumped not to disk, but directly to network, thus eliminating any disk reads/writes on the source. On the destination system, a page server runs, receiving the data from network and writing it to files on disk or tmpfs.
Pages deduplication
When iterative memory dumping feature (criu pre-dump) is used, memory is sent to page server a few times. The page server can automatically deduplicate pages, by punching holes in a parent images where child is replacing the page. This functionality is turned on by --auto-dedup option of criu page-server command.
Usage
See https://asciinema.org/a/15847.
See also
External links
- Using page server: https://asciinema.org/a/15847