Kernel changes

[Vito Sarducci]

Our vendor wants us to change npty, maxssiz, and maxtsiz in our 11.0 OS. We found when we change parameters we get
Semaphore and shared memory failed? Are these parameters the ones we should be looking at or is this another attempt for the vendor to guess at the correct kernel parameters?

Please advise?

Vito

[Patrick Wallek]

"Are these parameters the ones we should be looking at or is this another attempt for the vendor to guess at the correct kernel parameters? "

Well, that depends. What kind of problem are you trying to solve by changing these kernel parameters? are you having performance problems? shared memory problems? not enough tty's for everyone to login?

What application are you running? What did you change the kernel parameters to?

We really need a WHOLE LOT more information befre we can even attempt to make an educated guess about what is going on.

Just for information purposes here is a web site with all of the HP-UX configurable kernel parameters:
http://docs.hp.com/hpux/onlinedocs/os/KCparams.OverviewAll.html

[S.K. Chan]

Patrick's point is right on. I would think the vendor (if they understand their application very well plus they understand hpux architecture) should know what are the desirable kernel parameter value for their application. Would you mind sharing more information (what application ? , etc )

[A. Clay Stephenson]

Hi:

There is no way to answer this with the amount of data supplied. This is what probably happened. Your application was probably hitting memory fences and connection limits; when these were resolved, your application simply hit the next set of limits which in this case happened to be semaphores.

This is very typical in geting an application
up and running and is a normal part of the growing process. Remember, your vendor doesn't know what else is on your system or all the various hardware configurations. This is why SA's get paid the big bucks - so do your part of the job.

Regards, Clay

[Vito Sarducci]

The application is called Cloverleaf and it is a messaging transport application for hospital environments. It sends HL7 data between servers applications. It is a heavy Java application.

It uses all our physical memory on the server. I have over 4GB on this server running 11.0

Were trying to configure this server to handle this application without it puking all the time.

I hope this helps. If not what else do you need, i can provide.

Vito

[Patrick Wallek]

It sounds like one thing you need to do is add more memory to this machine. 4GB is not that much memory anymore. From what you describe, you are short on memory. I would probably try to at least double the amount of memory you have to start with.

If the app is using all physical memory, definitely check whether or not you paging out. If you are paging out, you definitely need more memory.

[Vito Sarducci]

Page Faults are high, but i dont see page out as being high.

I only have 3.75GB physical on this server. Its a K570 running 11.0

[Vito Sarducci]

I have another question, would running 32bit vs 64bit have any issue with the amount of memory? I have been told that 32bit 11.0 does not use more then 3.75GB of memory no matter how you configure it?

Is this true?

Please advise?

Vito

[Roger Baptiste]

hi,

Since you mentioned semaphore and sharedmemory : Run
#ipcs -am
and add the 10 th column (SEGSZ) to see how much of shared memory is allocated.
Also look at NATTCH column for zero's.

#ipcs -as
and add NSEMS column to check the number of semaphores consumption.


run glance -> t (tables) to see general kernel parms usage.

HTH
raj

[A. Clay Stephenson]

Yes, your understanding is correct. If this is 32-bit 11.x OR your application is a 32-bit application then you can only address 3.75 GB (The .25GB remaining is for kernel I/O address mapping). If this is a 32-bit application running on 64-bit 11.x then you can enable memory windows so that each application can get its own 3.75GB address space but there are some restrictions especially in the use of shared memory.

Since you indicated that this is Java-based, the very first thing you should do is search the Patch Database for any Java-related patches. There have been a number of them that plug memory leaks and prevent Java from hogging the CPU.