Memory issues running BaanIV

[Terry Johnson_1]

Hi all,

We are currently running baanIV on a K580 6-way with 3.75 Gb of Ram. Is there anyone out who has run into the same kind of issues. Approxiately 150 users usually are logged into the application and this takes up 2.85 Gb. The following is what the swapinfo -ta give me:
Kb Kb Kb PCT START/ Kb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 524288 87992 436296 17% 0 - 1 /dev/vg00/lvol2
dev 524288 88700 435588 17% 0 - 1 /dev/vg00/lvol4
dev 524288 85112 439176 16% 0 - 1 /dev/vg00/lvol10
dev 524288 88588 435700 17% 0 - 1 /dev/vg00/lvol11
dev 524288 86884 437404 17% 0 - 1 /dev/vgdb09/lvol3
reserve - 2184164 -2184164
memory 2943144 1724580 1218564 59%
total 5564584 4346020 1218564 78% - 0 -


Is there any kernel parameters I need to look into? I will attach them.

Thanks in advance for the help.
Buzz

[Sanjay_6]

Hi Buzz,

Looks like okay to me. Your swap lv's are only 17% consumed and your memory consumption is 59%. This is not so bad. What is the problem ?.

thanks

[Terry Johnson_1]

Sanjay,

It seems this continues to grow (now at 25%). What percentage should is acceptable? I get applications people at times complaining there jobs are running longer then normal.

Buzz

[A. Clay Stephenson]

Hi:

Something does appear a bit strange. I just checked one of our BaanIV application servers. I have 165 Baan users logged in on a K-box with 2.5 GB and am not swapping at all. In fact, all of these users are using only about 500 MB. Since almost everyone is running bshell the same text segment is shared and each process only has a private bss and data segment. I suspect that you have a bunch of shared memory segments leftover from bad Baan shutdowns or some indescriminate kills. Maybe some kill -9's?

Do an ipcs -ma and have a look at shared memory.

[Terry Johnson_1]

Clay,

Do you also have the database running on the same server? I've attached the ipcs -ma.

Thanks, Buzz

[A. Clay Stephenson]

No, we run a separate Database server with multiple application servers. Notice the 16M segment with 0 attachs (or is this a test baan instance with no user logged in?). That is almost certainly a stale baan segment. It also appears that you have three oracle instances.
Given that, your memory usage does appear more reasonable. Do you actually have a problem?

Do a sar -w 30 5 and note the swpot/s (swapouts). If that number is greater than 0 you are swapping. I would also do a vmstat and look at the po (Page Outs) column.

[Terry Johnson_1]

We had baan running on a server by itself until about a month ago. A decision was made to run baan on the same server as the database. I was just worried about putting to much of a load on this machine. It wasn't swapping before putting baan over there. From time to time the vmstat does show page-outs. We just added 750 meg (3.0 gig to 3.75 gig) this weekend which I hope will help. The sar -w did not show any swapping at this time. I guess I'll just have to keep an eye on it.

Thanks, Buzz

[Bill Hassell]

Memory usage is not very important. 100% RAM usage is desirable as long as processes are not continuously competing for RAM. You can see this with vmstat, specifically the po (page out) rate. Single digit values are fine which means very little paging is being done. When po jumps to 2-3 digits for long periods of time, RAM is definitely too small.

RAM is not the first resource to check for system loading however. Instead, disk activity is usually the limiting factor. And really, there is no concern if the response time is appropriate. You mayu want to consider the importance of this server's processes and get a copy of Glance so performance can be easily monitored.

[Sridhar Bhaskarla]

Many experts advise that it is better to run at 100% but not to throttle the system. This is a very idle situation and doesn't practically happen. If a system is consuming 100% resources, then certainly it is going to create problems. So,my best bet would be to run at 80% and plan for resources in advance.

Particularly memory is cheap.Your swapinfo does show that there is swapping out.
Simple. Buy some memory and get rid of swapping.

See if there is any i/o due to swapouts. Keep an eye on %wio. This is where the CPU is virtually there but not available to the systems due to processes trying to get rid of I/Os.

sar-u 2 20


It could be that there are memory leaks. I don't believe most of the softwares in the world.

-Sri

[Terry Johnson_1]

Since we're running 10.20 on this machine we can not run anymore than 3.75 Gb of RAM. The next phase is to watch Disk I/O to see if this is causing problems.

Thanks for all responses.