User Tools

Site Tools


cluster:147

This is an old revision of the document!



Back

BLCR Checkpoint in OL3

  • Installation and what it does BLCR

When we move to Openlava 3.x all queues will support checkpointing, which means you can run your job in a “wrapper” and if the job or cluster crashes you can restart your job from last checkpoint file.

Checkpointing is an expensive operation so do not checkpoint under 6 hours. For example, if your job runs for a month checkpoint once a day, if your job runs for a week checkpoint every 12 hours. From this point on I expect all users to checkpoint. Some software does this internally (Amber, Gaussian). For applications or home grown code you can use BLCR. (Too bad it does not work out of box within Openlava).

You need to test out checkpointing before you rely on it. I've notice that some local code, when opening files for output, BLCR does not notice it. The code below has such an example (file fid.txt). Hopefully future versions of BLCR will fix this. Or maybe we shuold open files differently, this needs investigating further.

BLCR, Berkely Lab Checkpoint and Restart, remembers file paths and process ids. The code stages the necessary STDOUT and STDERR files Openlava generates and invokes the relocation feature while ignore old process ids. If an application is large (for example 10G), and static, it is advisable to not save the application inside the checkpoint file.

Here is an interactive simple sample run. At the bottom of this page is the v0.1 version of blcr_wrapper program which will hide the complexity for you. blcr_watcher is a program that is in your PATH already and will terminate the wrapper if the application done inside of a check point time interval. I will work with any group interested to customize your blcr_wrapper for your lab/group.



Back

cluster/147.1458241036.txt.gz · Last modified: 2016/03/17 14:57 by hmeij07