Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 32 replies
  • Subscribers 3 subscribers
  • Views 15152 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 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
Reply
  • 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.
Children
No Data