Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 28 replies
  • Subscribers 3 subscribers
  • Views 13935 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Super high CPU % (Plus funny story)

Jayson
So, I've been playing with the ASG for some time now in my lab at home, and I really wanted to show it to some one. I jump online, VPN'd in and showed them how easy it is. After work we headed over to the house to see it first hand and when we arrive I find the gateway just killing itself at 100% CPU usage. Nothing was possible, IE web browsing, or even logging in to the system... (yes I did get in at one point see pictures)

Image asg100.jpg shows the system running at 100% CPU even though it has worked flawless for 25+ days. CPU never really peeked over 40% for any reason during that time.

Image asgday.jpg shows a snapshot of the physical servers CPU usage for the day.

Image asgtop.jpg shows a snapshot of a ssh session running the "top" command.

Image asg100-r.jpg is a picture of how the CPU% continued to peek after rebooting many times, even after adding a second CPU (1 ghz p3x2) and adding 3 times the amount of ram. It didn't slow down for hours. 

No users at all using the system for anything. But still the httpproxy is using up all the proc. As a test I unplugged the larger 48 port switch and plugged in a four port which removed all computers in my lab network and allowed me to connect a single computer. 

Needless to say the person I was trying to show and suggest Astaro to was completely unimpressed.

What I can't understand for the life of me is I've been using the ASG flawlessly for a month. Thing has been like a damn top. So what happened today?


This thread was automatically locked due to age.
Parents
  • 0
    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?
  • 0 in reply to Jayson
    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?
  • 0 in reply to Jayson
    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.
  • 0 in reply to drees
    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.
  • 0 in reply to Jayson
    I'd still check the disk...
  • 0 in reply to BrucekConvergent
    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
  • 0 in reply to BarryG
    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.
  • 0 in reply to harrisonpensa
    I had an issue with 100% cpu and it turns out that a dns forwarder was not responding. . . .


    Good to know.  Thanks!
  • 0 in reply to BrucekConvergent
    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!
  • 0 in reply to Gytis
    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.
  • 0 in reply to bitonw
    after clearing Proxycache, the cpu is going down to 10%
  • 0 in reply to ChristianZ
    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.
Reply
  • 0 in reply to ChristianZ
    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.
Children
  • 0 in reply to bitonw
    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.
  • 0 in reply to bitonw
    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
  • 0 in reply to RFCat_vk_01
    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?
  • 0 in reply to eganders_01
    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
  • 0 in reply to RFCat_vk_01
    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.
  • 0 in reply to bitonw
    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.