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?

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.

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.