Messages in this thread | | | Date | Tue, 21 Mar 2000 13:43:53 -0600 (CST) | From | Jesse Pollard <> | Subject | Re: Avoiding OOM on overcommit...? |
| |
Marco Colombo <marco@esi.it>: > On Mon, 20 Mar 2000, Horst von Brand wrote: > > > Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> said: > > > > [...] > > > > > Without overcommit: > > > You can support 100 simultaneous connections, with full saturation of > > > each server, with no failures. > > > > > > Result: happy customers, happy management, maybe even a raise. > > > > Management nagging about supporting more pages, worried by waste of several > > Gb of disk that has never, ever been touched. System is sluggish, needs > > constant tweaking of "resource allocation quotas" as applications crash, > > even there are resources available. Seriously consider firing inept > > sysadmin. > > Then, the new sysadm turns overcommiting on, and suddenly you realize > that you can support 300 simultaneous connections, with REAL full saturation > of each server, with no failure. 100% agreed.
And the system crashes just after a flood of DoS connections hit, corrupting the accounting database, and 3 days of downtime rebuilding the accounting.... And hoping nobody stole the credit card file while the system could not perform auditing because it got aborted...
> Either the system is under control, or it's not. A perfectly tuned system > never goes OOM or OOS. A badly configured system misperforms no matter of > overcommitting being on or off.
YUP. absolutely. Although "perfectly tuned" assumes "perfect users" too.
------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |