« Less email, more... | Main | Alone and without... »

20041016 Saturday October 16, 2004

Zone count: 86 steps forward, one step back

Friday left me with a few minutes of hacking with the Ultra 10 zones machine. Luckily, Scott was in town. Scott had already configured the Sun StorEdge 6920 with a volume for me to use. cfgadm -al showed the fibre channel WWN.

Unfortunately, I can't seem to get to the device files created. Bummer. Ran out of time but I'll call this a small step backwards. A quick check shows a bug that might be the cause. I'll keep ya'll up to date. This is a good time to start from scratch. I think I will wait for the next build or two of Solaris 10, put my swap file on the 6920 and re-create the zones from scratch. This is way too much fun. Anyone want to guess how many zones I can get up on the Ultra 10 with a full gig of RAM (assuming I can get it) and a 6920 behind it? My goal: 500.

Any spare cycles I have over the next few weeks I will put towards my container demo (bug fixes) and JXTA.

(2004-10-16 14:19:55.0) Permalink Comments [6]

Comments:

You didnt forget to enable the controller and format the luns did ya ? :) cfgadm -c configure "controller" echo "label" >/tmp/label && for i in /dev/rdsk/cXtX*s2 ; do format -f /tmp/label

Posted by Rodrick Brown on October 16, 2004 at 07:04 PM PDT #

We got stuck enabling the controllers. Didn't even debug really. I was hot to get out the door and beat traffic on a Friday (Friday Traffic is brutal in L.A.). Thanks for dropping the note!

Posted by John Clingan on October 16, 2004 at 07:44 PM PDT #

How many zones now? I would ussually say the most limiting factor would be your virtual memory. Are you going to limit your swap space or just increase it as needed? Depending what you have the zone to do to verify it's alive, you're going to have a very high zone count. I would estimate the limiting factor will be the paging in and out of the 1GB of memory by the kernel will be what finally brings it to it's knees. At some point the processor won't be able to keep up. I'm very curious about what you'll be able to get out of it, but I'm guessing somewhere around 1400 zones (with as small a app as possible). But then I could be way too optimistic.

Posted by David on October 17, 2004 at 06:59 AM PDT #

I'd be very happy with 1400, but I don't think I'll make it that far. It will not be virtual memory (I have wwwaayyy over-allocated with 3GB so far). I am going to completely re-do the hard drive lay out and install a fresh OS (because of other non-zones related issues). You bring up a good point in that it might fall under its own weight of having to swap in-and-out specific zone processes (perhaps zched??). Dunno. That's part of what this rather useless but fun exercise is all about. I will increase swap until I either run out of RAM for the kernel itself or it swaps into oblivion (which is my guess as well). I hope I can get the extra 512MB of RAM.

Posted by John Clingan on October 17, 2004 at 07:14 AM PDT #

John, you are going to be running the Fair Share Scheduler, is that correct? It would be interesting I guess, to see what happens if you give different zones different amounts of shares, and see how that interacts with swapping. Does a zone with a very high share amount ever get its active pages swapped out, for instance?

Posted by PatrickG on October 17, 2004 at 08:15 PM PDT #

PatrickG, FSS? Yes. Regarding swapping and shares, my guess is that the high-share-process will have more of its pages in memory more often. Will it get its pages swapped out if another process with less shares needs to run? Yep. If other processes need to run and their shares are up for running, absolutely that one high-share process gets pages pushed to disk if need be. Shares != priority (although shares do affect priority).

Posted by John Clingan on October 18, 2004 at 06:30 AM PDT #

Post a Comment:

Comments are closed for this entry.