Re: OnConfig parameters tuning

Laverio wrote: > Hi guys, I'm trying to speed up an IDS 9.30 on a Sun 7.5 system w/ > 2Gb ram and 4 processors that seems very slow on a large sequential > write (I suppose that the problem resides in the dbspaces on > filesystem...). Any suggestion? The following is my standard advice, what I consider a starting point. 1) get the chunks out of filesystem and into raw spaces! I understand that Solaris offers a filesystem switch which makes it unbuffered, and therefore nearly as efficient (give or take a few structural disk reads) as raw spaces. At the very least, get this option switched on for the filesystem. This still won't let you reap the benefits of KAIO which only works with raw spaces (unless I don't know enough about Solaris) > SERVERNUM 0 # Unique id corresponding to a OnLineinstance The files always say zero. One day some dummy might start a new engine, and then they'll smash each other. Change this number the next time you bounce the engine. It's a long-shot piece of paranoia that might save you one day. > RESIDENT 0Set RESIDENT to -1 because you have so much memory, you want to GUARANTEE that nothing ever pushes it out to swap space. I understand that Solaris will dynamically steal pages for lots of file buffering, and that's most likely going to happen since you are using filesystems to store chunks. Take control of the system and mandate the use of resident engine memory. > NUMCPUVPS 4 # Number of user (cpu) vps > NOAGE 0 # Process aging > AFF_SPROC 0 # Affinity start processor > AFF_NPROCS 0 # Affinity number of processors If it's a 4-cpu machine, set all of these to (in order) 4,1,2,3 or 4,1,1,3. The 3rd parameter changes depending on how Solaris numbers the CPU's. You should leave the first CPU for the O/S, hardware and user processes, and let IDS take over the others. If you find that the user processes are not getting enough (unlikely if it's only 4GL programs or similar) then reduce NUMCPUVPS and AFF_NPROCS to 2. See also below for advice on NETTYPE > BUFFERS 262144 # Maximum number of shared buffers That's close enough to 1/2 a gig. You're probably happy with that. > NUMAIOVPS # Number of IO vps There's a formula for the default here. I don't know it. I ain't going to look in the manual :-() Set this to N * 1.5, where N = number of chunks you have in the dbspaces. It's a start. > CLEANERS 1 # Number of buffer cleaner processes No way enough. One per chunk. Helps during checkpoints. I don't know how many disks and chunks you have (please reply) but then again, using files in filesystems sort-of interferes with my usual advice on this. Did I suggest you use raw spaces? > SHMVIRTSIZE 8000 > SHMADD 32768 This is NOTHING! the output of onstat -g seg probably has 30 lines... Look at the output of onstat -g seg, count up all the segments marked as class V, then allocate that number * 32768 as the SHMVIRTSIZE. Add another 20% for good luck. Make SHMADD about 25% of that number. > LRUS 8 # Number of LRU queues Match this to the number of cleaners you choose. When not doing checkpoints, the cleaners will sometimes flush pages from your LRU queues. Give them one each so they don't get jealous. > LRU_MAX_DIRTY 60 > LRU_MIN_DIRTY 50 If your checkpoints are horribly long, reduce these factors. Look in the message file for checkpoint times, and especially look for long checkpoints. If they are more than 2 or 3 seconds sometimes, then you need to drastically reduce these percentages to limit the number of dirty pages. If your worst checkpoint is 30 seconds (for example) and you desire 3 second checkpoints, then the factor is 30/3 = 10. Reduce your LRU_*_DIRTY by a factor of 10 each and see what happens. Monitor your checkpoint durations. That's a start. But get your data into raw spaces and start using KAIO.

Andrew Hamm wrote: > > See also below for advice on NETTYPE hmmm - there wasn't any 'cos you didn't post your NETTYPE parameters :-) make sure your nettypes look something like: NETTYPE soctcp,1,100,NET NETTYPE ipcshm,3,50,CPU NOTE: soctcp might be tlitcp on Solaris. Always run soctcp/tlitcp on NET processes. Allow each one to handle a maximum of maybe 200 connections, therefore the first number starts to rise once you exceed the need for 100-200 tcp connectors. and always run ipcshm on CPU processes. Allow them to handle upto maybe 150-200 connections each. Make the first number equal to the NUMCPUVPS parameter - this improves load balance. If you must make the 2nd number greater than maybe 200 (check the manual for advice on load capacity, I forget the details) then it's probably a hint that you might need another CPU or two.