From 7ee8080d1127b30c935dfd896a8e78b3a34ee176 Mon Sep 17 00:00:00 2001 From: Siri Hansen Date: Mon, 29 Aug 2011 15:58:45 +0200 Subject: Improve performance of upgrade when many processes have old code This commit utilizes the new bif erlang:check_old_code/1 to check if a module has old code in the system or not before running erlang:check_process_code/2. This is to optimize release_handler:install_release (and release_handler:check_install_release). A new test is added which checks that after traversing all processes/modules once and purging all old code, the second run through this part of the code is "sufficiently" much faster. A note is also added in the reference manual for release_handler:install_release about how to go around the efficiency problem of this function. --- lib/sasl/doc/src/release_handler.xml | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) (limited to 'lib/sasl/doc/src') diff --git a/lib/sasl/doc/src/release_handler.xml b/lib/sasl/doc/src/release_handler.xml index 4a973bc5ed..2781412848 100644 --- a/lib/sasl/doc/src/release_handler.xml +++ b/lib/sasl/doc/src/release_handler.xml @@ -4,7 +4,7 @@
- 19962009 + 19962011 Ericsson AB. All Rights Reserved. @@ -299,6 +299,26 @@ release_handler:set_unpacked(RelFile, [{myapp,"1.0","/home/user"},...]). {update_paths,true}, afterwards code:lib_dir(myapp) will return /home/user/myapp-1.0.

+ +

Before a new release is installed, the + release_handler checks that no processes have + references to old code of any of the modules that are to be + loaded. This operation can be very time consuming, + especially if there are many processes in the system, since + it might cause garbage collections and copying of data.

+

If it is desirable to reduce the time spent in this + function, then check_install_release/1 + might be called first. This function does the same check for + old code, including garbage collection, and can be done in + the background before actually starting the upgrade by + calling install_release.

+

Code might even be purged (using + code:purge/1) after + check_install_release in order to completely + avoid the check for old code during + install_release.

+ -- cgit v1.2.3 From 23a350702fd05ee45285c01172d2cba7ff9f5029 Mon Sep 17 00:00:00 2001 From: Siri Hansen Date: Fri, 2 Sep 2011 12:16:51 +0200 Subject: Add option purge to release_handler:check_install_release Given this option, all modules that are to be purged by indicated upgrade,and that can be soft purged, will be purged when all other check of check_install_release have been successfully completed. I added a note under install_release in the reference manual about how to use check_install_release with this new option in order to speed up the execution of install_release. I also added three more test cases for this functionality. --- lib/sasl/doc/src/release_handler.xml | 42 ++++++++++++++++++++---------------- 1 file changed, 24 insertions(+), 18 deletions(-) (limited to 'lib/sasl/doc/src') diff --git a/lib/sasl/doc/src/release_handler.xml b/lib/sasl/doc/src/release_handler.xml index 2781412848..5ac0dc1acc 100644 --- a/lib/sasl/doc/src/release_handler.xml +++ b/lib/sasl/doc/src/release_handler.xml @@ -159,9 +159,12 @@ old reboot_old permanent check_install_release(Vsn) -> {ok, OtherVsn, Descr} | {error, Reason} + check_install_release(Vsn,Opts) -> {ok, OtherVsn, Descr} | {error, Reason} Check installation of a release in the system. Vsn = OtherVsn = string() + Opts = [Opt] + Opt = purge Descr = term() Reason = term() @@ -179,6 +182,11 @@ old reboot_old permanent upgrade script.

Returns the same as install_release/1. Descr defaults to "" if no relup file is found.

+

If the option purge is given, all old code that can + be soft purged will be purged after all other checks are + successfully completed. This can be useful in order to + reduce the time needed by install_release.

 @@ -300,24 +308,22 @@ release_handler:set_unpacked(RelFile, [{myapp,"1.0","/home/user"},...]). code:lib_dir(myapp) will return /home/user/myapp-1.0.

-

Before a new release is installed, the - release_handler checks that no processes have - references to old code of any of the modules that are to be - loaded. This operation can be very time consuming, - especially if there are many processes in the system, since - it might cause garbage collections and copying of data.

-

If it is desirable to reduce the time spent in this - function, then check_install_release/1 - might be called first. This function does the same check for - old code, including garbage collection, and can be done in - the background before actually starting the upgrade by - calling install_release.

-

Code might even be purged (using - code:purge/1) after - check_install_release in order to completely - avoid the check for old code during - install_release.

+

Installing a new release might be quite time consuming if + there are many processes in the system. The reason is that + each process must be checked for references to old code + before a module can be purged. This check might lead to + garbage collections and copying of data.

+

If you wish to speed up the execution of + install_release, then you may call check_install_release + first, using the option purge. This will do the same + check for old code, and then purge all modules that can be + soft purged. The purged modules will then no longer have any + old code, and install_release will not need to do the + checks.

+

Obviously, this will not reduce the overall time for the + upgrade, but it will allow checks and purge to be executed + in the background before the real upgrade is started.

 -- cgit v1.2.3