[pca] Kernel Patch 142909-17

[Rajiv Gunja]

/etc/patch/pdf.conf = num_proc (parallel patching) was introduced with patch
119254-66 (SPARC)(Jun 17 2009) and 119255-66 (x86). I am not sure for x86,
but SPARC patch version is right.
num_proc should be ideally set to the number of Zones you are running as Don
pointed out. Depending on what type of Zone you have (sparse root or whole
root) you might find that patching time reduces either by 40-50% (sparse
root) or 20% (whole root). You should read through Oracle(SUN) patching
blog, they have excellent articles there.

-GGR
--
Rajiv G Gunja
Blog: http://ossrocks.blogspot.com


On Mon, Oct 11, 2010 at 12:08, Ron Halstead <rdhalstead at gmail.com> wrote:

>  David,
>
> Which OS (version) has num_proc= ? I'm running Solaris Express Community
> Edition snv_129 X86 and the patchadd command does not have that option.
>
> Ron Halstead
>
>
> On 10/11/10 00:39, French, David wrote:
>
>> I just wanted to point out that you can modify /etc/patch/pdo.conf and
>> set num_proc to something higher than the default of 1.  This will patch
>> num_proc zones in parallel when patchadd runs.  For example, if you have
>> many cpus and 10 zones, it shouldn't take much more time than twice what
>> it took to patch the global alone if you set the value to ten, as they
>> will all run in parallel.  I have a couple of T2000s with a global and 4
>> container zones.  The first (num_proc=1) took hours (4-5) to add about
>> 120 patches.  The other system I made sure the parameter above was set
>> to 5.  Patching on that server for the same 120 or so patches (identical
>> setups) took a little over an hour.  You can really see the difference
>> with the Java patches.
>>
>> BTW, the parameter is described in the patchadd man page, just search
>> for parallel.
>>
>>        --Dave
>>
>>  -----Original Message-----
>>> From: pca-bounces at lists.univie.ac.at [mailto:pca-
>>> bounces at lists.univie.ac.at] On Behalf Of Diana Orrick
>>> Sent: Saturday, October 09, 2010 3:41 PM
>>> To: PCA (Patch Check Advanced) Discussion
>>> Subject: Re: [pca] Kernel Patch 142909-17
>>>
>>>
>>>   Thanks for the suggestions everyone, will supply more info when time
>>> allows.
>>> Still working on the cluster...
>>>
>>> On 10/9/2010 6:18 PM, Rajiv Gunja wrote:
>>>
>>>> You might want to compare the times it took for other patches so
>>>>
>>> that
>>
>>> you know if it will take longer that 13*11*x minutes whet x is some
>>>> random number which it seems to take for patching zones. If the
>>>>
>>> server
>>>
>>>> is ok to run for more time let it run. It took my server 7 hours to
>>>> patch 200 patches on a server with 3 zones. Sine you have 13 zones
>>>>
>>> it
>>
>>> might take longer.
>>>> -GGR
>>>>
>>>>  On Oct 9, 2010 12:17 PM, "Martin Paul"<martin at par.univie.ac.at
>>>>> <mailto:martin at par.univie.ac.at>>  wrote:
>>>>>
>>>>> Diana Orrick schrieb:
>>>>>
>>>>>
>>>>>  Any suggestions on how to determine if the patching is
>>>>>>
>>>>> progressing
>>
>>>  at all?
>>>>>
>>>>> I guess you could use "truss -f -p<PID>" on the PID of the
>>>>> "patchadd" process to see what's going on.
>>>>>
>>>>> If you have to interrupt the patch installation process, the only
>>>>> "good" thing is that PCA is using plain patchadd for the patch
>>>>> install, so there's no extra uncertainty added by the fact that you
>>>>> are using PCA. On the other hand I don't have much practical
>>>>> experience about how "patchadd" reacts to Ctrl-C. I think that it
>>>>> should be pretty save to remove the partly installed patch with
>>>>> "patchrm" afterwards without causing any ill effects.
>>>>>
>>>>> Martin.
>>>>>
>>>>>
>>>>>  --
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>           Diana Mayer Orrick, System Administrator
>>>   Information Technology Services, Florida State University
>>>         Contact:   orrick at fsu.edu   --   (850) 645-8009
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.univie.ac.at/mailman/private/pca/attachments/20101011/64c7de6f/attachment-0001.html