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

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.

im rebooting the system every 2 days at night. i think that asl 7.002 is not ready for production environment.

Thanks for all the feed back, unfortunately I started with 7.001 just recently, I don't believe they sell V6.  I haven’t noticed the HD light being stuck on, but the ASL is about 25 miles away in a datacenter. I am now cycling the power remotely. I don’t see anything in the Kernel Logs to lead me in any direction. 

I sent my issue to Astaro Support yesterday and have yet to hear any response back from their team. I have bugged my local distributor, whom I purchased the software from and even had help setup the solution.  But it sounds like they are not experienced enough with V7, they just say how V6 is so wonderful! I think they are in for a rude awaking with accounting/reporting being removed and V7’s lack of stability so far.

I am on the verge of wishing I just kept with Sonicwall. I know ASL die-hards hate them, but at least they run for years without dieing and support most of the options that I was wanting. The only draw back was going to be the cost of the Pro level Sonicwall that I needed for throughput and connections.

What features of the asl are you using?  I may have another solution for you..[:)]

Update on my situation... here's what I just sent to Astaro to start a ticket on the "dead box" issue (it may apply to some of you other guys):

/QUOTE
I've been testing Version 7.0 (now 7.002) on a test system... been having problems with the system becoming totally unresponsive (no pings, no SSH console, No webadmin, no traffic flows)... when this occurs, the hard drive activity light goes solid on (there's a lot of disk activity going on).  Unfortunately, even though this has been happening on this and another test system (I swapped hardware for fun; both systems previously ran Version 6.x without a hitch) since Version 7 was released, I have not started a ticket because I couldn't see what was going on.  This is apparently a common thing with V7, as some others on the UBB are having the same "mystery" occur on their systems.  Well, I left the console up with "top" running all day today, and lo and behold I saw what was happening.  The httpproxy daemon just goes wild randomly, sucking up all the RAM it can (it gets up to about 92% of available memory, before the console dies-but it uses very little CPU when this is happening)... so the kernel starts pounding the swap file, which eats the CPU up.  I theorize that after a while the httpproxy daemon just dies (or the kernel zaps it), then the system busies itself cleaning up the swap.. then the system returns to normal operation.  After the "fun", the total memory usage dips down real low, like to almost 32%.  The system is not under heavy usage... it happened twice today, both times it happened right when I launched my web browser...

Yep, exactly as suspected, and now we know what process is responsible.

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.

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.

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

--hyperdyper is a astaro process, not the same as multithreading.

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

Sounds like either a memory leak or the proxy cache is misconfigured.

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.

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.