Thanks for the quick fix, it is very helpful for Jenkins running on NFS

On Thursday, January 4, 2018 at 7:53:08 AM UTC+8, Samuel Van Oort wrote:
>
> Thank you for reporting this -- turns out to be a very simple issue.  I've 
> pushed out a tested fix -- if you upgrade to the workflow-api plugin beta-2 
> version, this is now resolved. 
>
> I'm curious to hear how it's performing for people that have tried it out.
>
> On Wednesday, December 27, 2017 at 4:07:44 AM UTC-5, Ted Xiao wrote:
>>
>> I changed it to PERFORMANCE_OPTIMIZED, but it changed back to none after 
>> restart. xml is 
>>
>> more org.jenkinsci.plugins.workflow.flow.GlobalDefaultFlowDurabilityLevel
>> .xml
>> <?xml version='1.0' encoding='UTF-8'?>
>> <org.jenkinsci.plugins.workflow.flow.GlobalDefaultFlowDurabilityLevel_-
>> DescriptorImpl plugin="[email protected]">
>>   <durabilityHint>PERFORMANCE_OPTIMIZED</durabilityHint>
>> </org.jenkinsci.plugins.workflow.flow.GlobalDefaultFlowDurabilityLevel_-
>> DescriptorImpl>
>>
>>
>>
>>
>> On Friday, December 22, 2017 at 9:51:14 AM UTC+8, Samuel Van Oort wrote:
>>>
>>> Subject: Pipeline Storage Performance Work Available For Beta - Want to 
>>> kick the tires?
>>>
>>> Hey all, I've just released a set of plugin betas to the Experimental 
>>> Update Center.  They have enhancements to Pipeline which CAN dramatically 
>>> reduce I/O use and improve performance.  Please given them a try and report 
>>> back how they work out for you.
>>>
>>> Please note: to maintain existing behavior, these changes are OPT-IN. 
>>> You MUST enable them to see a difference (see below).
>>>
>>> The settings themselves have their own explanations (tooltips and help 
>>> info), but the below gives more info.
>>>
>>> *Will it help me?*
>>> * Yes, if you are running complex Pipelines or Pipelines with many steps.
>>> * Yes, if your Jenkins instance uses NFS, magnetic storage, runs many 
>>> Pipelines at once, or shows high iowait.
>>> * No, if your Pipelines spend almost all their time waiting for 
>>> shell/batch scripts to run.  This isn't a magic "go fast" button for 
>>> everything (I wish!).
>>> * No, if you are not using Pipelines, or your system is loaded down by 
>>> other factors.
>>>
>>> *How do I get it?*
>>> * You need to be on Jenkins LTS 2.73+ or higher (or a weekly 2.62+)
>>> * Enable the experimental update center - instructions here: 
>>> https://jenkins.io/blog/2013/09/23/experimental-plugins-update-center/
>>> * Check for plugins updates
>>> * You should see and install updates for the following plugins, with 
>>> versions including the word "durability"
>>>     - Pipeline: API (workflow-api)
>>>     - Pipeline: Groovy (workflow-cps)
>>>     - Pipeline: Job (workflow-job)
>>>     - Pipeline: Supporting APIs (workflow-support)
>>>     - Pipeline: Multibranch (workflow-multibranch)
>>> * Restart the master to use the updated plugins - note: you need all of 
>>> them to take advantage.
>>>
>>> *What does it do?*
>>>
>>> This adds a performance/durability setting for Pipelines.  If you use 
>>> the performance-optimized mode, disk writes are reduced significantly. This 
>>> lets you improve Pipeline performance greatly (reduce I/O) at some cost to 
>>> the running Pipelines' ability to survive if Jenkins falls over completely 
>>> (durability).  Stability of Jenkins ITSELF is not changed, nor are there 
>>> changes to completed Pipelines.
>>>
>>> We also add the ability to mark Pipelines to NOT resume upon restart (a 
>>> requested feature) - available under the properties at the top.
>>>
>>> *How do I USE it?*
>>>
>>> Durability settings need to be enabled (and will display in the logs 
>>> when a job begins), either globally or per Pipeline/branch (MultiBranch). 
>>> Settings take effect the next time the Pipeline runs. 
>>>
>>> There are 3 ways to configure the durability setting:
>>>
>>> **Globally**, you can choose a durability setting under "Manage Jenkins 
>>> > Configure System", labelled "Pipeline Speed/Durability Settings".  These 
>>> settings will take effect for Pipelines upon the next run, unless you 
>>> override them with one of the below settings
>>>
>>> **Per pipeline job:** at the top of the job configuration, labelled 
>>> "Custom Pipeline Speed/Durability Level" - this overrides the global 
>>> setting.  Or, use a "properties" step - the setting will apply to the NEXT 
>>> run after the step is executed (same result).
>>>
>>> **Per branch for a multibranch project:** configure a custom Branch 
>>> Property Strategy (under the SCM) and add a property for Custom Pipeline 
>>> Speed/Durability Level.  This overrides the global setting. 
>>>
>>>
>>> *What are the settings?*
>>>
>>> * Performance optimized mode ("PERFORMANCE_OPTIMIZED") - Greatly reduces 
>>> disk I/O but running Pipelines with lower durability settings may lose 
>>> runtime data IF they do not finish AND Jenkins is not shut down 
>>> gracefully.  If this happens, they behave like FreeStyle builds (logs, but 
>>> no steps to visualize). Details at bottom.
>>>
>>> * Maximum durability ("MAX_SURVIVABILITY") - behaves just like Pipeline 
>>> did before, slowest option.  Use this for running your most critical 
>>> Pipelines.
>>>
>>> * Less durable, a bit faster ("SURVIVABLE_NONATOMIC") - Writes data with 
>>> every step but avoids atomic writes. On some filesytems, especially 
>>> networked ones (i.e. NFS), this is faster than maximum durability mode, but 
>>> it carries a small extra risk (details at bottom).
>>>
>>>
>>> *Nitty-gritty details*
>>>
>>> Remember: worst-case behavior reverts to something like FreeStyle builds 
>>> -- Pipelines that cannot persist data may not be able to resume or 
>>> displayed in Blue Ocean/Stage View/etc, but will have logs.
>>>
>>> Running pipelines with the performance-optimized setting may lose data 
>>> IF they do not finish AND Jenkins is not shut down gracefully. A "graceful" 
>>> shutdown is where Jenkins goes through a full shutdown process, such as 
>>> visiting http://[jenkins-server]/exit or using one of the gentler signals 
>>> to kill the process.  A "dirty" shutdown is where the Jenkins process dies 
>>> without doing shutdown tasks -- killing a Docker container or using "kill 
>>> -9" to terminate the Java process will do this. 
>>>
>>> The less-durable/a bit faster setting avoids atomic writes -- what this 
>>> means is that if the Operating System fails, data that is buffered for 
>>> writing to disk will not be flushed and will be lost.  This is quite rare, 
>>> but can happen as a result of Docker or virtualization operations that halt 
>>> the operating system or disconnect storage.  Or, y'know, if someone pulls 
>>> the plug.
>>>
>>>
>>> *Warnings*
>>> This has extensive unit testing, plus initial code review and some 
>>> manual testing BUT it is still a beta, so there's some risk.  Take 
>>> appropriate precautions - back up JENKINS_HOME, don't deploy to a critical 
>>> Jenkins instance, etc.
>>>
>>> Think of it as an early Christmas gift, and happy holidays to all!
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/80d93b03-6879-403f-8272-9865db510e2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to