Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #48414
| From | dieter <dieter@handshake.de> |
|---|---|
| Subject | Re: Debugging memory leaks |
| Date | 2013-06-16 08:18 +0200 |
| References | (2 earlier) <slrnkrkacg.2u4.giorgos.tzampanakis@brilliance.eternal-september.org> <51ba82b5$0$29997$c3e8da3$5496439d@news.astraweb.com> <CAPTjJmqF3b1CZ5wB3C6kC3o=uUYt-7KCQax7_U+NQ77e8xvVBw@mail.gmail.com> <87y5abyig3.fsf@handshake.de> <CAPTjJmoLO8U5qpwZ_atS_5qE+Jk+BfiVkt_HC=CRuHTaTf07pQ@mail.gmail.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.3428.1371363534.3114.python-list@python.org> (permalink) |
Chris Angelico <rosuav@gmail.com> writes: > ... > Right. Everything needs to be scaled. Everything needs to be in > perspective. Losing 1 kilobit per day is indeed trivial; even losing > one kilobyte per day, which is what I assume you meant :), isn't > significant. But it's not usually per day, it's per leaking action. > Suppose your web browser leaks 1024 usable bytes of RAM every HTTP > request. Do you know how much that'll waste per day? CAN you know? What I suggested to the original poster was that *he* checks whether *his* server leaks a really significant amount of memory -- and starts to try a (difficult) memory leak analysis only in this case. If he can restart his server periodically, this may make the analysis unnecessary. I also reported that I have undertaken such an analysis several times and what helped me in these cases. I know - by experience - how difficult those analysis are. And there have been cases, where I failed despite much effort: the systems I work with are huge, consisting of thousands of components, developed by various independent groups, using different languages (Python, C, Java); each of those components may leak memory; most components are "foreign" to me. Surely, you understand that in such a context a server restart in the night of a week end (leading to a service disruption of a few seconds) seems an attractive alternative to trying to locate the leaks. Things would change drastically if the leak is big enough to force a restart every few hours. But big leaks are *much* easier to detect and locate than small leaks.
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Debugging memory leaks writeson <doug.farrell@gmail.com> - 2013-06-12 18:24 -0700
Re: Debugging memory leaks dieter <dieter@handshake.de> - 2013-06-13 08:29 +0200
Re: Debugging memory leaks Giorgos Tzampanakis <giorgos.tzampanakis@gmail.com> - 2013-06-13 20:15 +0000
Re: Debugging memory leaks Steve Simmons <square.steve@gmail.com> - 2013-06-13 22:45 +0100
Re: Debugging memory leaks Chris Angelico <rosuav@gmail.com> - 2013-06-14 08:36 +1000
Re: Debugging memory leaks Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-14 02:40 +0000
Re: Debugging memory leaks Chris Angelico <rosuav@gmail.com> - 2013-06-14 19:30 +1000
Re: Debugging memory leaks Giorgos Tzampanakis <giorgos.tzampanakis@gmail.com> - 2013-06-14 22:57 +0000
Re: Debugging memory leaks Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-15 01:39 +0000
Re: Debugging memory leaks dieter <dieter@handshake.de> - 2013-06-15 08:52 +0200
Re: Debugging memory leaks Chris Angelico <rosuav@gmail.com> - 2013-06-15 17:21 +1000
Re: Debugging memory leaks dieter <dieter@handshake.de> - 2013-06-16 08:18 +0200
Re: Debugging memory leaks rusi <rustompmody@gmail.com> - 2013-06-14 06:53 -0700
Re: Debugging memory leaks Chris Angelico <rosuav@gmail.com> - 2013-06-15 10:11 +1000
Re: Debugging memory leaks Ben Finney <ben+python@benfinney.id.au> - 2013-06-15 10:16 +1000
Re: Debugging memory leaks rusi <rustompmody@gmail.com> - 2013-06-14 20:16 -0700
Re: Debugging memory leaks Ben Finney <ben+python@benfinney.id.au> - 2013-06-15 21:23 +1000
Re: Debugging memory leaks rusi <rustompmody@gmail.com> - 2013-06-15 04:35 -0700
Re: Debugging memory leaks Chris Angelico <rosuav@gmail.com> - 2013-06-15 21:54 +1000
Re: Debugging memory leaks writeson <doug.farrell@gmail.com> - 2013-06-13 11:07 -0700
Re: Debugging memory leaks Dave Angel <davea@davea.name> - 2013-06-13 14:44 -0400
Re: Debugging memory leaks rusi <rustompmody@gmail.com> - 2013-06-14 05:36 -0700
Re: Debugging memory leaks "Frank Millman" <frank@chagford.com> - 2013-06-21 08:50 +0200
csiph-web