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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
