Is there a BIG version of Proc32?

An old customer of mine with a slowly growing system is bumping up against
the 2000 process limit on their QNX4 system. Is there a special version of
Proc32 somewhere that busts the Proc32 -p 2000 pid/vid limit?

Ken Schumm wrote:

An old customer of mine with a slowly growing system is bumping up against
the 2000 process limit on their QNX4 system. Is there a special version of
Proc32 somewhere that busts the Proc32 -p 2000 pid/vid limit?

Not that I’m aware of. It’s not just an artifical limit IIRC, it’s
related to segmentation limits for the data segment in Proc.

\

Cheers,
Adam

QNX Software Systems
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

“Adam Mallory” <amallory@qnx.com> wrote in message
news:con8tj$a65$1@inn.qnx.com

Ken Schumm wrote:
An old customer of mine with a slowly growing system is bumping up
against
the 2000 process limit on their QNX4 system. Is there a special version
of
Proc32 somewhere that busts the Proc32 -p 2000 pid/vid limit?

Not that I’m aware of. It’s not just an artifical limit IIRC, it’s
related to segmentation limits for the data segment in Proc.

Thanks Adam. I guess the band-aid fix is out.

Adam Mallory <amallory@qnx.com> wrote:

Ken Schumm wrote:
An old customer of mine with a slowly growing system is bumping up against
the 2000 process limit on their QNX4 system. Is there a special version of
Proc32 somewhere that busts the Proc32 -p 2000 pid/vid limit?

Not that I’m aware of. It’s not just an artifical limit IIRC, it’s
related to segmentation limits for the data segment in Proc.

They may be able to examine how/where they use process table entries
and reduce them…

They’re used by: processes, proxies, and vcs.

Often there isn’t much that can be done about processes – they run
what they need to.

Often the best place to look for saving is in vcs – if they’re explicitly
creating vcs, to they set the vc share flag?

If they’re opening a lot of files off-node, can some of that data be
moved on node? Are they holding-open files that they could close then
re-open?

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

David Gibbs <dagibbs@qnx.com> wrote:
DG > Adam Mallory <amallory@qnx.com> wrote:

Ken Schumm wrote:
An old customer of mine with a slowly growing system is bumping up against
the 2000 process limit on their QNX4 system. Is there a special version of
Proc32 somewhere that busts the Proc32 -p 2000 pid/vid limit?

Not that I’m aware of. It’s not just an artifical limit IIRC, it’s
related to segmentation limits for the data segment in Proc.

DG > They may be able to examine how/where they use process table entries
DG > and reduce them…

DG > They’re used by: processes, proxies, and vcs.

DG > Often there isn’t much that can be done about processes – they run
DG > what they need to.

DG > Often the best place to look for saving is in vcs – if they’re explicitly
DG > creating vcs, to they set the vc share flag?

DG > If they’re opening a lot of files off-node, can some of that data be
DG > moved on node? Are they holding-open files that they could close then
DG > re-open?

DG > -David
DG > –
DG > David Gibbs
DG > QNX Training Services
DG > dagibbs@qnx.com

Or could you just add an additional QNX box and put some of the
processes on that box and IPC ACROSS THE NETWORK!

Bill Caroselli <qtps@earthlink.net> wrote:

Or could you just add an additional QNX box and put some of the
processes on that box and IPC ACROSS THE NETWORK!

Um…actually… that might not buy you anything… depends on how
many extra VCs you need to talk to those processes acccross the network.

In fact, it could be worse, consider:

Before: 4 processes, each talks to every other process. Total 4 proc table
entries.

After 2 processes (A,B) on node 1, 2 processes (C,D) on node 2.
Node 1 also has 4 VCs - A-C, A-D, B-C, B-D. (So does node 2.)
After: 6 proc table entries on node 1.

Oops.

You’d have to carefully select which processes to migrate, migrating
them in self-talking groups with limitted outside-talk.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:coni76$gdt$3@inn.qnx.com

David Gibbs <> dagibbs@qnx.com> > wrote:
DG > Adam Mallory <> amallory@qnx.com> > wrote:
Ken Schumm wrote:
An old customer of mine with a slowly growing system is bumping up
against
the 2000 process limit on their QNX4 system. Is there a special
version of
Proc32 somewhere that busts the Proc32 -p 2000 pid/vid limit?

Not that I’m aware of. It’s not just an artifical limit IIRC, it’s
related to segmentation limits for the data segment in Proc.

DG > They may be able to examine how/where they use process table entries
DG > and reduce them…

DG > They’re used by: processes, proxies, and vcs.

DG > Often there isn’t much that can be done about processes – they run
DG > what they need to.

DG > Often the best place to look for saving is in vcs – if they’re
explicitly
DG > creating vcs, to they set the vc share flag?

DG > If they’re opening a lot of files off-node, can some of that data be
DG > moved on node? Are they holding-open files that they could close
then
DG > re-open?

DG > -David
DG > –
DG > David Gibbs
DG > QNX Training Services
DG > > dagibbs@qnx.com

Or could you just add an additional QNX box and put some of the
processes on that box and IPC ACROSS THE NETWORK!

Nope, none of that will work. No off-node files are opened, there are no
permanent VCs (the VC burst is only a few at most) and not many proxies are
used either. This node handles customer logins, and the customer protocol
requires a context so one process is spawned for each customer login. When
originally designed years ago there were two factors working in our favor.
One, the customers were charged for connect time so they would login, do
their work, then logout. Two, the sytem was totally FLEET based and the
software was designed to allow new nodes to be dropped in as needed to
handle the workload. Then the internet came along and everyone wanted to
connect via internet, so connect time was no longer billed and people no
longer logged out. The changes to support the internet were IP based so
FLEET was largely gutted, which screwed up the ability to drop in new nodes.
The current architecture has a manager which allocates and tracks login
processes and spawning them on another node won’t buy anything due to the
VCs that will be consumed. For this and various other reasons it’s looking
like a redesign will be required. We were going to do that anyway but
thought a larger Proc would buy us some time. As usual, it’s holiday crunch
mode.

Ken Schumm wrote:

Nope, none of that will work. No off-node files are opened, there are no
permanent VCs (the VC burst is only a few at most) and not many proxies are
used either. This node handles customer logins, and the customer protocol
requires a context so one process is spawned for each customer login. When
originally designed years ago there were two factors working in our favor.
One, the customers were charged for connect time so they would login, do
their work, then logout. Two, the sytem was totally FLEET based and the
software was designed to allow new nodes to be dropped in as needed to
handle the workload. Then the internet came along and everyone wanted to
connect via internet, so connect time was no longer billed and people no
longer logged out. The changes to support the internet were IP based so
FLEET was largely gutted, which screwed up the ability to drop in new nodes.
The current architecture has a manager which allocates and tracks login
processes and spawning them on another node won’t buy anything due to the
VCs that will be consumed. For this and various other reasons it’s looking
like a redesign will be required. We were going to do that anyway but
thought a larger Proc would buy us some time. As usual, it’s holiday crunch
mode.

What is the number of connections you’re looking to support? If it’s
another order of magnitude, then I think other things would break down
with a process table so large (at least in its original form).

It might be possible to make changes through custom engineering, but any
change isn’t going to be a solution, simply a delay of the inevitable.

\

Cheers,
Adam

QNX Software Systems
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

“Adam Mallory” <amallory@qnx.com> wrote in message
news:coopi8$g3j$1@inn.qnx.com

Ken Schumm wrote:
[…]

What is the number of connections you’re looking to support? If it’s
another order of magnitude, then I think other things would break down
with a process table so large (at least in its original form).

It might be possible to make changes through custom engineering, but any
change isn’t going to be a solution, simply a delay of the inevitable.

If we go this way it would only be to buy some time so I wouldn’t want to go
too large. 4000 processes would buy us a lot of time since it took years to
bump into the current limit. I’ll contact custom engineering if we want to
look further into this. Thanks a bunch!