1. Overview

Dynimize is a user mode program that quickly optimizes the in-memory machine code of target processes based on profiling information it gathers at run-time, thereby improving performance for some workloads. Dynimize typically runs as a background system process and does not require the source code of target programs that it optimizes.

---

2. Installation & Quick Start

To install Dynimize, run the following commands in a Linux terminal.




Use your access token to start a subscription license for your host.




To optimize any CPU intensive process who's exe is listed in the [exeList] section of /etc/dyni.conf, run:




The command dyni -status will show target processes progressing from the "profiling", to "dynimizing", and then "dynimized" states. A process has been fully optimized once in the "dynimized" state:











Dynimize can be shutdown with the following command:



If Dynimize is shutdown, all dynimized processes will remain dynimized.


To "undynimize" all dynimized processes, run



or alternatively restart the dynimized process. For example, the following command can restart the mysqld process for MySQL:




To cancel a subscription license for a given host, run the following command on that host:




To uninstall Dynimize, run:




Read this tutorial for help measuring the performance impact.

---

3. System Requirements

  •  x86-64 Linux Kernel version 2.6.32 or later

  •  4GB virtual memory (swap + RAM) per target process being dynimized in parallel. This is because Dynimize requires 4 GB per target process in the "dynimizing" phase, releasing the memory after that.

  •  Above virtual memory requirement increased to 6GB (swap + RAM) per target process being dynimized when the target is a MySQL 8 mysqld process.

---

3.1 VM specific requirements

There are no specific requirements for running inside KVM, Xen or VMware virtual machines. Therefore Dynimize can be run in most cloud environments.

---

3.2 Docker specific requirements

Dynimize must be run in the same container as the target process being optimized. When run, the dyni process requires the ability to use the ptrace(), process_vm_readv(), process_vm_writev(), and perf_event_open() system calls to profile and interface with the target process being optimized. This requires the dyni process to be run with the CAP_SYS_ADMIN and CAP_SYS_PTRACE capabilities. Docker as of the time of this writing (Docker version 18) disables these system calls and capabilities by default. The simplest way to enable them is by starting a docker container with the --privileged flag. For example, $run -it --privileged my_image. Alternatively, see Docker's documentation on seccomp profiles for specifically enabling just these system calls.

---

4. Command Line Options

---

5. Configuration File

On startup, Dynimize is configured based on the settings in /etc/dyni.conf. The following is a description of these settings. Many of these settings can be overridden by command line options. Note that starting a line with the # character will cause that line to be skipped.

All options follow the line in the .conf file containing the string [options]. If any of those following options are missing, their default settings are used. Note that the < | > characters should not actually be placed in the log file:



The lines following [exeList] in dyni.conf denote the whitelist of possible optimization targets. These are the names of the executables that are used to launch the processes that can be targeted by Dynimize, one name per line. So for example, the MySQL server process would be denoted as mysqld. A process must have been started by an executable on this list to be dynimized. Note that if a symbolic or hard link is used to call an executable, the real executable file name must be specified on the [exeList].

The lines following [users] list the possible user names of the owners of processes that can be targeted by Dynimize, one name per line. If present, a process must match both the [exeList] and [users] list in order to be dynimized. Default: no user name requirement.

The output log specified by -log=<pathname> records all errors and Dynimize status updates along with their timestamps. It will also list all options enabled at Dynimize startup which can be used to verify the options that are in effect. On installation the log path is set to /var/log/dyni.log in /etc/dyni.conf. Once the log file reaches half the maxLogSize, it is moved to the same path name appended with .old, and a new log is started as the original log file name. Logging is disabled if the log option is removed from dyni.conf.

---

6. Dynimize States

A process that is being targeted by Dynimize for optimization may be in one of the following states, as indicated by the dyni -status command. For example:





The follow are the 5 possible states:

profiling

dynimizing

dynimized

undynimized

partly dynimized

---

7. Dynimize Usage Examples

Below are examples of commands to perform specific tasks with Dynimize.

Start Dynimize as a background daemon process, dynimize any processes encountered, and then continue to run and target new processes that are CPU intensive and on the [exeList] in /etc/dyni.conf:




Dynimize a process with pid 9618 and exit once dynimized:




Launch Dynimize as a foreground process, only dynimizing process 9618 and then exit. Note that the -start option is excluded here so that Dynimize is not launched in the background, which can be useful for running Dynimize from shell scripts that wait for Dynimize to finish before performing the next task:




Launch Dynimize, only dynimizing process 9618, however in this case Dynimize will continue to run after the process has entered the "dynimized" state so that it can reoptimize the process if its workload drastically changes:




The following example will stop any other running instances of Dynimize, remove any optimizations performed by previous Dynimize invocations, and then continue running. Dynimize may now proceed to optimize these processes again, along with any other processes. This could be useful if you think that your workload has drastically changed and want it reoptimized using current profiling information:




Only dynimize processes run from the myprog executable:




Dynimize processes and shorten the amount of time spent in the dynimizing phase:




Start Dynimize with a new log path directory /tmp/log:

---

8. Licensing & Billing

One of the primary purposes of Dynimize is to reduce the financial costs of CPU resources consumed by target workloads for a given level of performance. Therefore to help users reduce billing costs in the cloud, elastic, on-demand subscriptions can be generated on the command line to license Dynimize with per second billing granularity, thereby matching the billing granularity of CPU resources in many public clouds and allowing for easy licensing automation.

Use your access token to start a subscription license for your host.



To cancel a host's subscription license from the command line, Dynimize must be shut down and there cannot be any dynimized processes running on that host.

To stop running instances of Dynimize and "undynimize" all dynimized processes, run



or you can simply stop Dynimize and restart any dynimized processes to "naturally" undynimize them. For example, the following commands can restart the mysqld process for MySQL after stopping Dynimize.





To then cancel a subscription license for a given host, run the following command on that host.



By default, time is accounted for using per second granularity, but only when the license is later correctly cancelled from the command line. See Billing time granularity for exceptions.

Time accounting for any licenses used only begins 7 days after your account was activated. This initial period is your free trial, after which each license is then priced at $1 per CPU core per 30 days, prorated per second of usage when cancelled from the command line on the licensed host.

For example, if you only have 1 hour and 48 minutes of use over the course of a month on a 4 core host, you will only be invoiced $0.01. Your account will be billed at the end of each month for subscription license time used during that month.

---

Workload Requirements

10. Miscellaneous Notes

Sequential CPU speedup

Dynimize performs work in response to CPU usage

Dynimize can respond to changes in workload

Zero downtime

One Dynimize instance per OS host

Single threaded

No handoffs between Dynimize instances

No stale shared libraries

Dynimized processes stay dynimized

---

11. Example Life Cycle of Dynimize and a Target Application

1. Dynimize is started as a background process and begins in idle mode, monitoring system processes. This state consumes virtually no CPU resources:
   
   
      $ dyni -start
   
   


2. A new target application process such as mysqld is then launched and becomes CPU intensive, or an already running target application becomes CPU intensive.


3. Dynimize detects this and begins to dynimize the target application. Incremental, atomic updates to the target application's machine code are made. If the target application remains CPU intensive then this optimization typically takes around 60 seconds to complete:
   
   
      $ dyni -status
   
   
   
     Dynimize is running
   mysqld, pid: 8375, dynimizing
   
   


4. Dynimize has completed its current batch of optimization work and enters idle mode:
   
   
      $ dyni -status
   
   
   
     Dynimize is running
   mysqld, pid: 8375, dynimized
   
   


5. A new target application is launched and Dynimize returns to step 3. Additionally, if the workload of the previously dynimized process has drastically changed and Dynimize was started with the reoptimize option, it also returns to step 3. Although Dynimize is single threaded, it can apply these steps to multiple target processes at the same time.

---

12. Dynimize Overheads

Dynimize introduces both CPU and memory overheads when ramping up performance during the dynimizing phase, with plans to reduce these overheads in future releases. The following section addresses these overheads.

---

12.1 Dynimize CPU overhead

CPU overhead exists during the warm-up phase when a process is being dynimized. There are two components of CPU overhead during this phase. The most obvious is the amount of CPU cycles that the dyni process is actually consuming. While at first spiking to 100% utilization of a single core for less than a second, dyni typically fluctuates at around 20% CPU utilization (of a single core) for the remainder of the warm-up phase. Because it is quite rare to be fully utilizing all hardware threads on a large multi-core system, the single threaded dyni process is unlikely to result in significant overheads in this regards. The second CPU performance overhead that takes place is that of application profiling, and although brief, it is typically far more drastic. Both these overheads are offset by the gradual machine code optimizations that take effect, and are completely eliminated once the process reaches the dynimized phase. Therefore an initial warmup period lasting anywhere from 30 seconds to several minutes should be set aside for workloads using Dynimize.

---

12.2 Dynimize Memory overhead

Memory overhead also exists, where the dyni process typically requires around 4 GB of virtual memory for each target process being dynimized, while it is dynimizing them. Most of this virtual memory consumption is used for book keeping purposes when dynimizing, and so the dynamic range of memory accesses is quite limited and in our experience does little to trigger additional page faults in memory constrained workloads. That said, at least 4GB total of free swap space + RAM is required for each dynimized process during the dynimizing phase. Once a process is dynimized, most of that memory is freed. The dyni process then typically consumes 50-150 MB of virtual memory per dynimized process. This is used for book keeping purposes in order to react to drastic workload changes in dynimized processes. This memory also undergoes a very small range of dynamic accesses, and should therefore have negligible impact on system paging.

Note that when using -reoptimize, if a drastic workload change occurs for a specific process then that target process may be redynimized and will return to the dynimizing phase. In this case Dynimize will briefly incur the 4 GB virtual memory overhead per target process again.

An additional use of memory is the 35 MB code cache used by the just-in-time compiler that is loaded into the target process at the start of the first dynimizing phase. That being said, the actual access patterns of machine code instruction memory with the addition of the code cache are more constrained than that of the original undynimized process, and so the resident memory pages used there should be less in most cases. Note that the flags -undo and -redo will leave behind this 35 MB code cache in a target process, and any subsequent reoptimization of a target process by Dynimize will then create a new code cache when that same process first enters the dynimizing state again. On the other hand, when the -reoptimize flag is used and dyni detects a drastic workload change in a process already dynimized by the current dyni invocation and subsequently reoptimizes it, Dynimize will continue to use the same code cache initially setup by the current dyni invocation.

Overall, because of the limited range of dynamic memory accesses, these memory overheads should not affect performance in memory constrained environments. Therefore more RAM is typically not required. However one should make sure that the system swap space can accommodate the increased virtual memory used during the dynimizing phase in memory constrained environments.

---

13. Using Dynimize on Applications Other than MySQL

Many have asked why MySQL is the main target for the initial release of Dynimize. Database workloads can be IO bound and may not always benefit from improved CPU performance to the same extent as other workloads. Extreme levels of instruction cache misses are common in many other CPU intensive enterprise software workloads, which leaves many places where the current crop of optimizations in Dynimize could be put to productive use in the future. However a lot of these other examples such as Redis or Nginx spend most of this CPU time in system mode execution (in the Linux kernel). The machine code underlying this system mode execution cannot be optimized by Dynimize in the current release and therefore these applications benefit to a lesser extent than MySQL. For example, at most around a 10% speedup with Nginx in a CPU bound setup has been observed. Other programs such as Apache HTTP Server are often configured in a multiprocess configuration where there may be too many processes for Dynimize to handle effectively, or where the processes have short lifetimes. For these reasons, little time has been spent investigating these other use cases up to now.

Future versions of Dynimize will be able to optimize workloads with these characteristics as well. However at the moment, MySQL and its variants have been the main focus, with other single process, multithreaded relational databases on Linux such as MongoDB being likely candidates to benefit from this current release. Stay tuned for expanded scope in future releases.

If you find Dynimize useful in other workloads outside of MySQL, we'd love to hear about it. Let us know at info@dynimize.com.

---

Questions & Feedback

We love answering questions and your feedback is extremely valuable! Please use the discussion form below for anything related to this documentation.