On 19 Feb 2016 12:27:09 -0800, in bit.listserv.ibm-main you wrote:
>On Feb 19, 2016, at 12:15 AM, Timothy Sipples wrote:
>
>> Andrew Rowley wrote:
>>> I will make the same comment I made last time this topic came up -
>>> avoiding garbage collection is not usually a wise goal.
>>
>> It depends on the workload(s). The point I made is that with the
>> z13 and
>> z13s you have more such options, when/as they make sense.
>>
>> To pick an example, I recall dealing with a Java workload that had an
>> unresolved memory leak. Such is life sometimes. Nobody is perfect,
>> and one
>> should plan for human fallibility. The application development team
>> did a
>> superb job to resolve the problem, eventually successfully, but it
>> took
>> several weeks to nail it down and get the fix tested and into
>> production.
>> In the meantime, on the production side, the operators ran the
>> mission-critical application in a minimum of two servants, with HTTP
>> session persistence and big heaps (lots of memory) to keep them
>> afloat for
>> as long as possible ("hours"). Then, even with the unresolved leak,
>> they
>> could maintain continuous service for their users. Much like the
>> coach of a
>> basketball team, they "benched" each player (servant) on a
>> scheduled basis
>> before the player got exhausted (couldn't garbage collect). They
>> decided
>> when the best times were to recycle opportunistically. This heroic
>> production operator save meant that end users didn't have any service
>> interruptions. They had no idea there was an ongoing, nail biting
>> drama --
>> everything ran smoothly. That's just one example among many of the
>> advantages of having lots of memory or at least a bit more than
>> "enough."
>> In their case throwing some more memory at the problem literally
>> meant not
>> busting their Service Level Agreement (SLA) on an extremely important
>> application.
>>
>> My hats off to those teams. Bravo, disaster well averted.
>
>Sorry Timothy. An unresolved memory leak is bad no matter what and
>buying a bigger machine for bad coding. Its not cost effective in any
>sense of the word.
>Fix the damn BUG! Get the team to fix their code and stop patting
>them on the back as obviously they still have issues.
Ed, they did fix the bug but it took several weeks to do it. With
memory they were able to stay afloat while the repair was being done.
Clark Morris
>
>Ed
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
