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?

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.

I had an issue with 100% cpu and it turns out that a dns forwarder was not responding. . . .

Good to know.  Thanks!

Hi all
We using ASG V7.104. We have same problem. CPU% goes up 100% and then down till ~10% every 15min. No signs in Log files. But after few weeks CPU% grows up and don't went down and stays at 80-100%.
Via ssh we saw - mysql process use lots of CPU.
For our business unit ASG is very critical, we have platinum support, but nothing helped (we couldn't allow access for support, regarding security reasons).
Our proxy started work terrible. We couldn't restart ASG every time so we started monitoring how much mysql process use CPU (via SNMP) and when it becomes very high, we just log in via SSH  end restart mysql with -  /etc/init.d/mysql restart
CPU wents down, node works properly without stopping, no impact to service.
Try it!

Hi all
We using ASG V7.104. We have same problem. CPU% goes up 100% and then down till ~10% every 15min. No signs in Log files. But after few weeks CPU% grows up and don't went down and stays at 80-100%.
Via ssh we saw - mysql process use lots of CPU.
For our business unit ASG is very critical, we have platinum support, but nothing helped (we couldn't allow access for support, regarding security reasons).
Our proxy started work terrible. We couldn't restart ASG every time so we started monitoring how much mysql process use CPU (via SNMP) and when it becomes very high, we just log in via SSH  end restart mysql with -  /etc/init.d/mysql restart
CPU wents down, node works properly without stopping, no impact to service.
Try it!

running 7.200 i have the same kind of 100% cpu what results in that the box just stops working.

the box can be running without any load other then a couple KB of traffic when this happened.

i have managed to ssh and run top to see that two daemons, snort_inline & barnyard, were eating more then 98% cpu creating a total of 100% cpu and bring the box to a still stand.

i have created an cron to restart the sql daemon every midnight just to be sure.

i have reinstalled the box with a new 7.200 image to be sure of no beta firmwares. i did a 12 hours memory test what was all fine. did a hard drive test all fine with no errors.

at the moment i have disabled:
Intrusion Protection
FTP Proxy
IM/P2P

but with no results.

after clearing Proxycache, the cpu is going down to 10%

thanks,

but what has the daemons snort_inline & barnyard to do with the proxycache? i don't understand that if it has.

i would expect that the daemon proxycache is taking all the cpu when checking with top. but it's not when this 100% cpu happens. it's always snort_inline & barnyard hammering the processor. 

i might go back to 7.104 since this is not a workable situation.

i still investigate this issue.

i found out that when i have the "Synchronize time with internet server" on "NTP Server Pool" (default) no issues but the firewall isn't running on the local time even with the correct tme zone (london) set.

so i changed the "Synchronize time with internet server" to an uk ntp pool. after this the box goes on 100% cpu for about 1 min and start doing those drops / 100% cpu's once a while. changing it back to "NTP Server Pool" all is well (no drops over a couple days).

now the BIG question is why!!!

if it has something to do with this ntp time setting than i should expect the ntpd daemon eating all the cpu cycles and not both snort_inline & barnyard!

i now have pointed the "Synchronize time with internet server" to my own web box what is an ntp box too since yesterday and will report what ever happened.

hope this will help others.

gert / astaro can you test this? since i can reproduce this every time.

Hi,
the NTP server you use as a source will not affect your local time much. Changing the NTP server to a local will increase the accuracy of of your ASG as a reference, but as I doubt you are doing hugely accurate time relationship applications with other people on the planet I don't think you need to worry about the accuracy or jitter.

There is more a likelyhood that the ASG is doing its own thing because this version (v7.2x) of the ASG can't use dynamic NTP pools.

Ian M

So Astaro's set to use the default NTP Pool are instead not syncing with any NTP servers at all?

Is this a permanent intentional change or is this a known issue that's scheduled to be remedied in the next update or two?

Therefore in service Astaro's that are trying to use the pool are instead using their internal clock - or are they just randomly going their merry way?

Hi,
I don't honestly know the answer to your question. The NTP pool issues was pointed out during the beta testing, you actually need to point at one NTP server and the ASG NTP function then works correctly. I currently have my ASG pointing at the Oceania pool, but the ASG only recognises one address, it can't handle the round robin of a pool, it always has the same address. I think the issue is the current version is setup to not to use the DNS refresh for NTP. 

Ian M

well i can only report that since i have my box pointing to my web box (what also does ntp) all is fine... and this box i use is a complete reinstall with the latest 7.200 iso. i indeed used this box for the beta tests but reinstalled it since i also have an pentium iii box as backup.

well i can only report that since i have my box pointing to my web box (what also does ntp) all is fine... and this box i use is a complete reinstall with the latest 7.200 iso. i indeed used this box for the beta tests but reinstalled it since i also have an pentium iii box as backup.

I point mine at a GPS based NTP device and it works great.