On 7/24/07, Mike Robinson <[EMAIL PROTECTED]> wrote:
I went ahead and performed the above. The compile session did crash a few times as usual, but the oom-killer never appeared. In fact, looking through the logs, it hasn't appeared since July 15th (the logs I posted earlier). So, I'm assuming
I really wonder if it's the compiler that is causing (or has caused) the oom as you described. From this snippet, it would seem that the only really big app you are running is "mythbackend" taking up a little over 220 megs of VM. That seems normal to me (amarok also takes up that much) but of course that's really not a valid comparison (although some dvd/media players take up quite a bit of room, such as gxine/vlc if you have all the filtering going on). Still, I'd find it odd that the compiler was eating all your available ram (and you have a lot of it). I notice further that much of mythbackend isn't all in memory (the VSIZE is only the "request size", not totally an indication of how much RAM it is consuming, but (as it has been explained, and I'm no expert - as the amount of VM the process *might* ask for) it isn't taking up all that much of your RAM footprint anyway (10% maximum maybe) and the kernel is smart enough to move pages of unused stuff into swap. (By the way, did you notice a lot of disk activity during any of this?) Bear in mind that compilation especially on a 64-bit machine means double pointer sizes, which adds proportionately to the amount of RAM your compile process needs. On the other hand, I haven't had personal experience compiling things where gcc or its backends needs anywhere near an "obscene" amount of RAM, but I've heard anecdotes, and I don't doubt the possibility, but for something like mythtv I don't think offhand that it would need "obscene" amounts of RAM to compile. That being said, I've never compiled it, but I have compiled other stuff where an individual cc1plus process needed over 200 megs just for itself. Thanks,
Mike
