Hi,

I'm running MVBASE 1.3.02 with the latest patchset.

Hardware is: Sun Fire x4200; Dual Opteron/Dual Core model 275 (2.2GHz),
Windows Server 2003 x64/Standard Edition, 16G RAM.

Okay, now that we have that established. Yes, I know that version of
MVBASE is old; and that it's a 32-bit process running on x64 Windows,
but the problem I will describe happened before, on older hardware.

We have ~130 user licenses, with "averages" of 80-90 users on the
system at any one time. Usually under these conditions we scoot along
at ~1-5% CPU usage with occasional spikes to 10-ish (or so). Then,
occasionally, something will bump that WAY up, and one core ends up
maxed, the next one pretty high, and the other two mostly idle....

I have noticed when I do a LISTLINES it can produce this behavior (it
also freezes my session sometimes when I do LISTLINES)...

MVBASE itself is serving these connections via its own internal telnet
mechanism. I wanted to know (since all patches have been applied),
could it be that MVBASE's internal telnet server code isn't up to par
for serving that many users? If I offloaded it to the Windows telnet
service (either the regular win32 one or the telnetd included in
services for UNIX), might that help?

Any other suggestions, given that at this time I cannot upgrade or
change the multivalue product I'm using? Any way to track the
individual threads within MVBASE and see which ones are causing
trouble...?

Thanks,
Gabe

once wrote in <1156972075.548837.14880 (AT) m79g2000cwm (DOT) googlegroups.com>...
It's always been the advice, as I understand it, /not/ to run mvBase on
hyperthreaded or dual cpu configurations. We have a single 3.02GHz CPU
with hyperthreading disabled.
--
David Morris

Hi Gabe,

I am presuming you use mvTERM!

I run 100 users, all of them use mvTERM and it works very well. I am still
on an old server running NT4 SP6

Do you use AUTO-LOGOFF at all? This has helped to remove a lot of issues for
me ( AUTO-LOGOFF {account} (D or AUTO-LOGOFF 1-100 (D )

I also have a delay with LISTLINES sometimes, this is mainly when someone
just closes mvTERM while still logged on. But because I use AUTO-LOGOFF it
does actually clear and then LISTLINES completes

I also did have a similar issue with CPU a long time ago. I think it turned
out to be a program that either had a very tight loop or it got into a
deadly embrace! It did take me a while to track it down as I remember.

Have you considered moving up to mvBASE version 2?




<gabegreen (AT) gmail (DOT) com> wrote

gabegreen (AT) gmail (DOT) com wrote:
process' resources under semaphore... only to be preempted by the
detachment of a TCP/ip connection with the semaphore still linguring.
therefore any other process (such as yours doing the LISTLINES)
attempting to examine such a blocked resource will be held hostage
without exception handling logic since this is falsely assumed to be an
otherwise non-interruptable process.

another issue that could be occuring with the spikes is how MVBASE is
flushing their memory and whether or not it is triggered through
another process attempting to use large amounts of memory. depending
on the internal algorithms this can create havoc and penalize the
entire machine for periods, especially if all the other process'
workspace is flushed out without and they intern must drastically
compete to bring theirs back into the fold. surprisingly in many
cases, by increasing the frequency of any background flushing, you
allow the workspaces of processes to be re-flagged as "recently
used"... rather than being seen as equal candidates for abandoning
whenever a process requiring a large amount of virtual memory (eg. a
large report) is run. therefore, i would look to see if MVBASE exposes
a flush-period and make it "smaller" (eg. 5 minutes or less.) also,
there may be an equivalent of RD's "FLUSH" command that you could have
a watchdog phantom periodically run in smaller time increments. it's
unfortunate that such tweaking falls to the application/end-user, but
it is what it is.

you also might want to try a "where z" to see the state of the
logged-off processes for additional clues, right before performing a
"listlines".

dave

Understand that I am not a programmer by background; and also the PICK
model of everything is still very very new to me--but if I understand
this correctly that is not a good thing. I come from a UNIX background
and I have never encountered this (imagine doing a $ who or $ rwho and
having the system become furiously overloaded!) ....

As for MV implementations, can anyone speak for UniVerse (latest
version) and how it handles this exact scenario? (Better?) LISTLINES
does indeed seem to hang at the first line which is "hung" and then CPU
usage spikes way, way up.

I'd like to know if anyone knows if UniVerse in particular handles
detached TCP connections better than this version of MVBASE. Upgrading
to MVBASE 2 is not an option unfortunately.

Thanks again,
Gabe