| apb1963 | I've been having severe load issues for months with 12.04.3... and I noticed today that I had no swap file or partition. So I installed one. Hard to be sure, but that seems to have helped but maybe it's my imagination, I don't know. Anyway, as the load started to rise a few minutes ago, I was looking at top and I noticed there were 5 zombies. | 02:14 |
|---|---|---|
| apb1963 | I had thought zombies were a thing of the past, back when kernels were buggy or some such. | 02:15 |
| apb1963 | But regardless, I wonder if there's anything I can do to figure out what the heck is creating this load? I noticed the swap issue because kswapd0 was using a lot of CPU and in fact in the D status... now that seems to be resolved for the moment... so, I'm looking for what else might be causing all this grief. | 02:17 |
| apb1963 | Any recommendations? | 02:17 |
| apb1963 | Thoughts? Ideas? Words of wisdom? | 02:17 |
| JanC | zombies happen because of buggy userspace | 02:20 |
| JanC | apb1963: my guess would be that your system doesn't have enough memory; maybe you need to tune some applications to use less memory, or some applications are leaking memory and need fixing, or maybe you really need more memory | 02:28 |
| apb1963 | JanC: thank you for your response. Please review the output of free -m: http://paste.ubuntu.com/6736119/ | 02:30 |
| JanC | well, zombies should be irrelevant | 02:35 |
| JanC | (at least in most cases, I don't know about corner cases) | 02:36 |
| JanC | kswapd kernel tread using a lot of CPU sounds like it needs to do a lot of work for some reason | 02:38 |
| apb1963 | JanC: right... but that was prior to installing a swap file. I don't know if it's coincidental or not. | 02:40 |
| apb1963 | not sure how it was running w/out swap space | 02:40 |
| JanC | I could easily run my system without swap :) | 02:42 |
| JanC | at least, most of the time | 02:42 |
| apb1963 | yes, but as you surmised, I run close to the RAM borderline | 02:46 |
| apb1963 | I'm currently using 300M of swap | 02:47 |
| apb1963 | but none of that is the point... the point is the load starts to build quickly and makes the system unusable.. sometimes just the act of running top itself seems to help... other times I have to kill a few processes.. usually chrome, but not always. | 02:48 |
| apb1963 | At the moment plymouthd is the top user of CPU at 5%. Load is 0.17 where I would expect it to be. | 02:49 |
| JanC | running top can't solve this | 02:49 |
| apb1963 | I know.... that's why I'm here. For suggestions as to what I should do... | 02:49 |
| JanC | and I don't se you running "close to the RAM borderline" | 02:51 |
| apb1963 | <JanC> apb1963: my guess would be that your system doesn't have enough memory; maybe you need to tune some applications to use less memory, or some applications are leaking memory and need fixing, or maybe you really need more memory | 02:51 |
| JanC | most of RAM is used by filesystem buffers & such, based on what you pasted there? | 02:52 |
| apb1963 | ok.... and? | 02:52 |
| JanC | is this a 64-bit system, and were you doing a big I/O operation while things stalled? | 02:53 |
| apb1963 | 32 bit | 02:53 |
| apb1963 | and I'm not sure what represents a "big I/O operation" specifically. I understand what you're asking in general terms, but I wasn't doing a file copy if that's what you're asking. | 02:54 |
| JanC | yeah, big file copies can cause problems (especially with older kernels), but that's mostly on 64-bit systems AFAIK | 02:57 |
| apb1963 | those zombies are really bugging me... shouldn't the kernel have reaped them within minutes or less? | 03:00 |
| JanC | apb1963: zombies are processes that have a parent process but the parent process didn't reap them | 03:01 |
| JanC | so processes that stopped, but their parent didn't act on that | 03:02 |
| JanC | stopping their parent process should get rid of them | 03:02 |
| JanC | (stopping their parent process would mean they get re-parented to init, which would reap them) | 03:03 |
| apb1963 | so that's a good point... parents... looking for the option to ps that gives me wchan | 03:03 |
| JanC | htop has an optio to show the process hierarchy in a tree :) | 03:04 |
| JanC | you can also see the PPID in top or ps though | 03:05 |
| apb1963 | unless I nkow which process is a zombie, I won't be able to find the parent. | 03:05 |
| apb1963 | found it | 03:07 |
| apb1963 | chrome | 03:07 |
| apb1963 | what a surprise | 03:07 |
| JanC | zombie processes shouldn't be a problem, unless they get created at an alarming rate | 03:07 |
| JanC | they should use almost no resources | 03:08 |
| apb1963 | well what I was concerned about was that they weren't getting reaped... I forgot that the parent reaps, I was thinking it was the kernel... | 03:08 |
| apb1963 | so ok, then that's not the issue | 03:09 |
| apb1963 | just exploring possibilities here | 03:09 |
| apb1963 | I started up sar | 03:09 |
| apb1963 | thought I had it running... but that was on a previous incarnation | 03:09 |
| apb1963 | well, let me do my thing and when it starts to load up again, I'll stick my nose in again | 03:10 |
| apb1963 | Thanks for the help | 03:10 |
| JanC | I had Firefox grow to 24 GiB some tiem ago, still not sure why that happened... :-/ | 03:11 |
| JanC | usually it uses less than 2 GiB with > 100 tabs open (which is *way* less than Chromium with 10 tabs open) | 03:13 |
| JanC | so maybe you have a process that sometimes grows to use a lot of memory, but maybe it disappears or releases that memory before you have a chance to debug; that's a hard thing to debug if you aren't monitoring | 03:15 |
| apw | bug #1262010 | 11:34 |
| apw | ubot2, ? | 11:34 |
| apw | lp#1262010 | 11:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!