Machine chokes during walk

[marcos1]

Hello,

We have a commercial license for enterprise webinator and recently switched from Solaris to RedHat linux. Since the move we are experiencing a problem during walks which ends in the machine becoming completely unresponsive (you can ping it but cannot ssh in or pull up a web page from it). What happens is we start a walk on a server that has around 60,000 pages (we allow 1 server, 15 threads). It works fine at first though the process (texis) slowly grabs more and more memory (the machine has a GB and the process will have as much as 700MB when it dies). It seems fine on processor usage -- using no more than 50% of the CPU and less than 1% when it dies.

At some point the walk slows down significantly (in the beginning it gets as many as 10 pages per second -- at the end it is about one page every 10 seconds) -- but it does not give up the memory. The machine is very sluggish at that point -- very slow to even return a command prompt or list the contents of a directory. Then it becomes completely unresponsive. After a power-cycle it behaves normally again until we go through the whole thing again.

The server is only being used for webinator.

Any ideas?? Any other info I can provide to help diagnose this?

Thanks,

Marcos

[mark]

What version of redhat?
What version of linux (uname -a)?
What's the overall memory and swapping status when it bogs down? My guess is that it's swapping to disk because there's too much memory being used.

Try fewer threads, like 5 or 2.

[marcos1]

RedHat 9
Linux 2.4.20-8

Memory goes down to only a little available right away (though it is unclear to me where it all goes -- because if I add up all the memory used by processes it does not add up to the total -- but anyway)

Swap is 0 at first and is very high when it is close to choking...

Why does the walker use so much memory? Isn't it writing the pages to disk as it gets them? Also why did we not have this problem on an older Solaris box (same exact walk settings) -- was it just slower overall so it could not eat up as much memory as fast?

In any case I'll try reducing the number of threads...

Thanks,

Marcos

[mark]

In general it shouldn't use that much memory, but I wanted to see if it's related to the large number of threads.