I think you need more LRU's for 400K buffers 'cause you could have too many dirty buffers to flush when you hit 5% dirty (depends on how fast your hardware is) , maybe change LRU_MAX_DIRTY to 1 and LRU_MIN_DIRTY to 0 if you don't want to reduce total # of buffers, and monitor the # of dirty buffers with onstat -R.
400K buffers / 7 LRU's = 50K buffers per LRU
flushing at 5% dirty of each LRU would be 2500 buffers x 7 LRU's which means you could potentially have 17500 buffers to flush at 5% dirty .... unless you've got incredible hardware that's too much.
I have 250K buffers, 127 LRU's, LRU_MAX_DIRTY = 1 & LRU_MIN_DIRTY = 0 which means I start flushing buffers per LRU when I hit 19 dirty buffers & the max # of dirty buffers I could ever have is about 2400 ... very manageable.
I do almost entirely LRU writes with this set-up & chunk writes occur at checkpoints.
Also possible PHYSFILE might be too big; it'll automatically flush when 75% full
so I'd keep this parameter smaller (20K works for me) but you have to experiment ... every site is different.
In a transaction heavy system, I think you'd want to maximize LRU writes so what do you see (top of output) when executing onstat -F?
I'm far from a guru, so here's some useful reading that will help you get going in the right direction:
Like I said, I'm not a guru. 35MB is manageable if you're thinking of copying a 35mb file from one VG to another .... or from one server to another. Flushing 35MB of dirty buffers is another matter.
The physical log will flush when 75% full; your phy log is 80000K which means a phy log flush of 75% is flushing 60MB which is also a huge writing task so perhaps your phy log should be smaller.
As always, the efficiency of your hardware & your disk setup (RAID, JBOD, etc) comes into play when addressing performance issues as does using raw space (more efficient) rather than cooked space.
I think you need to bump-up the # of LRU's & the number of CLEANERS, most people use approx. the same value for both of these parameters.
LRUS are limited to 128 so I have LRUS set to 127 & CLEANERS set to 128 so a CLEANER thread is always available when a LRU hits the 1% dirty mark.
Just changing LRU_MIN_DIRTY & LRU_MAX_DIRTY from 5% and 2% to new settings of 1% & 0% would increase your LRU writes & reduce checkpoint times because the maximum number of buffers that can be dirty at checkpoint time will be reduced 'cause you're doing a lot of LRU writes.
I keep my checkpoints manageable by doing mostly LRU writes rather than CHUNK writes which, I think, are triggered by CHECKPOINT interval of 4 hours. At a checkpoint, I'm usually writing about 1100 - 1300 dirty buffers and rarely do I see a checkpoint above 2 seconds.
Between LRU writes (frequent) and CHECKPOINTs (every 4 hours) I let the physical log take care of dirty buffers by flushing dirty buffers when it hits 75% full. You want your physical log big enough to handle your average transaction volume but you don't want it to be bigger than necessary.
Lots of good reading in the links I posted but there's no standard "best way" to setup IDS, only guide lines & some "best practice" suggestions.