NICEing login

[Terry Kummell]

We have a K570 running HP-UX 10.20 that is experiencing intermittant performance issues.

BTW, the machine is maxed out in terms of memory size for a 10.20 system.

We've noticed that we have two spikes where the system really gets hammered. They correlate to the times when folks are coming to work in the morning and returning form lunch. This is the time when we get a lot of logon activity.

My question to this forum is: Can you nice the logon process? (Or otherwise reduce its' importance to the system scheduler).

Regards,

Terry

[Wodisch_1]

Hi Terry,

so you have 3.75GB of RAM, right?
Well, then I guess your UN*X buffer cache is much to high, as the default of the HP-UX kernel is eat up to 50% of it (read: waste it). Since HP-UX 10.20 and 11.00 can only make good use of about up to 300-400MB, reduce the kernel paramater "dbc_max_pct" to 10 (which would restrict your buffer cache to only up to 375MB).

Just my $0.02,
Wodisch

[Charles McCary]

Terry,

good advice above about the buffer cache "unless" you run a lot of batch processing on the box. If you reduce the bufer cache it will effect batch processing.

C

[Terry Kummell]

Hi Wodisch,

The kernel parameter change is something we did quite awhile back (perhaps 2 years ago).

My recollection is that you are right, that it did free up a considerable amount of memory.

Last year, an expert from HP helped us tune the system. So I don't think any of the simple answers are going to apply to this issue.

As I said in my original post, we've noticed a correlation between the times of day when people are logging on. What we would like to do is make their logon process a lower priority as compared to the Informix Database engine.

Regards,

Terry

[A. Clay Stephenson]

I have not tried this on HP-UX but I can think of a scheme that almost certainly will work. On some older UNIX boxes, a common problem was that ulimit was typically 2MB and could only be increased by root. My solution was to rename /usr/bin/login to /usr/bin/login2. I wrote a very small bit of C which 1) increased ulimit and 2) exec'ed /usr/bin/login2. This took advantage of the fact that login was called while the effective UID was 0 so that ulimit could be increased and then exec'ed itself into the 'real' login.

A similar approach should work for you. Rename /usr/bin/login and then create a replacement /usr/bin/login that does a nice() system call and then an exec() to the real login command. Because the nice value is retained across exec's, you should be in business.

Make sure that you are logged in as root in more than one session before deploying this guy. You can then get yourself out of trouble as fast as you got yourself in.

[Bill Hassell]

I would find it difficult to understand why a login causes any measureable load at all. Login is totally interactive and consumes insiginificant CPU and disk.

On the other hand, what does bdf look like? When anyone logs in, disk quotas are chaked automatically which means a visit to every disk to search for the quotas file. And if you have NFS mounts, it's even slower.

Are you using disk quotas? (if you don't know then you're probably not). So you can remove the quotas fileset. Or you can add noquota to each of the mounted filesystems in fstab.

Take a good look at what goes on inside /etc/profile and .profile for the users. Does it take more than a couple of seconds to login and get a prompt? Trim out the big stuff from profiles. Some vendors supply some really bad setup scripts that they (silently) tag onto /etc/profile.

So, it has nothing to do with login as a command. Once you answer the password question it disappears. Trim the junk out of the profile steps.

[doug hosking]

Terry, are you running trusted mode? If so,
how many accounts are on your system ? On a system with lots of accounts, you will want to be sure you are current on libsec patches. There were some rather ugly performance
problems in 10.20 and earlier releases that
could cause the problem you describe.
PHCO_11214 is the one to look for.
There were some additional performance improvements in this area but they were never patched in 10.20. Keeping dbc_max_pct low would indirectly help with these. (I can't say whether that's appropriate for your particular system.)

[John Bolene]

I agree with Bill.

Login takes very little resources. I would check to see what else is going on after they login.

Are they starting database processes? Are they copying stuff around? Are they doing NFS accesses? How is your swap, maybe it is the slow guy in starting up sessions?

Maybe you just need them to not logoff, just lock the terminal.