 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
http://thedailywtf.com/Articles/That-Wouldve-Been-an-Option-Too.aspx
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Darren New wrote:
> http://thedailywtf.com/Articles/That-Wouldve-Been-an-Option-Too.aspx
WTF?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
And lo on Fri, 18 Jul 2008 05:25:55 +0100, Darren New <dne### [at] san rr com>
did spake, saying:
> http://thedailywtf.com/Articles/That-Wouldve-Been-an-Option-Too.aspx
"a developer had to step in and restart the site to release resources"
Wouldn't that suggest that bunging some more memory in would only increase
the time it took to fill up?
--
Phil Cook
--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Phil Cook <phi### [at] nospamrocain freeserve co uk> wrote:
> And lo on Fri, 18 Jul 2008 05:25:55 +0100, Darren New <dne### [at] san rr com>
> did spake, saying:
> > http://thedailywtf.com/Articles/That-Wouldve-Been-an-Option-Too.aspx
> "a developer had to step in and restart the site to release resources"
> Wouldn't that suggest that bunging some more memory in would only increase
> the time it took to fill up?
You have a very good point. If the memory was filling up slowly, it means
there was some kind of leak. Buying more memory doesn't fix any memory leaks,
it only delays the symptoms.
Leaks also often go hand-in-hand with other bugs in the software, so
fixing the leaks not only make the program stabler, but other bugs may
be caught in the process.
Unless more "WTF" details are given about this story, I'd have to say
this is a "false WTF". It might sound like a WTF at first, but isn't.
The priorities should be "fix bugs first, then buy more hardware", not
the other way around.
--
- Warp
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Warp wrote:
> Unless more "WTF" details are given about this story, I'd have to say
> this is a "false WTF". It might sound like a WTF at first, but isn't.
> The priorities should be "fix bugs first, then buy more hardware", not
> the other way around.
For me, the WTF moment is that everybody else thought that just throwing
more hardware at the problem would somehow be a "better" solution than
actually fixing the underlying problem. But maybe that's just me...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Orchid XP v8 <voi### [at] dev null> wrote:
> Warp wrote:
>
> > Unless more "WTF" details are given about this story, I'd have to say
> > this is a "false WTF". It might sound like a WTF at first, but isn't.
> > The priorities should be "fix bugs first, then buy more hardware", not
> > the other way around.
>
> For me, the WTF moment is that everybody else thought that just throwing
> more hardware at the problem would somehow be a "better" solution than
> actually fixing the underlying problem. But maybe that's just me...
>
> --
> http://blog.orphi.me.uk/
> http://www.zazzle.com/MathematicalOrchid*
My first thought was the new employee came from Microsoft.
Isaac
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Clarence1898 wrote:
> My first thought was the new employee came from Microsoft.
I am fairly confident that using more hardware resources is an explicit
*design goal* for M$. (After all, who are their main customers?)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Phil Cook wrote:
> Wouldn't that suggest that bunging some more memory in would only
> increase the time it took to fill up?
Not necessarily. Sure, if you have a leak, you need to fix it. But it's
entirely possible to have problems from not having enough memory that
are solved by adding memory. The linux OOM killer won't kick in, you
won't thrash, you won't have race conditions caused by thrashing, you
won't have exceptions causing you to fail to release resources because
you are thrashing, etc.
"Had to restart the system to free up resources" could mean "we're
thrashing because we have 5000 connections open to the server at once,
because they're not closing, because we're thrashing." For example.
But sure, if there's a leak, you'll eventually fill up memory. If 2 gig
changes it from being "restart the server once every day" to "restart
the server more rarely than we upgrade the software anyway", it's a win.
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Orchid XP v8 wrote:
> Clarence1898 wrote:
>
>> My first thought was the new employee came from Microsoft.
>
> I am fairly confident that using more hardware resources is an explicit
> *design goal* for M$. (After all, who are their main customers?)
>
End users?
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Mike Raiford wrote:
> Orchid XP v8 wrote:
>> Clarence1898 wrote:
>>
>>> My first thought was the new employee came from Microsoft.
>>
>> I am fairly confident that using more hardware resources is an
>> explicit *design goal* for M$. (After all, who are their main customers?)
>>
>
> End users?
That's the mistake everyone makes.
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Darren New wrote:
> Mike Raiford wrote:
>> Orchid XP v8 wrote:
>>> Clarence1898 wrote:
>>>
>>>> My first thought was the new employee came from Microsoft.
>>>
>>> I am fairly confident that using more hardware resources is an
>>> explicit *design goal* for M$. (After all, who are their main
>>> customers?)
>>>
>>
>> End users?
>
> That's the mistake everyone makes.
>
OEMs are just distributors of the software, though.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Mike Raiford wrote:
> OEMs are just distributors of the software, though.
Yes? And?
You probably think you're CBS's customer, too.
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Darren New wrote:
> Mike Raiford wrote:
>> OEMs are just distributors of the software, though.
>
> Yes? And?
>
> You probably think you're CBS's customer, too.
>
No. CBS's customers are the advertisers ...
MS doesn't write specifically for the hardware vendors. Unless you
consider corporations as being their biggest customers, but they're just
a conglomeration of end users.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Mike Raiford" <mra### [at] hotmail com> wrote in message
news:4880e65d$1@news.povray.org...
> Unless you
> consider corporations as being their biggest customers, but they're just
> a conglomeration of end users.
But end users without a say in what their company buys and they use. Can
they be called customers since they did not spend their own money on a
product?
Corperates are MS's largest clients. Single users who purchase their
software (like you or I) are small fry to them.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Phil Cook" <phi### [at] nospamrocain freeserve co uk> wrote
> And lo on Fri, 18 Jul 2008 05:25:55 +0100, Darren New <dne### [at] san rr com>
> did spake, saying:
> > http://thedailywtf.com/Articles/That-Wouldve-Been-an-Option-Too.aspx
> "a developer had to step in and restart the site to release resources"
>
> Wouldn't that suggest that bunging some more memory in would only increase
> the time it took to fill up?
No. If there was a leak, they wouldn't have reduced the memory footprint by
50%.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
somebody wrote:
> No. If there was a leak, they wouldn't have reduced the memory footprint by
> 50%.
Clearly the article *does* say they got rid of leaks and inefficiencies
both. :-) Some leaks just aren't big enough to worry about, tho.
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Darren New" <dne### [at] san rr com> wrote in message
news:4880f9f3$1@news.povray.org...
> somebody wrote:
> > No. If there was a leak, they wouldn't have reduced the memory footprint
by
> > 50%.
> Clearly the article *does* say they got rid of leaks and inefficiencies
> both. :-)
That's not clear to me. Note that "unreleased resources" ...etc need not be
leaks.
It just doesn't make sense to me to be able to claim a 50% reduction in
memory in a leaky application, unless they halved the leaks as well instead
of eliminating them <g>
> Some leaks just aren't big enough to worry about, tho.
True, typically in interactive applications where user interaction
limitation sets an upper bound on leak rate.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
somebody wrote:
> That's not clear to me. Note that "unreleased resources" ...etc need not be
> leaks.
Possibly not. Possibly they were released but not as early as they
should have been.
> It just doesn't make sense to me to be able to claim a 50% reduction in
> memory in a leaky application, unless they halved the leaks as well instead
> of eliminating them <g>
Yeah. In any case, it's obvious that it's not going to be resolved on
the basis of *that* article. :-)
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
And lo on Fri, 18 Jul 2008 17:26:33 +0100, Darren New <dne### [at] san rr com>
did spake, saying:
> Phil Cook wrote:
>> Wouldn't that suggest that bunging some more memory in would only
>> increase the time it took to fill up?
>
> "Had to restart the system to free up resources" could mean "we're
> thrashing because we have 5000 connections open to the server at once,
> because they're not closing, because we're thrashing." For example.
True, but that still may be simply postponing the problem; the article
mentions the increasing need for restarting.
> But sure, if there's a leak, you'll eventually fill up memory. If 2 gig
> changes it from being "restart the server once every day" to "restart
> the server more rarely than we upgrade the software anyway", it's a win.
Indeed from a business perspective if buying more memory is cheaper then
fixing the underlying problems then that's the 'best' solution. I just
wouldn't place this article in the pure WTF category.
--
Phil Cook
--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Darren New wrote:
>
> But sure, if there's a leak, you'll eventually fill up memory. If 2 gig
> changes it from being "restart the server once every day" to "restart
> the server more rarely than we upgrade the software anyway", it's a win.
>
I actually know a system (actually, a 4-numbered set of those systems),
which is being reboot scheduledly every week because of a memory leak.
It's rare enough (and the actually needed schedule would be once in two
weeks oslt), so it's "ok".
--
Eero "Aero" Ahonen
http://www.zbxt.net
aer### [at] removethis zbxt net invalid
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Phil Cook wrote:
> And lo on Fri, 18 Jul 2008 05:25:55 +0100, Darren New <dne### [at] san rr com>
> did spake, saying:
>
>> http://thedailywtf.com/Articles/That-Wouldve-Been-an-Option-Too.aspx
>
> "a developer had to step in and restart the site to release resources"
>
> Wouldn't that suggest that bunging some more memory in would only
> increase the time it took to fill up?
>
When I worked for GM a developer had to access a system to 'clean out
the database' about every month or so so that it wouldn't crash. They
had a nice maintenance contract going.....
Tom
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |