[Tfug] Memory woes

Bowie J. Poag bpoag at comcast.net
Sun Feb 4 01:48:55 MST 2007


my twoCents()
{

ventSpleen();

I don't know whats happening in your specific case, but I can tell you 
one thing, technical reasons aside... Sadly, that's common. I've got a 
gameserver with a gig of memory, 3GHz Athlon XP 64-bit, running a 64-bit 
kernel. I still see occasional performance drag, particularly when new 
processes kick off. Even on apps optimized for 64-bit hardware. It's 
terrible.

Faster and faster computers mean programmers pay less and less attention 
to performance on an application-by-application basis. The beast has two 
heads, as I see it---One, Programmers write apps so that they perform 
well on their own systems, not necessarrily on other people's systems. 
And two, Faster gear. masks. bad. code. Most programmers, even good 
programmers, don't KNOW their code is horribly inefficient, and most of 
them either don't care or don't have the time to care. To make it worse, 
the same bleh* and that affects code also affects the tools people build 
to help write NEW code. Same problem, but with interest compounded. 
Java, anyone?

Where I work, there was a patch deployed on a mission-critical app that 
added about 15-20% processor overhead across the board. It lit a fire 
under our ass to get the application migrated to new hardware, because 
we were beginning to see the box hit ceiling on CPU utilization. After a 
few weeks, the new hardware arrived, we had migrated, and the vendor 
corrected the 15-20% penalty with a new patch. We took before-and-after 
performance metrics on it, and couldn't really see the performance we 
got back, even though we know it was there! It simply didn't stand out 
from the background noise, since the new hardware was (x)^n faster. More 
than likely, there are similar performance issues elsewhere in the code, 
but with every generation of hardware, they're simply hidden via 
brute-force, less and less discernable against the background noise as 
time goes on. At the end of the day you've got a 20-30 second 
transaction lag in a database app which eats 60% CPU on a 4-way SMP 
RS/6000, when transactions sould be quicker than shit through a goose 
and eat less than 10% CPU.

So, how do you fix it? I don't know.  Maybe some sort of law that would 
require us to run-test everything against a 233 MHz Pentium prior to 
release.  :)  Throw strace underneath your favorite app sometime, and 
watch the fireworks. If you had any idea how badly most systems squander 
memory and processor time, you'd be horrified. If you slowed it down to 
human speeds, you'd cry at how hopeless and incorrectible the situation 
seems. Part of it is also that the bar has been lowered more and more. 
Hell, how many times is a typical desktop completely repainted, and new 
icons laid out when you boot, regardless of whether its Linux or 
Windows? Half a dozen times or more? It's just crap code. A ten fold 
increase in processor speed translates into about a two fold increase in 
real-world performance over time, from my experience. You're buying a 
computer for it's increased ability to wait faster, and better mask 
horrid code.

Now, don't get me wrong -- I often suck, and I've written my share of 
crap code, too.  (heh, IPC via signalling & filehandles!) But i've tried 
to make a practice out of seeing what i've done execute on lower 
hardware. It helps.
}

Cheers,
Bowie

// * bleh (n.) Malaise. Melancholic sloth.

unmount_soapbox(); // :)


Christopher Robbins wrote:

>I've been running SUSE for quite some time now, and I've never had any real
>issue with it.  My Athlon64 3000+ combined with a meager 512mb of RAM was
>good enough for even
>the most memory-hungry apps.
>
>But all that has suddenly changed.  I recently installed SUSE 10.2 x86-64,
>and my computer has slowed down considerably.  The stupid *#@#$* thing
>thrashes about and everything works at a
>standstill.  I recently added a gig of memory, pushing the system to
>1.25gigs, and nothing's helped.  I don't know where to start digging,
>because
>everything seems screwy.  KDE processes are taking
>100-150 mb of memory.  I've got (at present time) 2 ssh connections, and
>sshd is reporting 120mb of memory devoted to each process.  The mythtv
>backend is swallowing another 400mb.
>
>I don't understand - this hasn't been a problem in the past.  I don't think
>it's a window manager issue either, though I do understand that my use of
>KDE may be a factor...
>
>Any thoughts?
>
>-Chris
>  
>





More information about the tfug mailing list