RE: Expectations of MEM requirements for a DB with
Anyway, I crashed my system the other day when I did a "select *" from
one
of my large tables (about 5.5gb in size).Well.... It takes abit more than that to actually crash the system. Can
you give more details? What _exactly_ happened? Did it hang? Kernel
panicked? Something else.
Actually, I was watching this convo on another message board. When linux
hits low memory situations (i.e. none) it thrashes for far longer than it
should have to, just to free some up. In this way, NT and other OS's are
much better - they can run with no memory available, very slowly, but
without waiting 2 hours for processes to time out. For all intents and
purposes, you will get your box back quicker with linux by rebooting than
waiting a few hours for it to respond. I'm not posting that here as a gripe,
but to support the guy who said it "crashed".
Rob Nelson
rdnelson@co.centre.pa.us
Thats very true. FreeBSD is a little smarter, and actualy kills a runaway
process if it allocates more memory than is available. It of course tries to
page things in and out of swap first, hoping the high memory condition will
soon resolve its self. FreeBSD is also one of the only OSes I've seen that
kick processes (idle ones, i.e., cron, getty, etc) out of memory for kernel
buffers and disk cache to improve preformance for busier ones.
Yann
On Mon, 06 Nov 2000, you (Robert D. Nelson) might of written:
Actually, I was watching this convo on another message board. When linux
hits low memory situations (i.e. none) it thrashes for far longer than it
should have to, just to free some up. In this way, NT and other OS's are
much better - they can run with no memory available, very slowly, but
without waiting 2 hours for processes to time out. For all intents and
purposes, you will get your box back quicker with linux by rebooting than
waiting a few hours for it to respond. I'm not posting that here as a
gripe, but to support the guy who said it "crashed".Rob Nelson
rdnelson@co.centre.pa.us
--
--------------------------------------------------------------------
Yann Ramin atrus@atrustrivalie.eu.org
Atrus Trivalie Productions www.redshift.com/~yramin
AIM oddatrus
Marina, CA http://profiles.yahoo.com/theatrus
IRM Developer Network Toaster Developer
SNTS Developer KLevel Developer
Electronics Hobbyist person who loves toys
Build a man a fire, and he's warm for a day.
Set a man on fire, and he'll be warm for the rest of his life.
"I'm prepared for all emergencies but totally unprepared for everyday
life."
--------------------------------------------------------------------
Thats very true. FreeBSD is a little smarter, and actualy kills a runaway
process if it allocates more memory than is available. It of course tries
It's less about its ability to kill processes (Linux does it too), but sane
default timeouts. I dunno about FreeBSD, but it can take Linux over an hour
to report an out of memory condition in any definitive form - the box
slowing to a crawl doesn't count as definitive ;) It's kinda like, why do I
have to wait 2 minutes for telnet to kill itself if I telnet to a bad
address in windows?
to
page things in and out of swap first, hoping the high memory condition will
soon resolve its self. FreeBSD is also one of the only OSes I've seen that
kick processes (idle ones, i.e., cron, getty, etc) out of memory for kernel
buffers and disk cache to improve preformance for busier ones.
Well that's kinda dangerous in and of itself. I haven't run into *too many*
OOM conditions (I do try and stack my boxes! er...) but I've noticed linux
tends to kill kswapd first :/
Rob Nelson
rdnelson@co.centre.pa.us
Import Notes
Resolved by subject fallback
On Mon, Nov 06, 2000 at 07:45:10PM -0800, Yann Ramin wrote:
FreeBSD is also one of the only OSes I've seen that
kick processes (idle ones, i.e., cron, getty, etc) out of memory for kernel
buffers and disk cache to improve preformance for busier ones.
Linux also does this, and has does this for quite some time:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 417 0.0 0.0 1084 0 ? SW Sep06 0:00 [supervise]
root 418 0.0 0.0 1084 0 ? SW Sep06 0:00 [supervise]
root 419 0.0 0.0 1084 0 ? SW Sep06 0:00 [supervise]
root 420 0.0 0.0 1084 0 ? SW Sep06 0:00 [supervise]
root 421 0.0 0.0 1084 0 ? SW Sep06 0:00 [supervise]
root 422 0.0 0.0 1084 0 ? SW Sep06 0:00 [supervise]
root 429 0.0 0.0 1084 0 ? SW Sep06 0:00 [supervise]
root 430 0.0 0.0 1084 0 ? SW Sep06 0:00 [supervise]
bruce 431 0.0 0.0 2588 0 ? SW Sep06 0:00 [pyhttpd2]
root 432 0.0 0.0 1084 0 ? SW Sep06 0:00 [supervise]
root 433 0.0 0.0 1084 0 ? SW Sep06 0:00 [supervise]
root 435 0.0 0.0 1084 0 ? SW Sep06 0:00 [supervise]
root 440 0.0 0.0 1084 0 ? SW Sep06 0:00 [supervise]
root 441 0.0 0.0 1084 0 ? SW Sep06 0:00 [supervise]
root 442 0.0 0.0 1084 0 ? SW Sep06 0:00 [supervise]
root 443 0.0 0.0 1084 0 ? SW Sep06 0:00 [supervise]
root 714 0.0 0.0 1364 0 ? SW Sep06 0:18 [junkbuster]
root 759 0.0 0.0 3252 0 ? SW Sep06 0:00 [python]
root 782 0.0 0.0 1688 0 ? SW Sep06 0:00 [safe_mysqld]
root 869 0.0 0.0 2196 0 tty1 SW Sep06 0:00 [login]
root 872 0.0 0.0 2196 0 tty4 SW Sep06 0:00 [login]
root 873 0.0 0.0 2196 0 tty5 SW Sep06 0:00 [login]
root 2007 0.0 0.0 2196 0 tty2 SW Sep07 0:00 [login]
root 2010 0.0 0.0 2196 0 tty3 SW Sep07 0:00 [login]
postgres 12527 0.0 0.0 5508 0 ? SW Sep09 0:00 [postmaster]
root 24968 0.0 0.0 2188 0 tty6 SW Sep13 0:00 [login]
lori 26328 0.0 0.0 1712 0 tty1 SW Sep13 0:00 [bash]
root 22233 0.0 0.0 1084 0 ? SW Sep12 0:00 [unixserver]
bruce 19645 0.0 0.0 1976 0 ? SW Sep18 0:00 [vpyadmin-sessio]
root 7411 0.0 0.0 1176 0 ? SW Sep23 0:00 [lpd]
root 31969 0.0 0.0 1120 0 ? SW Sep24 0:00 [inetd]
root 32052 0.0 0.0 2644 0 ? SW Sep30 0:00 [xdm]
root 5925 0.0 0.0 3568 0 ? SW Oct23 0:00 [xdm]
lori 31163 0.0 0.0 1708 0 pts/2 SW Oct27 0:00 [bash]
--
Bruce Guenter <bruceg@em.ca> http://em.ca/~bruceg/
On Tue, Nov 07, 2000 at 08:25:00AM -0500, Robert D. Nelson wrote:
I haven't run into *too many*
OOM conditions (I do try and stack my boxes! er...) but I've noticed linux
tends to kill kswapd first :/
Linux (at least in the discussions I've heard on the kernel mailing
list) is very careful to select non-critical user processes to kill, and
I would be extremely surprised if it picked one of its own threads
(kswapd is a kernel thread). I've never seen it happen, but I've only
had a few OOM situations myself.
--
Bruce Guenter <bruceg@em.ca> http://em.ca/~bruceg/