Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

memory problem ?

Status
Not open for further replies.

shoux

Technical User
Nov 9, 2000
83
0
0
MY

Hi all ?

OS - AIX 5.2 on regatta/p670

Currently, I'm having system performance problem. the problem is when the process log off from application or database it taken loger time. I have 400 users logged and has 8G of RAM. is't enough for them ? from command #svmon -G the memory free column it shown 42462.
is there any way to overcome this problem.
sorry my english is not good.

Thanks



shoux
 
Fishbed,

Thanks you for the response.here is the ouput

#vmstat 1

kthr memory page faults cpu
----- ----------- ------------------------ ------------ -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
1 3 536540 248448 0 0 0 286 653 0 1301 39607 1083 4 6 78 11
0 1 536544 248398 0 0 0 0 0 0 1185 15428 935 1 1 93 4
0 0 537113 247802 0 0 0 0 0 0 1212 6921 904 1 1 96 1
0 0 537208 247683 0 0 0 0 0 0 1225 15839 956 1 2 95 1
0 1 537472 247381 0 0 0 0 0 0 1225 23818 999 2 4 90 5
0 0 537055 247787 0 0 0 0 0 0 1266 15367 947 2 1 95 2
0 0 537105 247737 0 0 0 0 0 0 1158 11739 856 1 1 96 2
0 0 537106 247736 0 0 0 0 0 0 1155 8569 836 1 1 98 0
1 0 537106 247730 0 0 0 0 0 0 1815 18447 860 2 1 90 7
0 2 537067 247752 0 0 0 0 0 0 1491 26442 1203 1 2 88 9
2 1 538146 246647 0 0 0 0 0 0 1506 76515 995 5 5 83 7
1 0 538039 246750 0 0 0 0 0 0 1333 112243 915 6 6 82 6
0 3 537563 247197 0 0 0 0 0 0 1709 46479 921 3 4 79 15

#topas
Topas Monitor for host: B_SERVER EVENTS/QUEUES FILE/TTY
Sat Sep 25 11:47:11 2004 Interval: 2 Cswitch 834 Readch 1154.4K
Syscall 5823 Writech 48449
Kernel 0.6 | | Reads 683 Rawin 0
User 0.3 | | Writes 1199 Ttyout 0
Wait 0.3 | | Forks 2 Igets 0
Idle 98.7 |############################| Execs 2 Namei 508
Runqueue 0.0 Dirblk 0
Network KBPS I-Pack O-Pack KB-In KB-Out Waitqueue 0.0
en0 19.0 148 118 6.0 32.0
lo0 0.0 0 0 0.0 0.0 PAGING MEMORY
Faults 239 Real,MB 8191
Disk Busy% KBPS TPS KB-Read KB-Writ Steals 0 % Comp 22.7
hdisk2 7.0 172.0 21 32.0 312.0 PgspIn 0 % Noncomp 66.4
hdisk0 0.0 0.0 0 0.0 0.0 PgspOut 0 % Client 59.0
hdisk1 0.0 0.0 0 0.0 0.0 PageIn 4
dac0 0.0 0.0 0 0.0 0.0 PageOut 38 PAGING SPACE
Sios 4 Size,MB 512
Name PID CPU% PgSp Owner % Used 60.7

#svmon -G

size inuse free pin virtual
memory 2097152 1851072 246080 210018 536095
pg space 131072 78993

work pers clnt lpage
pin 210018 0 0 0
in use 466710 155812 1228550 0
>


shoux
 
Moshiah , why do you think it is CPU bound?

Baanman
 
What database, and what application?

Did one of the "slow logouts" take place during the monitoring period you posted? If so, the problem probably isn't AIX or the hardware, but rather the app or database.

If not, can run vmstat during a slow logout and post the results?

"lsps -a" output might be useful, as well.



Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L

 

Thanks for the reply.

Currently the system condition is bad. The system performance is very slow. The following is the snap shoot



#vmstat 1
1 3 502307 660 0 0 0 242 552 0 1267 15724 974 2 2 83 12
1 1 502776 347 0 0 0 175 186 0 1769 41277 630 3 4 71 22
0 4 502693 420 0 0 0 0 0 0 1793 34939 539 2 4 64 30
0 3 502588 515 0 0 0 0 0 0 1786 31122 514 2 4 52 42
0 0 502589 462 0 0 0 0 0 0 1200 34452 572 2 2 82 14
1 1 502888 155 0 0 0 0 0 0 1036 11595 502 1 1 98 0
0 2 503055 131 0 0 0 147 156 0 1745 27183 771 2 2 80 16
0 4 503186 152 0 0 0 360 390 0 1838 63514 1558 7 7 63 23
#lspv
hdisk0 003044db7bfc092a rootvg active
hdisk1 003044db40e5920a rootvg active
hdisk2 003044db411efccd datavg active

#lsps -a
Page Space Physical Volume Volume Group Size %Used Active Auto Type
hd6 hdisk0 rootvg 512MB 8 yes yes lv

#svmon -G
size inuse free pin virtual
memory 2097152 2096213 939 187525 503484
pg space 131072 9338

work pers clnt lpage
pin 187525 0 0 0
in use 495746 99285 1501182 0
>
# svmon -F
Processing.. 100%
percentage of memory used: 16.76%





shoux
 
That doesn't really look like a system that's having any performance problems. In the worst case vmstat line, you're only actually using 14% of the cpu capacity for real work, and your i/o wait cycles never get to even half of idle cycles. Memory's not a problem, as paging space use is light, page stealing is non-constant (the 0 values for fr), and your scan/free ratio (sr/fr) is very low (it typically needs to be over four on a constant basis before you should even consider that it might be a problem.)

Could this be a network problem? By "system performance is slow", are you referring to response time to network clients (ssh, telnet, web, etc...) or execution time of non-interactive jobs?

Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L

 

Hi all !

Sorry for the delay in responding and fyi the problem still persist.

RodKnowlton
According to network administrator there was not a network problem. we are facing frequent problem on this matter. when the problem occured the errpt shown as following:- Thanks

#errpt -a
LABEL: CORE_DUMP_FAILED
IDENTIFIER: 45C7A35B

Date/Time: Thu Mar 3 16:31:55 WAUS
Sequence Number: 57839
Machine Id: 003044DB4C00
Node Id: AIB_SERVER
Class: S
Type: PERM
Resource Name: SYSPROC

Description
SOFTWARE PROGRAM ABNORMALLY TERMINATED

Probable Causes
INTERNAL SOFTWARE ERROR
SYSTEM RUNNING OUT OF PAGING SPACE

User Causes
USER GENERATED SIGNAL

Failure Causes
Failure Causes
CORE DUMP FAILED - SEE A REASON CODE BELOW

Recommended Actions
DEFINE ADDITIONAL PAGING SPACE
RERUN THE APPLICATION PROGRAM
IF PROBLEM PERSISTS THEN DO THE FOLLOWING
CONTACT APPROPRIATE SERVICE REPRESENTATIVE

Detail Data
SIGNAL NUMBER
11
USER'S PROCESS ID:
229378
REASON CODE
13
USER ID
928
PROCESSOR ID
3
CORE FILE NAME
/app/AIB_0305/core
PROGRAM NAME
uvsh

#errpt
IDENTIFIER TIMESTAMP T C RESOURCE_NAME DE SCRIPTION
45C7A35B 0303163105 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED
45C7A35B 0303163105 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED
45C7A35B 0303163105 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED
45C7A35B 0303163105 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED
45C7A35B 0303163105 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED
45C7A35B 0303163005 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED
45C7A35B 0303163005 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED
45C7A35B 0303162905 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED

the following some info will help u to trace the problem:-
#lsps -a
Page Space Physical Volume Volume Group Size %Used Active Auto Type
hd6 hdisk0 rootvg 2560MB 4 yes yes lv

#lsps -s
Total Paging Space Percent Used
2560MB 4%




 
shoux, sorry to hear you're still experiencing problems, but remember that the phrase "According to network administrator there was not a network problem. " is a mantra network admins are taught at College as part of their course!
 
PROGRAM NAME
uvsh

What is the program "uvsh"? Are you running UniVerse database?
 

Thank for the prompt reply

KenCunningham
I don't understand what are you traying to say.please be specifiy and precise.

KissArmy,
that right I'm using universe database (U2) Rel 10.0.14, I would grateful if you could suply the info.

Thank you


shoux
 
shoux. I wasn't trying to say anything specific about your problem (since I don't know the answer), merely making an observation that to network admins all problems are other peoples until categorically proved otherwise. Is that specific and precise enough for you ;-) ?
 

shoux: KenCunningham is saying that all network administrators (and I have to agree with this) will tell you without checking and/or knowing, that there is no network problem.
You have to be firm with them in asking for proof or do it yourseelf.

Cheers
 
shoux,

Here is what I would look at:
If you have any large files, or files that everyone accesses, I would:
run >LIST FILENAME F1 DET.SUP (supplying the filename)
This checks for file corruption. If everytrhing is ok, it just returns a record count.

>FILE.STAT FILENAME (this can take a while for very large files, and consume resources) It will tell you how "full" the file is. If a majority of record groups are towards the 200% range, that can have a huge effect on your performance.

You can also run >ACCOUNT.FILE.STAT to check every file in an account.

Also run HASH.HELP and HASH.AID to determine how the file should be sized. Then follow instructions for RESIZE command to resize them.

Ok...try those and let me know what you find out. Have you seen any file corruption ("blink" errors)? With core dumps, I would think people would complain about getting booted out of the app.

BTW....who is your UniVerse suport through?
 
universe pins memeory for each login it was 8mb at one time
 
Hi all

thank you for the response

kissarmy - yes I will execute the task this weekeed since the RESIZE command can be used when the file is not being access by user


 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top