Running 7.1.2.0 with two AIX servers, Object & Library. Library server has arscacheSL that we need to reduce.
We ran arsmaint command on object server with the following options:
> arsmaint -c -d -u admin -p ----- -n 90 -x 92
This produced the following:
Object Server
pkda0190-/arsacif1> df -k | grep arscache
/dev/cache1lv 102465536 9198772 92% 443153 18% /arscache1
/dev/cache2lv 102465536 9985352 91% 71318 4% /arscache2
/dev/cache3lv 104857600 10202036 91% 68942 3% /arscache3
/dev/cache4lv 102465536 10005884 91% 64991 3% /arscache4
/dev/cache5lv 102465536 9942508 91% 63968 3% /arscache5
/dev/cache6lv 102465536 10017804 91% 64098 3% /arscache6
/dev/cache7lv 102465536 10012332 91% 63299 3% /arscache7
Library Server - arscache size is unchanged
pkda0193-/reprint> df -k | grep arscache
/dev/sysloglv 1769472 86644 96% 15638 37% /arscacheSL
IBM isn't helping us since we are beyond end of service date
We need to know how to get the system cache reduced? Will running arsmaint on the library server reduce the arscacheSL? Or is there another parameter we need to specify on the command (like -g System Log)
I am not very sure on this one but here's what you may try.
Lower the upper threshold and the lower threshold values to say 10 and 60 and try.
Experinting with these values may free up the cache.
I found this article which may be useful for you. This one also suggests to run arsmain with a lower 'high threshold value'.
Well, the advice of Pankaj is good.
I have 2 other advices to give you:
1. Increase disk space (Ok, ok, ok... obvious... but still valid!!)
2. use the time option of arsmaint.
-> arsmaint -I ARCHIVE -u admin -p password -cvs -t <internal CMOD Date - Default Today>
Example, today we are the 21.04.2011 -> Internal CMOD Date : 15086
The today date was found like that
$ /opt/ondemand/bin/arsdate 04/21/11
04/21/11 -> 15086
Let say we go 1 month in the future : 21.05.2011 -> 15116
So the arsmaint command will be:
arsmaint -I ARCHIVE -u admin -p password -cvs -t 15116
The drawback of the method.... you loose 1 month of cache, but your immediate problem of disk space is gone.
I needed to do that with a customer, because he couldn't afford new disk space, and changing the threshold didn't help...
Cheers,
Alessandro
Won't the space parms 10 and 60 run for hours - this is a business critical application we can't take the system down more than 4 hours overnight.
Where is the article you referenced?
How do we increase the space of the arscacheSL w/o taking down the system? Is this a DBA function?
OOPS!!
Here it is.
https://www-304.ibm.com/jct01003c/support/docview.wss?rs=3247&uid=swg21421795&context=SSCVQSN&cs=utf-8&lang=en&loc=en_US
About your other question, I don't have any experience on that. Alessandro/JD would definitely have something for you.
Thanks. We're reviewing the article.
Theresa
Hello Theresa,
All I can say is that you can without any problems run ARSMAINT for the cache during production time... I've done countless times... But only for the cache of course!
But again, it depends on your internal processes, on how and when you want to do this.
Cheers,
Alessandro
Unless arscacheSL is the FIRST cache filesystem in your ars.cache file, remove it. It'll stop growing, and start shrinking on itself over time without intervention.
If it *is* the first cache filesystem, you'll need to expand it -- you're stuck with it until you migrate to new filesystems, or move to new hardware.
-JD.
It's ok to change the min & max percentages to 0 in the arsmaint -c command. It'll just expire the eligible data. Note that this is based on the assumption that you don't have to keep any of the data in cache file systems that's ready for expiration.
Filesystem expansion is something that your AIX admin can do with the help of storage team. It should be an online activity based on the AIX version you are using.
Regards,
SV