[9fans] memory use

[9fans] memory use

[john]

I've just installed Plan 9 on a new terminal that will soon become my
new auth/cpu/file server.  It's a PIII@1Ghz, 128MB of RAM, and a 500GB
hard drive.  I made a 10GB fossil and gave the rest to venti.  When I
boot, I find that pretty much all of the 128 megs is being used, and
of course since swap doesn't work I didn't even bother to make a
partition for it.  Besides the obvious "buy more RAM", do you guys
have any suggestions for reducing memory use?  I have run Plan 9 on
machines with 32 MB in the last few years so I presume this must have
something to do with the size of the file systems--correct?

Thanks

John

Re: [9fans] memory use

[Charles Forsyth]

> and of course since swap doesn't work I didn't even bother to make a
> partition for it.

i don't think i'd go as far as that for a cpu server, or even a terminal.
(paging over the net is tedious, but better than shutting things down
on overload.)  file servers should be configured not to page (there is no need).

Re: [9fans] memory use

[Lyndon Nerenberg]

>  Besides the obvious "buy more RAM", do you guys
> have any suggestions for reducing memory use?  I have run Plan 9 on
> machines with 32 MB in the last few years so I presume this must have
> something to do with the size of the file systems--correct?

venti(8) has a very good discussion of memory usage and how to tune it.
But there doesn't seem to be any way of displaying the memory usage of a
running venti so it's going to take some trial and error to come up with
the right values.

--lyndon

[9fans] nextstation

[Benjamin Huntsman]

[-- Attachment #1: Type: text/plain, Size: 236 bytes --]

I just remembered, I've got an old Nextstation Turbo Color under my desk...
I know there was a port for it at one time...

Does anyone still have the sources?  I didn't see them on the kernel history site.

Thanks in advance!



[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2532 bytes --]

Re: [9fans] memory use

[john]

>>  Besides the obvious "buy more RAM", do you guys
>> have any suggestions for reducing memory use?  I have run Plan 9 on
>> machines with 32 MB in the last few years so I presume this must have
>> something to do with the size of the file systems--correct?
>
> venti(8) has a very good discussion of memory usage and how to tune it.
> But there doesn't seem to be any way of displaying the memory usage of a
> running venti so it's going to take some trial and error to come up with
> the right values.
>
> --lyndon

I tried setting mem, bcmem, and icmem all to 1M but no improvement.
They are not set by default, and trying the configuration shown in the
man page actually prevents the system from booting (out of memory).

John

Re: [9fans] memory use

[Russ Cox]

> I've just installed Plan 9 on a new terminal that will soon become my
> new auth/cpu/file server.  It's a PIII@1Ghz, 128MB of RAM, and a 500GB
> hard drive.  I made a 10GB fossil and gave the rest to venti.  When I
> boot, I find that pretty much all of the 128 megs is being used, and
> of course since swap doesn't work I didn't even bother to make a
> partition for it.  Besides the obvious "buy more RAM", do you guys
> have any suggestions for reducing memory use?  I have run Plan 9 on
> machines with 32 MB in the last few years so I presume this must have
> something to do with the size of the file systems--correct?

490 GB of venti storage is 900 arenas or so, and venti
requires having at least two disk blocks in its buffer
cache for each arena.  At 8k disk blocks, that's going
to be about 16MB just for those blocks, no matter
what you set bcmem to.

I haven't studied this in detail, but I think that if you
made larger arenas (say 1.5GB instead of 0.5GB)
then you'd end up with less memory usage by venti.
That would require starting over, of course.

Another solution would be to just use less of the
disk for venti, since most people seem to use only a
very small amount of venti storage.  You could split
the disk into multiple arena partitions and for now just
use one, and then if you need more in the future you
could turn them on as needed.  By then maybe the
disk will sit in a machine with more memory.

Russ

Re: [9fans] memory use

[erik quanstrom]

> I tried setting mem, bcmem, and icmem all to 1M but no improvement.
> They are not set by default, and trying the configuration shown in the
> man page actually prevents the system from booting (out of memory).
>
> John

perhaps i'm pointing out the obvious.  have you tried something as simple
as ps to identify culprits?

	ps -a|sort +4nr|sed 10q

on my system, i get

(names changed to protect the guilty)

xxx          151013    1:48   0:21   346784K Pread    fs ?
yyy          157084    0:11   0:03   299780K Pread    fs ?
yyy          162896    0:04   0:01   281240K Pread    fs ?
zzz          158720   13:31   2:09   132616K Pread    fs ?
[...]

suprise, suprise.  it's upas/fs leading the charge.
(the leading upas/ is of course dropped from the fs entries,
just as it would be for /bin/ls.)

venti & fossil, being threaded programs sharing a heap,
will appear to be using more memory than they are.  ps doesn't
provide any easy way of figuring this out but if /proc/$pid/segment
shows >1 references (the last field) for the Data segment, then
there are that many procs sharing the same heap.  baring
enormous executables, text, stacks or numbers of procs sharing
the same heap, this should be pretty close the memory usage
for the entire set of procs.

- erik

Re: [9fans] memory use

[john]

>> I tried setting mem, bcmem, and icmem all to 1M but no improvement.
>> They are not set by default, and trying the configuration shown in the
>> man page actually prevents the system from booting (out of memory).
>>
>> John
>
> perhaps i'm pointing out the obvious.  have you tried something as simple
> as ps to identify culprits?
>
> 	ps -a|sort +4nr|sed 10q
>
> on my system, i get
>
> (names changed to protect the guilty)
>
> xxx          151013    1:48   0:21   346784K Pread    fs ?
> yyy          157084    0:11   0:03   299780K Pread    fs ?
> yyy          162896    0:04   0:01   281240K Pread    fs ?
> zzz          158720   13:31   2:09   132616K Pread    fs ?
> [...]
>
> suprise, suprise.  it's upas/fs leading the charge.
> (the leading upas/ is of course dropped from the fs entries,
> just as it would be for /bin/ls.)
>
> venti & fossil, being threaded programs sharing a heap,
> will appear to be using more memory than they are.  ps doesn't
> provide any easy way of figuring this out but if /proc/$pid/segment
> shows >1 references (the last field) for the Data segment, then
> there are that many procs sharing the same heap.  baring
> enormous executables, text, stacks or numbers of procs sharing
> the same heap, this should be pretty close the memory usage
> for the entire set of procs.
>
> - erik


I get venti as the largest process.  upas/fs is not a potential
culprit because this is a freshly installed terminal, meaning upas/fs
reads in ONE email.

I did just realize that running a screen at 1280x1024x32 probably
consumes a bit of memory too; I'm dropping that down to 1024x768x8 to
see how that helps.

John

[9fans] file ownership on /srv

[Benjamin Huntsman]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

I have a CPU/Auth server set up.  I'd like to be able to add users remotely (via drawterm), rather than at the system's console.  However, normally, I can't attach to /srv/fscons, and as I found, can't start another fscons and open the filesystem under it.

/srv/fscons gets created at startup, by bootes:

cpu% ls -l /srv/fscons
--rw------- s 0 bootes bootes 0 Aug  6 12:09 /srv/fscons
cpu% 

Since I'm not logged in as bootes, and am not a member of the bootes group, I can't use con to connect to /srv/fscons, and therefore, can't add a user.

I read in chgrp(1) that you can't change file group membership when the fileserver is not in the bootstrap state.  How then can I get the /srv/fscons to belong to the 'sys' or 'adm' groups?  Or is the generally accepted solution to add my account to the bootes group, then chmod g+rw /srv/fscons  (from the console)?  Would that even allow me to connect to the fscons from a drawterm session?

I understand the concept of no superuser and un-circumvent-able security, but someone's got to be able to do administrator-type things w/o taking a trip to the server room...

Thanks much in advance!!

-Ben

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2939 bytes --]

Re: [9fans] file ownership on /srv

[Lyndon Nerenberg]

> I have a CPU/Auth server set up.  I'd like to be able to add users
> remotely (via drawterm), rather than at the system's console.  However,
> normally, I can't attach to /srv/fscons, and as I found, can't start
> another fscons and open the filesystem under it.

When you drawterm, authenticate as 'bootes' instead of your usual id.

--lyndon

   Every cloud has a silver lining; you should have sold it, and bought titanium.

Re: [9fans] file ownership on /srv

[Benjamin Huntsman]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

>When you drawterm, authenticate as 'bootes' instead of your usual id.

Yes that works, but isn't that similar to logging in as root to a unix box over the wire?
If I were delegating "add user" abilities to another user, that'd mean I'd have to give them the password for bootes...

Is there no way to give a specific group the ability to connect to fscons non-locally w/o using the bootes account?

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2635 bytes --]

Re: [9fans] file ownership on /srv

[Charles Forsyth]

> I read in chgrp(1) that you can't change file group membership when the fileserver is not in the bootstrap state.

the following isn't directly relevant to your current problem, but:
the manual page is commenting on chgrp's being used to change
file ownership, not its group.  changing groups is subject to the rules
in wstat(5), provided the file server supports it.  unfortunately, kernel
drivers such as #s don't support groups (in general).
lyndon@orthanc.ca's suggestion should work, though
(instead of drawterm, i usually just use telnet as bootes to a file/cpu/auth server for admin work.)

although i haven't needed it here, consolefs(4) might be useful too (and it implements groups itself)

Re: [9fans] file ownership on /srv

[Lyndon Nerenberg]

> Yes that works, but isn't that similar to logging in as root to a unix
> box over the wire? If I were delegating "add user" abilities to another
> user, that'd mean I'd have to give them the password for bootes...

Yes. Anyone who has access to /srv/fscons owns the file server.

The first alternative that comes to mind is to write a server that runs as
the file server host owner and accepts user creation requests. Make it
require authentication and give it a list of authorized users and you're
good to go. (Well, you get the idea.)

--lyndon

   Per dollar, the cray is cheaper to maintain than the comets.  -pjw

Re: [9fans] file ownership on /srv

[Benjamin Huntsman]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

>(instead of drawterm, i usually just use telnet as bootes to a file/cpu/auth server for admin work.)

Isn't that one of those proverbially bad admin practices?  :)  I know I'm guilty of it too, but I'm trying to cure myself of the habit.

I did just find that if on the console I do chmod ugo+rw /srv/fscons, I can open it under my username via drawterm, though just chmod ug+rw /srv/fscons isn't good enough.  Also, adding my username to bootes didn't seem to have an effect.

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2559 bytes --]

Re: [9fans] file ownership on /srv

[Benjamin Huntsman]

[-- Attachment #1: Type: text/plain, Size: 358 bytes --]

>The first alternative that comes to mind is to write a server that runs as 
>the file server host owner and accepts user creation requests. 

Actually, that's exactly the sort of thing I was working toward.  I was just hoping it could be done entirely via scripting, without having to put together any C.

Looks like not, eh!?

Thanks much!

-Ben

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2719 bytes --]

Re: [9fans] file ownership on /srv

[erik quanstrom]

> I did just find that if on the console I do chmod ugo+rw /srv/fscons, I can open it under my username via drawterm, though just chmod ug+rw /srv/fscons isn't good enough.  Also, adding my username to bootes didn't seem to have an effect.

unlike unix, groups only exist on the fileserver.  neither the
auth server nor cpu servers are in on this joke.

- erik

Re: [9fans] file ownership on /srv

[Russ Cox]

> Since I'm not logged in as bootes, and am not a member of the
> bootes group, I can't use con to connect to /srv/fscons, and
> therefore, can't add a user.

That's correct.

You want to change the policy, so that you are allowed
to act as bootes occasionally.  I see three reasonable ways
to do that.  The first is to put bootes's key in your factotum,
after your own.  Then when you want to connect to the
cpu server you can cpu -k 'user=bootes', do what you
need to do, and exit.

The second is to make a console for each user who can
run file server commands.  You can issue additional
srv commands in the file server config to create
/srv/fscons.bhuntsman, etc., and then each user can
connect to the one with the appropriate permissions.

The third is to use consolefs, as Charles suggested,
to moderate access to /srv/fscons.  This has many
benefits over the previous two ideas: the set of console
users is defined in one easy place (the consolefs config),
consolefs will multiplex output to multiple connections
(unlike /srv/fscons, which is just a pipe and thus doesn't
work so well with multiple readers), you can log the
console output easily, and you can see what commands
others are executing.

The cpu or extra console solutions are fine if only one
person (you) ever connects to the console.  Once there
is more than one person involved, consolefs is usually
better.  I use consolefs (with serial lines) for my own
Plan 9 machines even when it's just me.

One could imagine more complicated solutions, like
writing servers that let certain users do certain restricted
things, like create a new user but not execute other
file server commands.  It sounds like that's more complex
than you actually need.

All of these solutions assume that your normal user id
should be allowed to connect to the file server console
without additional authentication.  You could also create
a second user id (e.g., bhuntsman-sys) and require
explicitly loading that user's credentials before connecting,
if you were worried about accidental use.

Russ

Re: [9fans] file ownership on /srv

[Lyndon Nerenberg]

> The third is to use consolefs, as Charles suggested,

The true enjoyment of this OS is in discovering the blatantly simple
solutions to what turn out to be blatantly simple problems ;-)

I had completely forgotten about consolefs. Serial consoles still rule
in a certain realm, but who says they cannot be updated ;-)

--lyndon

   They were easy to tell apart: the good Kirk was played by William
   Shatner and the evil one by Gavin McLeod.

Re: [9fans] file ownership on /srv

[Russ Cox]

> The true enjoyment of this OS is in discovering the blatantly simple
> solutions to what turn out to be blatantly simple problems ;-)
>
> I had completely forgotten about consolefs. Serial consoles still rule
> in a certain realm, but who says they cannot be updated ;-)

Just in case it isn't clear, you don't need a serial console
to use consolefs.  You can tell consolefs to open /srv/fscons
directly instead of a serial line.

Russ

Re: [9fans] file ownership on /srv

[Benjamin Huntsman]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

>The third is to use consolefs, as Charles suggested,
>to moderate access to /srv/fscons.  This has many
>benefits over the previous two ideas: the set of console
>users is defined in one easy place (the consolefs config),
>consolefs will multiplex output to multiple connections
>(unlike /srv/fscons, which is just a pipe and thus doesn't
>work so well with multiple readers), you can log the
>console output easily, and you can see what commands
>others are executing.

Now that's the ticket!  consolefs it is!

Thanks all for the responses!

-Ben

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2563 bytes --]