Live data from Hacker News

Help, Linux ate my RAM

linuxatemyram.com

101–106 of 106 posts

Re: Help, Linux ate my RAM

#101
post #35
post #16

Earlier quoted context omitted.

I'm a programmer but not a Mac user. I fail to see what is wrong with the bug report above. Care to explain?

"installd" is a completely undocumented (outside of Apple) daemon that is somehow involved in installing your software (it runs while installing App store programs) and checking to see what updates you might need. It has no user visible existence. No one would ever know about it unless they ran "ps" or something similar. They will find no hint at what it does, or if killing it is safe.

Thanks for the explanation. I still don't think it's a good example in the context of this thread. My impression is similar to onli's:

http://news.ycombinator.com/item?id=3699158

Re: Help, Linux ate my RAM

#102
post #80

Earlier quoted context omitted.

Thanks! htop is MUCH better than plain ol top.

You'd be surprised how good and feature rich plain ole top actually is. My guess is you rarely deviate from the default options. I made a video which shows how you can get top to show you some pretty interesting stuff. http://www.youtube.com/watch?v=yFKRsLj_Jhg

thanks for sharing!

Re: Help, Linux ate my RAM

#103
post #69

Earlier quoted context omitted.

I have seen installd peg my CPU to 100% and have killed it. What would you suggest I do? One of the most annoying features of modern OSes is when some system process just decides to start going wild, eating memory and CPU. Often I find reinstalling is the only way to fix such things.

Let it finish. It has some thinking to do, maybe crypto checksums? Maybe just a really inefficient corner case on an algorithm. There's nothing wrong with letting your CPU work. if running at 100% makes your machine flakey, it is broken. If your foreground performance is being impacted too severely (and I haven't seen this from installd, I just noticed and researched installd while removing Mac Keeper (malware) from…

More than weekly (but fairly randomly) I used to find installd would peg my CPU to 100% and just stay there for hours. It doesn't make my machine flakey, but it makes it slow and I have other things to do.

In the end I just reinstalled my OS, restored files from Time Machine, and everything was fine. I never did figure out why it was misbehaving. I have had (once) a similar problem with spotlight. Fortunately there I knew enough to run lsof to find it had got snuck in an infinite loop on one particular mp3 file, which I just deleted.

However, my point (which I should probably have been clearer about) is that bits of OSes are known to just start going wild for no reason, and often killing them, and eventually reinstalling, is the only option.

Re: Help, Linux ate my RAM

#104
post #78

Earlier quoted context omitted.

If it's cached to the filesystem, it'll be handled by the file cache, under the kernel's control with the rest of RAM. Maybe browser makers have a good reason for thinking they can do better than the OS, I don't know, but having two systems trying to do the same job with the same resources sounds like a recipe for instability and inefficiency to me.

If you have to cross the kernel boundary every time you want to access something in your cache, your "cache" is now much, much slower. Note that this applies even if the OS keeps the file in memory, and doesn't require going to disk.

Sure, but if accepting that cache slowdown makes the rest of the system more responsive and more useful for background tasks, it may be worthwhile. It's a trade-off, and the browser makers have every incentive to be as selfish as possible.

Re: Help, Linux ate my RAM

#105

Earlier quoted context omitted.

then there's over-commit, e.g. "you want to malloc 200% of the ram? here you go! enjoy! oh wait, you wrote to the second half? have fun finding the power button, sucker!" can someone explain to me why so many distros, including "enterprise" server stuff, ship with /proc/sys/vm/overcommit_memory set to 1?

Most software cannot cope with malloc failing. A little swapping is at least recoverable. A failed malloc almost guarantees that your application will crash--sometimes in a very unpleasant way.

ime the main alternative is the box crashing, frequently without leaving behind enough information to know what went wrong. at least if the app crashes you have a pretty good idea who was incompetent.

Re: Help, Linux ate my RAM

#106
post #94
post #73

Earlier quoted context omitted.

Having tried both, I'd recommend atop over htop. There's a great overview of its capabilities at https://lwn.net/Articles/387202/

While more powerful, atop is rather confusing. htop is friendly.

I'm not sure what about using atop is confusing, but I'll admit to printing out and referring to the manpage when I discovered it. That was as much because of the great explanations atop's manual provided for the metrics it could display as it was because I wanted to learn the interactive commands.

Some things about htop that I could see as friendlier:

* Htop scrolls with the arrow keys, while atop uses ^F and ^B.

* Htop displays a reminder for some commonly-used commands at the bottom of the screen (e.g. that you need to press 'F1' for help), whereas in atop you have to remember the commands or look them up by pressing 'h' or '?'.

* Htop displays gauges for system-level activity. I think this is a bad tradeoff, though:

    CPU | sys      0% | user      1% | irq       0% | idle    799% | wait      0% |
    MEM | tot    7.8G | free    5.7G | cache 735.6M | buff  351.2M | slab  248.1M 

is much more useful than

    Avg[|                                        0.2%]
    Mem[|||||||||||||||||                 1008/7967MB]
There are features of htop that I wish atop had. For example, the toggleable display of threads, the tree view, and integration with strace and lsof. Even without those I find atop more useful, but YMMV.

The killer feature for atop is logging per-process performance data and reviewing it after the fact.

Post reply on HN