Disk performance using NIKE add-on cache

[Anthony deRito]

Hello all. I would like to ask if anyone has had any experience and performance information with the add-on cache for the Model 10/20 NIKE disk arrays. I have recently maxed out the cache in both SPs of each of my NIKEs and I am disappointed at the performance improvement. I am seeing the disk perform more productively but from a user perspective, the response time is not what I thought it would be. While I am seeing more performance gain with raw I/O transfers, I am not with filesystem I/O. Any experience would be greatly appreciated.

[Andy Monks]

If your seeing performance benifits from raw lvol access, but not from filesystem access, it probably means, that your buffer cache isn't optimally configured for your system. Now, depending on what application your using, determines how you configure your buffer cache.

If your using Oracle, it should have a large SGA, therefore, you don't need a large buffer cache. If your using something like uniVerse, then a larger buffercache is better. In either case, I wouldn't recommend a buffer cache over 1GB. Typically I'd say 10-20% of physical memory, with the more memory, the lower the percentage.

You can change the buffer cache percentage with the 2 kernel paramters dbc_min_pct and dbc_max_pct

Andy

[CHRIS_ANORUO]

If you are using fastwide/scsi cards, change them and use HSC expansion I/O slots on you system. My guys in production are off my back because of the tremendious performance increase.

[Emmanuel Eyer]

Silly question: did you increase the cache allocation figures on the Nike? As far as I remember, extra cache memory is not allocated to either read or write cache :-(

Go to GridManager (get a VT-100 to the serial port at the back of your Nike, either SP-A or SP-B). From the main menu, choose Change Configuration (5), Change SP Parameters, Change Memory Parameters (might be slightly different, I don't remember exactly). From here you can change:
- Amount of system memory for SP-A
- Amount of system memory for SP-B
- Amount of read cache for SP-A
- Amount of read cache for SP-B
- Amount of write cache (mirrored)
- Amount of RAID-3 buffers
- Unallocated memory.

System memory for both SPs should be 8 MB. Set up Read/Write cache using ratios as you feel for your application (to make it balanced, assuming you are balancing the IOs thru the 2 SPs, say 1/3rd for Read, 2/3rd for Write). Set RAID-3 buffers to 0 (should be the case...). And be sure to have no unallocated memory!

Bad news for your next week-end: changing memory configuration requires :
- disabling cache
- rebooting both SPs (hence power cycle the box, it's the simplest thing to do)

Hope it helps, Emmanuel

[Anthony deRito]

Emmanuel, thanks for the input. I am familiar with Grid Manager and have the cache installed and configured OK. What I am looking for is someone who actually has used sar, vmstat, glance...etc to measure system performance and tune the system with respect to I/O. I cannot change/refresh hardware at this time. The stats I am looking at are from glance and sar -d. I am measuring the throughput of the SP using the r+w/sec, blks/s, avwait, avserv and avque params. The throughput increases (more I/O requests processed per sec) but the user response time stays the same. The main question is: if I can get the throughput of the disk to increase, how can I get the CPU/buffer cache to feed more data and make more requests to the disk??? I do not know where the bottleneck is. The CPU IS NOT TAPPED OUT. I have 100% read and writes to/from buffer cache and have fs_sync turned on. I find it very frustrating to believe that I can get a mechanical device to work harder but cannot get the work to it fast enough!!!

[Bill McNAMARA_1]

Have a look at my posting here:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0x82b6d06ed8c8d4118fef0090279cd0f9,00.html

Later,
Bill