Am 18.09.2012 13:49, schrieb Erik Thiele: > Am 18.09.2012 12:53, schrieb Nico Golde: >> Hi, >> * Erik Thiele <erik.thi...@thiele-hydraulik.de> [2012-09-18 09:48]: >> [...] >>> how can I further supply information on this issue? It is a production >>> machine, but maybe I can somehow help find the cause of the issue >>> anyway? Or is that memory leakage a known issue? >> >> This is not known to me at least. Unfortunately the logs don't show that >> fetchmail had memory issues. The kernel randomly starts killing processes >> (depending on your policy) if no memory can be allocated anymore. >> Could you log the virtual memory usage of specifically fetchmail? > > at the end of my report you see daily logs of last two days of fetchmail > memory consumption. i will continue to log that log to see if it further > increases. > > actually the kernel killed many (174) processes until it finally killed > fetchmail, then there where no more oom kills left. since fetchmail is > the last to be killed, i suggest that fetchmail was the problem.
Any proof? Or did another process just run away with all the memory and killing fetchmail was the first process to yield sufficient memory for the rampant OOM killer to settle down? Possibly run without memory overcommit just to make sure that there is no need for the OOM killer to go raging at all? At any rate, the resident set size (RSS) of your fetchmail process is largish, it should be a few MBytes. Some state is cached in daemon mode, so if you have a large .fetchids file, that might be the culprit; OTOH should a process using 75 MB of memory not destabilize your system. Fetchmail does not lock pages into memory, so the kernel should just page it out if needed. > there was only one single kill of fetchmail. i am quite sure that > fetchmail must be the process that used all system memory here. I would not jump to that conclusion - fetchmail used 75 MB per your figures, which is a smaller portion of your 1.5 GB address space. [...] > does this mean take debian source package, recompile with debug flags, > run under valgrind and terminate after two days with valgrind option > show-reachable or so and send you that output then? or is there an > easier way? Please consider it's a production system on a non-IT company > which should just run... A valgrind trace of a leak would be most helpful. For starters, just running valgrind on the code might help to see if there are real leaks (and those inside OpenSSL or glibc need to be reported to the appropriate places, they do not count against fetchmail). Show-reachable is less interesting than real leaks, if any - that is because fetchmail caches internal state, and that will all be show-reachable (some of that code, especially around parsed configuration, is only freed on exit - so that would show up as false positive). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
