Super high CPU % (Plus funny story)

By the way, just because I wanted to see what it would do, I did let it run its course. Keep in mind that the ASG box did not have access to the internet and no computers were using the ASG box.

After five hours of waiting the box finally slowed and was running at around 10% CPU which is what I know to be normal for my ASG. See screen shot.

Anyone have any ideas?

Jayson, I have no idea why that happened to you either; we've not seen that behavior out of the httpproxy process ever on any of our rather numerous client Astaro devices.  Are there any interesting entries in the httpproxy logfiles or other logfiles?

Jayson, I have no idea why that happened to you either; we've not seen that behavior out of the httpproxy process ever on any of our rather numerous client Astaro devices.  Are there any interesting entries in the httpproxy logfiles or other logfiles?

The only thing that I'm seeing in the logs that strikes me as odd is the storage usage line under partition usage. It shows as being 5% solid for weeks then in the time frame in question it shoots up to 40% till the problem ends... Could be nothing...

Memory never really changed during the issue, if anything its lower than normal. The ram sits around 70% no matter how much I throw at it.

Swap space for whatever reason no longer is more than 0%. Think that's an issue? Sounds like it would be...





When the problem started I had not arrived home yet. So no one should have been hitting the ASG box from the inside for any reason.

Could loggin in via the SSL-VPN connection cause such an issue? I logged in (which I do every day) and then logged and came home. In the time it took me to leave work and reach home (a matter of minutes) the problem started.

I've re-included the first picture files here because the way this board changes them to jpgs and makes them smaller is too hard to see.

I would suggest you have a hardware fault. One of your graphs shows 377mb om RAM where your system has 1gb.

Ian M

Good Catch RFCKat!  That indeed is unusual... Probably is a hardware issue. There it was staring me in the face....

I would suggest you have a hardware fault. One of your graphs shows 377mb om RAM where your system has 1gb.

Nope, read his first post.

He used to only have 377MB of RAM, and later upgraded it to 1GB. The snapshots are from before and after the upgrade, showing that the problem existed before and after the upgrade.

Obviously the system should be much happier now since 377MB of RAM (probably had 384 MB, a 128MB+256MB stick) was causing him to go deep into swap space usage, but I don't think a hardware fault is the reason, here.

I would suggest you have a hardware fault. One of your graphs shows 377mb om RAM where your system has 1gb.

Nope, read his first post.

He used to only have 377MB of RAM, and later upgraded it to 1GB. The snapshots are from before and after the upgrade, showing that the problem existed before and after the upgrade.

Obviously the system should be much happier now since 377MB of RAM (probably had 384 MB, a 128MB+256MB stick) was causing him to go deep into swap space usage, but I don't think a hardware fault is the reason, here.

Nope, read his first post.

He used to only have 377MB of RAM, and later upgraded it to 1GB. The snapshots are from before and after the upgrade, showing that the problem existed before and after the upgrade.

Obviously the system should be much happier now since 377MB of RAM (probably had 384 MB, a 128MB+256MB stick) was causing him to go deep into swap space usage, but I don't think a hardware fault is the reason, here.

Yeah, as Drees was saying, I did add RAM and a second CPU afterwards. The 384 MB RAM that I've been running for the last month seems to be OK for me. I don't care if it hits the swap space. It's just a LAB.

After a couple reboots the problem didn't resolve itself. So, I added more RAM and a second CPU to see if the problem would just run its course, and it did after many hours. I've still have yet to find anything in the logs files that would help spot the issue, but I'm starting to believe it was a fluke problem with the SSL-VPN connection I made from work, but that's because no other ideas have surfaced.

The unit is back to running like a top, without any help from me, it just started working like it should after whatever it was doing finished. No issues at all from that point till now. Looking at it from a business point of view however I couldn't begin to imagine how the people at work would flip out if they couldn't get to their Gmail or video poker if this was to happen in production... (I'd probably go HA in production tho)

You got me... I really haven't seen this anywhere before, and we manage about 15 installs, and have about 15 more clients in addition that run Astaro, and have to say this is a new one on me.  Must've been a real fluke...

OK, found something that appears no where else in the logs that I've yet to find.

2008:02:05-18:13:47 (none) httpproxy[4065]: Integrated HTTP-Proxy (c) 2007 Astaro AG
2008:02:05-18:13:47 (none) httpproxy[4065]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="read_config" file="httpproxy.c" line="428" message="loading httpproxy.ini"
2008:02:05-18:13:47 (none) httpproxy[4065]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="disk_cache_read" file="diskcache.c" line="295" message="fopen: /var/cache: No such file or directory"
2008:02:05-18:13:47 (none) httpproxy[4065]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="disk_cache_zap" file="diskcache.c" line="384" message="zapping cache"


That appears a short time before the issue starts.

Update: I'm putting my main focus on this item. When I first installed / started Astaro it was fast and easy, however I found myself a short time later coming here and saying I was having massive CPU usage and thought at that time it was the fact I had 2 people using SSL-VPN... I just did a search for the string "disk_cache_zap" and hit twice. Once for the 5th a couple days ago (the reason for this post) and wouldn't you know it, again when I was here posting the first time about high CPU usage. Now, I have never gone in and manually cleared the cache so I have questions...

Does this cache purge or something after X amount of data / time is collected or something? 

Would it be a smart thing to simply turn off the caching?

How often could one expect to have this fail (if this is in deed the issue) in a production setup? 

On a related note: The "Search log files" options is incredibly power, simply awesome!

Have you tried clicking the "clear cache" button in the HTTP proxy configuration?  All my customer sites run with cache enabled, to save on bandwidth... really haven't had an issue with that yet.

Oh.. I see you say this shows up in the log when you had that problem... hmm.. not sure how it could start itself automatically, or what the rules are that would make it run... a disk error might fool it, though.  I've not seen that on any production systems here at all.  In any event, even when clearing the cache is manually triggered, I've never seen it "eat" the machine... in fact, it takes it's time clearing it sometimes... but it works nonetheless, everything keeps going.  Do you have another hard disk you can try?  You also might want to run a "shutdown -F -r now" on that box to force a restart and disk check, you might have some disk problems.

2008:02:05-18:13:47 (none) httpproxy[4065]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="disk_cache_read" file="diskcache.c" line="295" message="fopen: /var/cache: No such file or directory"

This line is more worrisome than the "zapping cache" line - is this a normal error in the logs or not? If not, for whatever reason the http proxy disk structure didn't appear to get created properly in this case.

Does this cache purge or something after X amount of data / time is collected or something?

That should not happen - items in the cache should simply get expired as the cache partition gets full and items age - at least this is how the cache used to work when it was based on squid - I imagine that with the new proxy in v7.1 it should be similar.

Would it be a smart thing to simply turn off the caching?

No, in general caching is great for saving a bit of bandwidth and improving page response times.

OK, found something that appears no where else in the logs that I've yet to find.

2008:02:05-18:13:47 (none) httpproxy[4065]: Integrated HTTP-Proxy (c) 2007 Astaro AG
2008:02:05-18:13:47 (none) httpproxy[4065]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="read_config" file="httpproxy.c" line="428" message="loading httpproxy.ini"
2008:02:05-18:13:47 (none) httpproxy[4065]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="disk_cache_read" file="diskcache.c" line="295" message="fopen: /var/cache: No such file or directory"
2008:02:05-18:13:47 (none) httpproxy[4065]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="disk_cache_zap" file="diskcache.c" line="384" message="zapping cache"

This could be caused by either zapping the cache from webadmin, or because the proxy did an unclean shutdown before - in that case the cache is recreated from scratch to make sure that the caching subsystem is in a sane state. That line will also be shown after the first start of the proxy on a fresh installation, but this isn't obviously the case here.

Does this cache purge or something after X amount of data / time is collected or something?

Cache removes only single items from the cache, not the complete cache. criterias for removal:

a) Expiration Time announced by the server
b) Time the item was last requested
c) Size of the item

Cheers,

Sven.

This line is more worrisome than the "zapping cache" line - is this a normal error in the logs or not? If not, for whatever reason the http proxy disk structure didn't appear to get created properly in this case.


That should not happen - items in the cache should simply get expired as the cache partition gets full and items age - at least this is how the cache used to work when it was based on squid - I imagine that with the new proxy in v7.1 it should be similar.


No, in general caching is great for saving a bit of bandwidth and improving page response times.

Those lines only appear twice in the 30 day period. Both times nothing was done in the admin to start this. It simply started doing it on its own.

The first time it happened I thought the high CPU usage was the SSL-VPN connections, but then found which probably wasn't the case after all that the proxy was getting hammered by programs like adobe and avg trying to get out to update. So I added those to the safe list and later on that day the CPU usage dropped. Seemed as if the problem was salved so I didn't look any farther.

Now 27 days later the same issue came up again. Nothing prompted the issue. It simply started on its own. No one or thing was connecting to the box internally. I mean there are static devices like switches etc that are on the network, but nothing that should / could bring this box to its knees...

It's probably best for now to just continue watching it like a hawk to see if it every happens again. Maybe some threshold needs to be reached.

I'd still check the disk...

You can test your disk while Astaro is running:
(as root)
badblocks -sv /dev/disk/by-label/storage
(storage partition only)

or, the entire drive:
badblocks -sv /dev/sda
(SCSI/SATA)
or
badblocks -sv /dev/hda
(IDE/PATA)


This should be completely safe, but always backup your config first!
If your disk is bad, running something like this should expose it.
A read/write test (-nsv) would be better, but cannot be run online. (use RIP or Knoppix or other bootable distro)

Barry

I had an issue with 100% cpu and it turns out that a dns forwarder was not responding. I had 4 dns forwarders set up on my internal DNS server. Let's call them A,B,C,D. What happened to me was that A was working, B was not working and C and D were not reachable due to firewall rules that I failed to create. What was happening is that if A was busy then my internal dns server would try B, B was not responding so it was trying C. C could not get out of the firewall so it tried D. The end result was hundreds if not thousands of open connections were created by my internal dns server trying to do name resolution and it ground the cpu to a halt. As soon as I corrected the DNS issue everything returned to normal. 

The reason I mention this is just in case your problem is external to your network. In other words, something is not responding externally causing a flood from the internal network?
 

Just another avenue of thought.