Is 4000 users too high a number for filePro

[Fairlight]

At Thu, Jun 09, 2005 at 04:04:35PM -0400 or thereabouts, 
suspect Kenneth Brody was observed uttering:
> 
> Someone else posted about 4000 copies of a 500K dclerk would
> require 2GB of RAM.  However, you have to remember that the
> code segments are sharable, meaning that only one copy of the
> executable is in memory, regardless of the number of processes
> running it.  Only the data has separate copies.  You would
> have to check how much memory the data segment requires in
> your partiular database.

Actually, that was my first analysis.  And it's low.  Look at the
subsequent number, which was VSZ, and it was in the 2.4 or 2.6MB mark for
the image, as displayed in 'ps' output, which comes directly from proc, and
hence the kernel in linux.  

Okay, I tried it on another system:

filepro  11434  0.1  0.0  2300  860 pts/0    S    17:10   0:00
/var/appl/fp/rclerk
filepro  11437  0.1  0.0  2300  800 pts/3    S    17:10   0:00
/var/appl/fp/rclerk

~2.3MB--each.  

A breakdown, for instance, of rclerk, reveals the following:

Name:   rclerk
State:  S (sleeping)
Tgid:   11434
Pid:    11434
PPid:   11377
TracerPid:      0
FDSize: 256
Groups: 0
VmSize:     2300 kB
VmLck:         0 kB
VmRSS:       860 kB
VmData:      204 kB
VmStk:        16 kB
VmExe:       476 kB
VmLib:      1444 kB

I'm not an expert on the proc subsystem.  However, it appears to me that
even if VmLib -is- shared (which makes sense to me), then you're still
eating ~856K per instance.  And then proc-ps is basically including VmLib
in its readings, which I can accept.

Likewise, if we revise the sshd readings, and assume that the VmLib is
shared, the picture isn't as bleak:

VmSize:     5444 kB
VmLck:         0 kB
VmRSS:      2296 kB
VmData:      796 kB
VmStk:        24 kB
VmExe:       308 kB
VmLib:      4088 kB

The way I'm interpreting this, unless someone wishes to correct me, is that
you subtract VmLib from VmSize, and that should be the per-instance memory
use for the process.

Given the above assumptions:

rclerk:  ~856KB
856*1024
876544
876544 * 4000
3,506,176,000  (3.5 Gigs)

sshd:  ~1356KB

5444-4088
1356
1356*1024
1388544
1388544 * 4000
5,554,176,000  (5.5 Gigs)

You're looking at 9 Gigs total, -just- to keep the system out of swap,
-just- with sshd and rclerk running, with no margin for overhead.  About a
third of what I think I calculated earlier, based on what I think is a
better understanding of the way proc-ps reports memory as summarized from
what's really extant in proc.

It's still not pretty.  And you're right, Ken.  Data entry...probably
you're not going to notice much.  Unless someone's using INKEY liberally!
*laugh*

But certain operations would indeed magnify as scaled, and disk I/O is
going to be the next bottleneck if you can get a fast enough CPU.

I still maintain that 4000 users on a single system is Not A Good Idea[tm].
However, I stand corrected on my earlier assumptions.  They're higher than
the raw binary figures, but not as high as 'ps' will report them.

Unless I'm wrong about VmLib breaking out and all being shared.  I have to
believe it is, except for one thing (and this confuses me for some strange
reason):

machine:~ # ldd /appl/fp/rclerk
        not a dynamic executable
machine:~ # file /appl/fp/rclerk
/var/appl/fp/rclerk: setuid ELF 32-bit LSB executable, Intel 80386, version
1 (GNU/Linux), for GNU/Linux 2.2.5, dynamically linked (uses shared libs),
stripped

This makes not a whit of sense to me.  If it's not dynamic in 'ldd', how is
it dynamic to 'file'?  It is, or it isn't shared.  Pick one.  But I have
zero idea how I'm getting conflicting readings.  I could verify more of my
theory on VmLib and be more definitive if I could find out which libs it
thinks it's loading.  Unfortunately, well...see above.  @-|

(SuSE 9.0, fP 5.0.13R4 on this, if anyone's interested.)

Boy, that last bit leaves me scratching my head.  Never seen a
contradiction like that before.  Someone educate me, please.  It's going to
keep me awake nights...

mark->
-- 
          *****   Fairlight Consulting's Software Solutions   *****
OneGate Universal CGI Gateway:                  http://onegate.fairlite.com/
FairPay PayPal Integration Kit:                 http://fairpay.fairlite.com/
RawQuery B2B HTTP[S] Client & CGI Debugger:     http://rawquery.fairlite.com/
Lightmail Mail Sending Agent:                   http://lightmail.fairlite.com/
FairView Image Viewer for Integration:          http://fairview.fairlite.com/