5.0.5 upgrade from 5.0.2 (enterprise editions)

5.0.5 upgrade from 5.0.2 (enterprise editions)

Post by Mike Parke » Sat, 31 Oct 1998 04:00:00



I have a post-upgrade problem:

Computer:  Compaq Proliant 1500, duel processor Pentium 166,
                 RAID 5 on Compaq IDA, Netflex-3 NIC (100MB), 16GB Compaq
SCSI DAT tape

OS:  was SCO Openserver 5.0.2 Enterprise Edition, 130-user
               Compaq EFS 5.13
        now SCO Openserver 5.0.5 Enterprise Edition, 130-user
               Compaq EFS 5.21
               SMP

Main App:  Custom BBX Inventory Control / Order Entry System
Network:  Ethernet, TCP/IP, ISDN router to internet ISP

Other upgrade issues having been resolved or worked around I am left with:

When the morning shift (about 25 users) logs in all goes well.  About noon,
as the second shift overlaps the first, the system balks at allowing more
than about 70 users on the system.  By about 3 o'clock, things settle down
and we can get up to our working number of 84 logins.

There is nothing added to */crontabs/root, except a backup script that runs
at midnight.  All stune parameters are adequate for a 130-user system.  All
licenses are registered.  There are no errors or usual messages on the
console or in /usr/adm/messages, syslog or syslogt.  No failures in any
streams.  TCP/IP stack is configures for 256 connections and there are 198
/dev/ttyp* entries.  There are no internet, NIS, or PC-Interface services
running.  The system worked wonderfully prior to adding the second
processor and SMP, and performing the 5.0.5 upgrade.  Connections are made
using James River Group ICE.TCP telnet (SCO ANSI emulation).

What else do I need to look at that might have been changed during the
upgrade?  What change(s) in the versions would cause this situation?  I
have been installing and administering SCO systems for over eight years,
and this one has me stumped!

I still need to add an ADIC 40GB tape drive and a DPT Smart-IV RAID
controller and an external drive tower and file systems to the server.  I
am holding off until I can resolve this user login issue.  I am already
facing a user revolt and disgruntled management.

I will discuss my other issues with the 5.0.5 upgrade and it's
documentation with SCO at next months QBB in Dallas.

Best Regards,
Mike Parker
Technical Services
MicroCity LAN Engineering Services

As usual, management says that my problems are my own and they will disavow
any knowledge of my activities.

 
 
 

5.0.5 upgrade from 5.0.2 (enterprise editions)

Post by Bob Baili » Sat, 31 Oct 1998 04:00:00


Well, if you've followed this newsgroup for any length of time, you've probably
notice a consensus that it's better to do a fresh install rather than an
in-place upgrade to 5.0.5, even though the IPU is much improved over previous
attempts.

How exactly does the system 'balk' at letting new users log in?  Any error
msgs or warnings, or does each login just hang after entering the password?
When this is happening, can you login normally at the console?

Two years ago I ran into a problem with bbx when I exceeded 32 users:  one of
the kernel semaphore parameters was insufficient, and although this didn't
seem to affect bbx directly, I couldn't get into SCO Merge.  Try increasing
all the semaphore parameters, even those not adjustable thru configure(ADM).

Bob


> I have a post-upgrade problem:

> Computer:  Compaq Proliant 1500, duel processor Pentium 166,
>                  RAID 5 on Compaq IDA, Netflex-3 NIC (100MB), 16GB Compaq
> SCSI DAT tape

> OS:  was SCO Openserver 5.0.2 Enterprise Edition, 130-user
>                Compaq EFS 5.13
>         now SCO Openserver 5.0.5 Enterprise Edition, 130-user
>                Compaq EFS 5.21
>                SMP

> Main App:  Custom BBX Inventory Control / Order Entry System
> Network:  Ethernet, TCP/IP, ISDN router to internet ISP

> Other upgrade issues having been resolved or worked around I am left with:

> When the morning shift (about 25 users) logs in all goes well.  About noon,
> as the second shift overlaps the first, the system balks at allowing more
> than about 70 users on the system.  By about 3 o'clock, things settle down
> and we can get up to our working number of 84 logins.

> There is nothing added to */crontabs/root, except a backup script that runs
> at midnight.  All stune parameters are adequate for a 130-user system.  All
> licenses are registered.  There are no errors or usual messages on the
> console or in /usr/adm/messages, syslog or syslogt.  No failures in any
> streams.  TCP/IP stack is configures for 256 connections and there are 198
> /dev/ttyp* entries.  There are no internet, NIS, or PC-Interface services
> running.  The system worked wonderfully prior to adding the second
> processor and SMP, and performing the 5.0.5 upgrade.  Connections are made
> using James River Group ICE.TCP telnet (SCO ANSI emulation).

> What else do I need to look at that might have been changed during the
> upgrade?  What change(s) in the versions would cause this situation?  I
> have been installing and administering SCO systems for over eight years,
> and this one has me stumped!

> I still need to add an ADIC 40GB tape drive and a DPT Smart-IV RAID
> controller and an external drive tower and file systems to the server.  I
> am holding off until I can resolve this user login issue.  I am already
> facing a user revolt and disgruntled management.

> I will discuss my other issues with the 5.0.5 upgrade and it's
> documentation with SCO at next months QBB in Dallas.

> Best Regards,
> Mike Parker
> Technical Services
> MicroCity LAN Engineering Services

> As usual, management says that my problems are my own and they will disavow
> any knowledge of my activities.

--
Bob Bailin


 
 
 

5.0.5 upgrade from 5.0.2 (enterprise editions)

Post by Bob Baili » Sat, 31 Oct 1998 04:00:00


I forget to add:

If you're waiting on adding a DPT SmartRaid IV, check out their new Millenium
product instead.  Seems to be much faster than the SRIV, esp if you're
planning to setup a RAID 5.  It's also U2W-LVD capable, which is important
if you have 128 users on a common inventory/order processing database.
--
Bob Bailin

 
 
 

5.0.5 upgrade from 5.0.2 (enterprise editions)

Post by Bill Vermilli » Sat, 31 Oct 1998 04:00:00




>I have a post-upgrade problem:
>When the morning shift (about 25 users) logs in all goes well.
>About noon, as the second shift overlaps the first, the system
>balks at allowing more than about 70 users on the system. By about
>3 o'clock, things settle down and we can get up to our working
>number of 84 logins.

Please define 'balks at allowing ..' as that term is rather
nebulous.  Does it mean, no one gets a prompt to start a new
session, or do they get logged in and things are slow, or does it
print error messages that indicate you can't log in.

Quote:>What else do I need to look at that might have been changed during
>the upgrade? What change(s) in the versions would cause this
>situation? I have been installing and administering SCO systems for
>over eight years, and this one has me stumped!

I'd say don't go looking at what has been changed until you find
the root of the problem.  Run sar during these periods - I normally
specify 10 interations with 15 second spacing - and then take a
look at the output.  That should tell you a lot.

Memory?  Swap?  You didn't indicate either in your post.

--

 
 
 

5.0.5 upgrade from 5.0.2 (enterprise editions)

Post by Bill Vermilli » Sat, 31 Oct 1998 04:00:00




>Two years ago I ran into a problem with bbx when I exceeded 32
>users: one of the kernel semaphore parameters was insufficient, and
>although this didn't seem to affect bbx directly, I couldn't get
>into SCO Merge. Try increasing all the semaphore parameters, even
>those not adjustable thru configure(ADM).

BBX is a resource hog - at least on the systems I've seen.  On an
upgrade I recall having to reset a lot of kernel parameters to make
it work.  Lock files were 1t 1500 - far above the SCO recommended
maximum.  New version of the ap software made that invalid as they
opened even more files.  Current lockfile limit had to bumped to
3000 file - and typically 2500-2700 files are open at any one time.

This is with about 85 users.

--

 
 
 

5.0.5 upgrade from 5.0.2 (enterprise editions)

Post by Bob Baili » Sat, 31 Oct 1998 04:00:00


The SCO recommended maximum for file locks is a joke, especially for a program
that makes extensive use of record locking as opposed to file locking.  In
BBx, each open file requires a minimum of 2 record locks per user.  With 80
users and dozens of files open per user (some apps open all possible files at
once to speed things up), just do the math and 3000 file locks it the end result.
All this is irrelevant anyways, because MAX_FLCKREC is usually set to 0, allowing
dynamic allocation as needed (under 5.0.x).




> >Two years ago I ran into a problem with bbx when I exceeded 32
> >users: one of the kernel semaphore parameters was insufficient, and
> >although this didn't seem to affect bbx directly, I couldn't get
> >into SCO Merge. Try increasing all the semaphore parameters, even
> >those not adjustable thru configure(ADM).

> BBX is a resource hog - at least on the systems I've seen.  On an
> upgrade I recall having to reset a lot of kernel parameters to make
> it work.  Lock files were 1t 1500 - far above the SCO recommended
> maximum.  New version of the ap software made that invalid as they
> opened even more files.  Current lockfile limit had to bumped to
> 3000 file - and typically 2500-2700 files are open at any one time.

> This is with about 85 users.

> --


--
Bob Bailin