Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 32 replies
  • Subscribers 3 subscribers
  • Views 15189 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

System grinds to a halt every few days, how do I trouble shoot?

exposuresolutions
My Astaro install 7.002 is proving to be very unstable in a production environment where we need strong stability. I need some advice of what logs to review to detect where the issue truly is. I am open to it being a hardware issue but wondering how I prove what the true case may be. 

-I have had IPS disabled for about a week, because it is way to flaky.
-New hardware, installs all went smoothly.
-I also don’t have any of the proxy services running as I don’t have internal users.
-I am hosting email, database and web services.

Today’s crash: Around 4:00 PM today the performance of the throughput dropped and moved to a crawl, simultaneously my access to the web admin stopped. But I was still getting limited packets through, until about 10 minutes later the whole system froze.  Luckily, I can remotely power cycle my hardware and after the cycle my system is back up and running smoothly. But it is missing logs from around 8:00AM today until the final episode of death. 

The last entry of the self monitoring log is everything is running fine: (2007:03:13-08:43:55 (none) daemon-watcher[3262]: Watching selfmonng.plx - running fine) then no entries until after my reboot.

Has anyone else been experiencing this type of issue? This also happened to me about 48 hours prior to.  Do I need to start creating issues with Astaro support? What can I look at and take note of to be more helpful in figuring this out? 

Many thanks.


This thread was automatically locked due to age.
Parents
  • 0
    If your description of the problem is the same as Bruce's I'd bet it is some sort of memory leak causing the problem leading to lots of swapping.

    If you can leave a console running with "top" updating frequently that should give you a clue.

    Has anyone reported this issue to Astaro?

    If you need rock solid stability, I'd stay with the V6, it has been pretty stable for us.
  • 0 in reply to drees
    im rebooting the system every 2 days at night. i think that asl 7.002 is not ready for production environment.
  • 0 in reply to drees
    The funny thing is, I have a customer that has had ASG for  5 months now. Running V6. And this exact same thing is happening to him now. On V6! On V6 though it is Hyperdyper doing this, and then the kernel kills the processes. Usually every few days it happens now.
  • 0 in reply to drees
    An update on my original post in this thread. 

    I have worked with the Astaro support crew and shared logs etc with them. The errors are occurring with a process around the hard drive controller. No one is certain that it is a hardware issue or device driver issue. So far the system has been up and running for almost 48 hours, which is about how long I have been experiencing before the next episode. There are some more system level log files the Astaro staff wants to look at to help remedy the issue.

    I don’t understand how it can be a device issue if it installs and runs just fine for the most part for a few days with thousands of concurrent connections and gigabytes of data transfer.

    Still a little nervous, but at least a quick reboot solves the outage.
  • 0 in reply to ReD-MaN
    The funny thing is, I have a customer that has had ASG for  5 months now. Running V6. And this exact same thing is happening to him now. On V6! On V6 though it is Hyperdyper doing this, and then the kernel kills the processes. Usually every few days it happens now.



    Hyperthreading??? I have that was on by default for my processor. Should we not have that one? I can disable it from within the BIOS. -Nick
  • 0 in reply to exposuresolutions
    --hyperdyper is a astaro process, not the same as multithreading.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent
    Had the same happen to me twice before I caught was going on...

    The responsible for the crash is the http proxy cache,  for some reason it keeps unneeded files on memory that are later passed to swap partition, this in time causes the sistem swap partition to fill up and after that the RAM fill's up too, then the system crashes....  what I did to work around this issue was to disable http proxy caching and cleaning the cache...  This resulted in lowering the swap space usage form 99% of a 1GB swap partition to 30%

    regards
  • 0 in reply to Jalmillategui
    Sounds like either a memory leak or the proxy cache is misconfigured.
  • 0 in reply to BrucekConvergent
    HT is not multithreading..it's faking a second cpu to keep the monstrous instruction pipeline of the p-4 full.  HT is actually starting to show cracks.  SQL under heavy loads with HT on has been showing corruption simply because HT isn't true multi threading and it steps on itself(HT does) causing data corruption.

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • 0 in reply to Jalmillategui
    I have the same problem, but my system crashes every hour! 

    As far as I have seen the system is running out of memory. I can see in the Reporting / Hardware of the webadmin that swap usage reaches 100%. 

    The system starts 2-4 new processes every minute: 

    root      2662  0.0  1.1  37804  5744 ?        Ss   16:29   0:02 confd [master]
    root      2710  0.0  0.9  37704  5128 ?        S    16:29   0:00  \_ confd [prpc]
    root      2719  0.0  1.1  38652  6048 ?        S    16:29   0:01      \_ prpc [system]
    root      2795  0.0  0.9  38628  4832 ?        S    16:29   0:00      \_ prpc [system]
    root      3034  0.4  0.9  38764  4800 ?        S    16:29   0:13      \_ prpc [system]
    root      3990  0.0  1.1  38632  5972 ?        S    16:30   0:00      \_ prpc [system]
    root      4644  0.0  1.1  38636  6012 ?        S    16:30   0:00      \_ prpc [system]

    and:

     5826  0.0  0.4   8112  2376 ?        Ss   16:33   0:00 /usr/local/bin/emailpki-sync.plx
    root      5972  0.0  0.4   8112  2372 ?        Ss   16:34   0:00 /usr/local/bin/emailpki-sync.plx
    root      6016  0.0  0.4   8112  2380 ?        Ss   16:34   0:00 /usr/local/bin/emailpki-sync.plx
    root      6077  0.0  0.4   8108  2384 ?        Ss   16:35   0:00 /usr/local/bin/emailpki-sync.plx

    Does anyone know what these processes are used for? How to avoid them?

    Ernst



    It shouldn't be the http proxy because it is disabled.
  • 0 in reply to eha
    I have the same problem, but my system crashes every hour! 

    As far as I have seen the system is running out of memory. I can see in the Reporting / Hardware of the webadmin that swap usage reaches 100%. 

    The system starts 2-4 new processes every minute: 

    root      2662  0.0  1.1  37804  5744 ?        Ss   16:29   0:02 confd [master]
    root      2710  0.0  0.9  37704  5128 ?        S    16:29   0:00  \_ confd [prpc]
    root      2719  0.0  1.1  38652  6048 ?        S    16:29   0:01      \_ prpc [system]
    root      2795  0.0  0.9  38628  4832 ?        S    16:29   0:00      \_ prpc [system]
    root      3034  0.4  0.9  38764  4800 ?        S    16:29   0:13      \_ prpc [system]
    root      3990  0.0  1.1  38632  5972 ?        S    16:30   0:00      \_ prpc [system]
    root      4644  0.0  1.1  38636  6012 ?        S    16:30   0:00      \_ prpc [system]

    and:

     5826  0.0  0.4   8112  2376 ?        Ss   16:33   0:00 /usr/local/bin/emailpki-sync.plx
    root      5972  0.0  0.4   8112  2372 ?        Ss   16:34   0:00 /usr/local/bin/emailpki-sync.plx
    root      6016  0.0  0.4   8112  2380 ?        Ss   16:34   0:00 /usr/local/bin/emailpki-sync.plx
    root      6077  0.0  0.4   8108  2384 ?        Ss   16:35   0:00 /usr/local/bin/emailpki-sync.plx

    Does anyone know what these processes are used for? How to avoid them?

    Ernst



    It shouldn't be the http proxy because it is disabled.


    how much memory do you ahve in the system?  What cpu, mobo, nic as well as hdd.

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • 0 in reply to William Warren
    Hi,

    the system has 512 MB ram, a P-III 1000 cpu, a 40GB disk with a 1GB swap and 2 3COM 905C-TX nics.

    Some further investigation showed, that the selfmonitoring daemon stated 1 to 2 times a minute, that the dns resolver was not running properly and started a new instance of it.

    I found a solution: Just reinstall the box [:D] . 

    But it was a pitty, that the 7.002 configuration backup could not be loaded on a fresh installed 7.001 system. I had to do the basic configuration until the up2date brought me the 7.002. Since my configuration is simple I just reentered the rules by hand. 

    Till now, the system runs. 

    Ernst
Reply
  • 0 in reply to William Warren
    Hi,

    the system has 512 MB ram, a P-III 1000 cpu, a 40GB disk with a 1GB swap and 2 3COM 905C-TX nics.

    Some further investigation showed, that the selfmonitoring daemon stated 1 to 2 times a minute, that the dns resolver was not running properly and started a new instance of it.

    I found a solution: Just reinstall the box [:D] . 

    But it was a pitty, that the 7.002 configuration backup could not be loaded on a fresh installed 7.001 system. I had to do the basic configuration until the up2date brought me the 7.002. Since my configuration is simple I just reentered the rules by hand. 

    Till now, the system runs. 

    Ernst
Children
  • 0 in reply to eha
    I've heard through the grapevine that some Kernel updates may be in the forthcoming up2date package (in a week or so)... perhaps they will address the memory allocation issue---it seems to be happening in all sorts of different processes on different systems... we'll see.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent
    I doubt that a kernel update would affect any memory issues unless there was a memory leak in the kernel itself. Hopefully the other updates they release along with it address the memory leaks.

    eha, do you have a full process list from when the system became unresponsive?
  • 0 in reply to drees
    When mine does that most of the time the logs go missing, so there is nothing to look at or review.

    Once I have found two apps misbehaving, I covered that in another thread.

    Ian M
  • 0 in reply to BrucekConvergent
    I've heard through the grapevine that some Kernel updates may be in the forthcoming up2date package (in a week or so)... perhaps they will address the memory allocation issue---it seems to be happening in all sorts of different processes on different systems... we'll see.


    We have an issue where the box became unresponsive on a production 7.002 220 appliance. It was due to a problem in communication with mysql and the self monitor. That was fixed (from what I can tell) by reloading the box. Not that big a deal. 

    Unfortunately, we now have an issue where SSL VPN will stop responding. The rest of the box appears to run fine (it's the main box at the edge), but we have to reboot it to get it back to normal.
  • 0 in reply to drees
    I doubt that a kernel update would affect any memory issues unless there was a memory leak in the kernel itself. Hopefully the other updates they release along with it address the memory leaks.

    eha, do you have a full process list from when the system became unresponsive?


    This issue isn't the kernel per se.  It is astaro has the swappiness set too high so the machine swaps out instead of reclaiming file cache space.  Also Astaro v7 is a pig and 512 megs of ram is not sufficient.  Astaro needs to set vm.swappiness to zero and increase the minimum requirements to 1 gigabyte of ram for the low end and 2 gigs for the midrange.  Higher end customers need 4 gigs(the 32-bit limit w/o PAE) for decent performance.  During my runs of v7 the machine was constantly swapping up to a quarter gigabyte.  Linux will not swap unless either the kernel is mistuned, the software is a memory hog, or both.  In Astaro's case it's both.

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • 0 in reply to William Warren
    So, by working directly with a friendly Astaro support person they helped me to get my machine more stable. Everything they could trace down had to do with IRQs. So we placed the following, “no APIC” in the Kernal boot parameters using the Grub editor.

    Thus limiting the IRQs to 15 and I disable a few hardware ports on the server such as the pare and serial ports to allow for less IRQ assignments. So far my system has stayed online with no crashing for 4 days. Much better than the 24 to 48 hours it was hardly working for. There seems to be in my opinion something with the way it uses swapdrive space, because after  a reboot my CPU would be pegged at 90% for about 10 minutes cleaning out the swap.
  • 0 in reply to drees

    ....
    eha, do you have a full process list from when the system became unresponsive?


    Sorry, I have not a full process list. I reinstalled the system - this time without intrusion detection - and it still works (uptime 6d 18h 58m).

    But I see an slowly increasing use of swap space. It was about 16% in the beginning and slowly increased to 25% in teh last 6 days.
  • 0 in reply to eha
    We have the same problem on an ASG220 / 7.002 cluster. Either RAM fills up or swap fills up. ASG220 dead in 2-3 days. The problem (for us at least) is that httpproxy (ie. web admin) is leaking. When you boot it's around 40Mb, 2-3 days later it's chewing through 1.5Gb of RAM. I'm SSH'ing in every 1-2 days and manually restarting the middleware (perhaps I should cron it lol). I'll check out the vm.swappiness.

    The ASG's are _SERIOUSLY_ underpowered to run 7.00x. If you must run 7 with a lot of proxies running 2-4Gb of RAM is recommended. If you have an ASG downgrade to 6.x. 7 is also very very buggy. But this is nothing new with an new Astaro release. They usually take 6-8 months to get it "right".