
<?phpxml version="1.0" encoding="utf-8"?>
<rss version="2.0" 
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:wfw="http://wellformedweb.org/CommentAPI/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
>
<channel>
<title>TheGridPlace - For all your Grid and DataGrid Information / Published</title>
<link>http://smetube.com/TheGridPlace</link>
<description>TheGridPlace - For all your Grid and DataGrid Information  votes</description>
<pubDate>Sat, 04 Feb 2012 08:00:15 CST</pubDate>
<language>en</language>
<item>
<title><![CDATA[Webinar: Guarantee your e-Commerce site’s uptime next Black Friday.
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Webinar-Guarantee-your-eCommerce-sites-uptime-next-Black-Friday</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Webinar-Guarantee-your-eCommerce-sites-uptime-next-Black-Friday</comments>
<pubDate>Sat, 04 Feb 2012 08:00:15 CST</pubDate>
<dc:creator></dc:creator>
<category>GigaSpaces</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Webinar-Guarantee-your-eCommerce-sites-uptime-next-Black-Friday</guid>
<description><![CDATA[Join us for a webinar on how to Dynamically Scale your E-Commerce Business. In&amp;#160;today&amp;#39;s fast-paced e-commerce industry, every minute of downtime translates to&amp;#160;money lost. &amp;#160; E-Commerce companies&amp;#160;just can&amp;#39;t afford any glitches&amp;#160;&amp;#8211; especially during the traffic-heavy holiday season. &amp;#160; Ron Anderson, &amp;#8230;  Continue reading  &amp;#8594;  <br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Analytics for Big Data – Venturing with the Twitter Use Case
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Analytics-Big-Data-Venturing-with-Twitter-Use-Case</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Analytics-Big-Data-Venturing-with-Twitter-Use-Case</comments>
<pubDate>Fri, 27 Jan 2012 08:00:10 CST</pubDate>
<dc:creator></dc:creator>
<category>GigaSpaces</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Analytics-Big-Data-Venturing-with-Twitter-Use-Case</guid>
<description><![CDATA[Performing analytics on Big Data is a hot topic these days. Many organizations realized that they can gain valuable insight from the data that flows through their systems, both in real time and in researching historical data. Imagine what Google, &amp;#8230;  Continue reading  &amp;#8594;     Continue reading  &amp;#8594;  <br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[GigaSpaces Cloudify &amp; VMware CloudFoundary the new PaaS Jailbreaker
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=GigaSpaces-Cloudify-VMware-CloudFoundary-new-PaaS-Jailbreaker</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=GigaSpaces-Cloudify-VMware-CloudFoundary-new-PaaS-Jailbreaker</comments>
<pubDate>Mon, 16 Jan 2012 08:00:03 CST</pubDate>
<dc:creator></dc:creator>
<category>GigaSpaces</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=GigaSpaces-Cloudify-VMware-CloudFoundary-new-PaaS-Jailbreaker</guid>
<description><![CDATA[I was reading Krishnan Subramanian's post, Two Events That &quot;Clouded&quot; Our Thinking In 2011. The thing that caught my attention was Krishnan's comments on why PaaS is a superior alternative to DevOps: The shift in the thinking about the enterprise...  Continue reading  &amp;#8594;  <br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Terabyte Elastic Cache clusters on Cisco UCS and Amazon EC2
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Terabyte-Elastic-Cache-clusters-on-Cisco-UCS-Amazon-EC2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Terabyte-Elastic-Cache-clusters-on-Cisco-UCS-Amazon-EC2</comments>
<pubDate>Thu, 05 Jan 2012 08:00:02 CST</pubDate>
<dc:creator></dc:creator>
<category>GigaSpaces</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Terabyte-Elastic-Cache-clusters-on-Cisco-UCS-Amazon-EC2</guid>
<description><![CDATA[Overview Last week I was working on a new opportunity. The prospect needs to store 1 Terabyte of data in memory to address scalability challenges and were interested in using GigaSpaces. I was tasked with creating a demonstration of this &amp;#8230;  Continue reading  &amp;#8594;  <br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[2012 Cloud, PaaS, NoSQL Predictions
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=2012-Cloud-PaaS-NoSQL-Predictions</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=2012-Cloud-PaaS-NoSQL-Predictions</comments>
<pubDate>Thu, 22 Dec 2011 08:00:03 CST</pubDate>
<dc:creator></dc:creator>
<category>GigaSpaces</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=2012-Cloud-PaaS-NoSQL-Predictions</guid>
<description><![CDATA[2011 is coming to its end and now is a good time to start planning for 2012. I thought that a good start would be too look at my 2011 predictions and if my previous (and first) attempt to predict...  Continue reading  &amp;#8594;  <br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Architecting Massively-Scalable Near-Real-Time Risk Analysis Solutions
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Architecting-MassivelyScalable-NearRealTime-Risk-Analysis-Solutions</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Architecting-MassivelyScalable-NearRealTime-Risk-Analysis-Solutions</comments>
<pubDate>Tue, 20 Dec 2011 08:00:05 CST</pubDate>
<dc:creator></dc:creator>
<category>GigaSpaces</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Architecting-MassivelyScalable-NearRealTime-Risk-Analysis-Solutions</guid>
<description><![CDATA[Recently I held a webinar around architecting solutions for scalable and near-real-time risk analysis solutions based on the experience gathered with our customers. In the webinar I also had the honor of hosting Mr. Larry Mitchel, a leading expert in the Financial &amp;#8230;  Continue reading  &amp;#8594;     Continue reading  &amp;#8594;  <br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Moving away from Mainframe to Commodity – How?
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Moving-away-from-Mainframe-to-Commodity-How</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Moving-away-from-Mainframe-to-Commodity-How</comments>
<pubDate>Thu, 15 Dec 2011 08:00:23 CST</pubDate>
<dc:creator></dc:creator>
<category>GigaSpaces</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Moving-away-from-Mainframe-to-Commodity-How</guid>
<description><![CDATA[Moving away from Mainframe to Commodity &amp;#8211; How? Mainframe (Z/OS) based systems running COBOL programs are legacy systems in many organizations. These are planned to be replaced with low cost commodity servers running Java or .Net based systems, saving the &amp;#8230;  Continue reading  &amp;#8594;  <br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Making Cloud Portability a Practical Reality
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Making-Cloud-Portability-Practical-Reality</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Making-Cloud-Portability-Practical-Reality</comments>
<pubDate>Fri, 09 Dec 2011 08:00:03 CST</pubDate>
<dc:creator></dc:creator>
<category>GigaSpaces</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Making-Cloud-Portability-Practical-Reality</guid>
<description><![CDATA[In one of my previous posts Five Misconceptions On Cloud Portability I argued that: The term &amp;#34;cloud portability&amp;#34; is often considered a synonym for &amp;#34;Cloud API portability,&amp;#34; which implies a series of misconceptions. If we break away from dogma, we...  Continue reading  &amp;#8594;  <br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Parabon Spins Off Nanotechnology Unit
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Parabon-Spins-Off-Nanotechnology-Unit-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Parabon-Spins-Off-Nanotechnology-Unit-2</comments>
<pubDate>Fri, 02 Dec 2011 08:00:21 CST</pubDate>
<dc:creator></dc:creator>
<category>General Grid</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Parabon-Spins-Off-Nanotechnology-Unit-2</guid>
<description><![CDATA[The grid computing pioneer's nanotechnology is based on DNA and grid power.<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Globus Looks to the Future
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Globus-Looks-to-Future-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Globus-Looks-to-Future-2</comments>
<pubDate>Fri, 02 Dec 2011 08:00:21 CST</pubDate>
<dc:creator></dc:creator>
<category>General Grid</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Globus-Looks-to-Future-2</guid>
<description><![CDATA[The open source Globus Project is planning for the future &amp;#151; and is looking to users for help in determining the grid computing group's direction.<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Parabon Builds Distributed Security Testing Service
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Parabon-Builds-Distributed-Security-Testing-Service-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Parabon-Builds-Distributed-Security-Testing-Service-2</comments>
<pubDate>Fri, 02 Dec 2011 08:00:17 CST</pubDate>
<dc:creator></dc:creator>
<category>General Grid</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Parabon-Builds-Distributed-Security-Testing-Service-2</guid>
<description><![CDATA[Parabon Computation has unveiled a grid-based online service for cyber security testing and Web monitoring.<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Pathwork, Univa UD Research Cancer in the Cloud
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Pathwork-Univa-UD-Research-Cancer-in-Cloud-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Pathwork-Univa-UD-Research-Cancer-in-Cloud-2</comments>
<pubDate>Fri, 02 Dec 2011 08:00:16 CST</pubDate>
<dc:creator></dc:creator>
<category>General Grid</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Pathwork-Univa-UD-Research-Cancer-in-Cloud-2</guid>
<description><![CDATA[A cancer diagnostics company has chosen Univa UD's UniCloud and Amazon's Elastic Compute Cloud to meet its research computing demands.<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Big Blue Takes On Swine Flu
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Big-Blue-Takes-On-Swine-Flu-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Big-Blue-Takes-On-Swine-Flu-2</comments>
<pubDate>Fri, 02 Dec 2011 08:00:15 CST</pubDate>
<dc:creator></dc:creator>
<category>General Grid</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Big-Blue-Takes-On-Swine-Flu-2</guid>
<description><![CDATA[IBM and the University of Texas are using grid computing to study drug candidates that could help fight influenza.<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Terracotta ehCache vs. GigaSpaces Cache benchmark
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Terracotta-ehCache-vs-GigaSpaces-Cache-benchmark</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Terracotta-ehCache-vs-GigaSpaces-Cache-benchmark</comments>
<pubDate>Fri, 02 Dec 2011 08:00:03 CST</pubDate>
<dc:creator></dc:creator>
<category>GigaSpaces</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Terracotta-ehCache-vs-GigaSpaces-Cache-benchmark</guid>
<description><![CDATA[Are you Really using the Most Fastest and Scalable Cache with your Application? We are hearing lately reports from several accounts &amp;#34;discovering&amp;#34; that Terracotta ehcache is not the fastest and most scalable cache out there. GigaSpaces local cache actually performs &amp;#8230;  Continue reading  &amp;#8594;  <br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Public vs Private clouds (Again!)- it’s not about the cost
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Public-vs-Private-clouds-Again-its-not-about-cost</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Public-vs-Private-clouds-Again-its-not-about-cost</comments>
<pubDate>Wed, 23 Nov 2011 08:00:23 CST</pubDate>
<dc:creator></dc:creator>
<category>GigaSpaces</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Public-vs-Private-clouds-Again-its-not-about-cost</guid>
<description><![CDATA[I was reading Geva Perry's post, 10 Predictions about Cloud Computing .. ﻿ As always I enjoyed reading Geva's throughts and for the most part comletely agree with him. The thing that caught my attention is Geva's point on private...  Continue reading  &amp;#8594;  <br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Five Misconceptions on Cloud Portability
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Five-Misconceptions-on-Cloud-Portability</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Five-Misconceptions-on-Cloud-Portability</comments>
<pubDate>Wed, 16 Nov 2011 08:00:04 CST</pubDate>
<dc:creator></dc:creator>
<category>GigaSpaces</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Five-Misconceptions-on-Cloud-Portability</guid>
<description><![CDATA[Three years ago when we started working on the first generation of our PaaS offering, cloud portability seemed to be pretty much &quot;mission impossible.&quot; At the time, we made a conscious decision to focus only on Amazon for our first...  Continue reading  &amp;#8594;  <br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[GigaSpaces Cloudify for Azure at the NYC/NJ Windows Azure User Group meetup
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=GigaSpaces-Cloudify-Azure-at-NYCNJ-Windows-Azure-User-Group-meetup</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=GigaSpaces-Cloudify-Azure-at-NYCNJ-Windows-Azure-User-Group-meetup</comments>
<pubDate>Sat, 12 Nov 2011 08:00:14 CST</pubDate>
<dc:creator></dc:creator>
<category>GigaSpaces</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=GigaSpaces-Cloudify-Azure-at-NYCNJ-Windows-Azure-User-Group-meetup</guid>
<description><![CDATA[I will be presenting next week (Wed , Nov 16 2011, 18:00 ET) at the NYC/NJ Windows Azure User Group. We will be presenting GigaSpaces Cloudify for Azure. It allows Java developers to On-board Java Applications to the Azure Cloud &amp;#8230;  Continue reading  &amp;#8594;  <br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Dealing with MySQL issues in the Cloud: Automating restart on error
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Dealing-with-MySQL-issues-in-Cloud-Automating-restart-on-error</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Dealing-with-MySQL-issues-in-Cloud-Automating-restart-on-error</comments>
<pubDate>Wed, 09 Nov 2011 08:00:28 CST</pubDate>
<dc:creator></dc:creator>
<category>all</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Dealing-with-MySQL-issues-in-Cloud-Automating-restart-on-error</guid>
<description><![CDATA[MySQL is the mainstay of most Cloud Applications (including this WordPress Blog !), however if MySQL has an issue, either through number of connections maxing out, or MySQL being locked and not available it can result in site outages. We&amp;#8217;ve seen clients who have ended up with their SQL DB down from a couple of [...]<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Using the Power of Cloud Computing with SaaS Services
		]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Using-Power-Cloud-Computing-with-SaaS-Services</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Using-Power-Cloud-Computing-with-SaaS-Services</comments>
<pubDate>Sun, 06 Nov 2011 08:00:29 CST</pubDate>
<dc:creator></dc:creator>
<category>all</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Using-Power-Cloud-Computing-with-SaaS-Services</guid>
<description><![CDATA[We recently started documenting the services we use on a day-to-day basis and it struck us just how much we use SaaS and Cloud Computing services. To that end we thought it would be fun / beneficial to share some of these and how and why we use them: File Server: SMEStorage We use SkyDrive [...]<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[I Like This Guy
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=I-Like-This-Guy-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=I-Like-This-Guy-2</comments>
<pubDate>Sat, 05 Nov 2011 08:01:25 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=I-Like-This-Guy-2</guid>
<description><![CDATA[ At the  Omniture Summit '09  last week I listened to a keynote presentation by  George Colony , head honcho over at  Forrester .  I found his style very entertaining and his points mostly on target.  I recently took a look at his  blog , and I think I really like this guy.  His blog is definitely worth a read.  (I also love the irony that in the brave new world of social media, I, Joe Nobody, can announce with a straight face to my faceless readership that I approve of the founder of Forrester.  I also approve of  Peter Gabriel  and  Scott McNealy , by the way.)<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Sun Grid Engine 6.2 Update 2 Is Out!
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Sun-Grid-Engine-62-Update-2-Is-Out-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Sun-Grid-Engine-62-Update-2-Is-Out-2</comments>
<pubDate>Sat, 05 Nov 2011 08:01:24 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Sun-Grid-Engine-62-Update-2-Is-Out-2</guid>
<description><![CDATA[  Sun Grid Engine 6.2u2  is now available.  If you're not excited, you should be.  First off, don't let the name fool you.  6.2u2 is not just bug fixes.  It's a full feature release, and contains some great features.  What features?  Glad you asked.  First and foremost,  job submission verifiers  (JSVs).  It's a feature we added specifically for  TACC , but it's one that will be useful for almost everyone.  In fact, I suspect that we'll discover it's the answer to some of the classic Sun Grid Engine problems.  What is it?  Before 6.2u2, there was no way to prevent a job from being submitted.  It was (and still is) possible to choose not to schedule a job after it's been submitted, but before 6.2u2, that's all you could do.  With 6.2u2 and JSV, you now have the option to insert a step between submission and acceptance.  With that step, you can choose to accept or reject the job submission,  but  you can also choose to modify the job before accepting it, and that's where the magic comes in.  The verification step is handled through scripts or binaries.  There's a new submission option,  -jsv , that adds a JSV to the submission.  That means you can pick up JSVs from anywhere that you can stash a submission option: most notably the global sge_request file, your user sge_request file, and the directory's sge_request file, but also DRMAA native specification, DRMAA job category, the enigmatic -@ switch, and, of course, the command line itself.  The  -jsv  switch is cumulative, so if you have one in several of those places, several JSVs will be run for your submission.  It's worth noting that all of the above listed JSV sources are controlled by the user, except the global sge_request file, and even that can be overridden with the  -clear  switch.  So far, we've only talked about the client side.  JSVs can also come in on the server side.  In the global host configuration an administrator can configure a single JSV.  Unlike on the client side where every JSV is started from scratch with every job submission, on the server side the JSV is started once and queried repeatedly.  The reason is that on the client side, performance isn't a big issue, but on the server side, the cost of forking and execing the JSV for every job submission can have a huge impact.  By keeping the JSV running, we save that cost.  The big advantage of the server-side JSV is that users can't circumvent it.  If you really need to enforce a policy with a JSV, the server side is that place to do it.  Now, if you're thinking fast, you might question the point of the server-side JSV when users can change everything about the job using qalter  after  it's submitted.  Well, so did we.  When you configure a server-side JSV, users are no longer allowed to modify jobs after submission unless you specifically grant the ability to do so, and even then it's limited to the job attributes that you allow them to modify.  JSV is a huge topic, and I could probably go on for days about it.  Instead I'll save it for a white paper and move on.  The next big feature in 6.2u2 is the  new installer .  You now have the option of using the old interactive text-based installer or a new graphical installer.  The graphical installer has several important advantages.  First, it lets you install an entire cluster at once.  It actually sits on top of the auto-installer and reuses that same functionality to install remote nodes.  The graphical installer, however, will first verify that all the nodes are reachable before the installation starts, so the installation won't quietly hang on an unreachable node.  It also accepts wildcarded host name and IP address ranges, which makes installing a huge cluster much simpler.  The third major feature is that we've added support for Microsoft Windows Vista (Ultimate and Enterprise) and Server 2003R2 and 2008.  Both 32-bit and 64-bit version are available.  Harald (who you should encourage to start blogging!) worked really hard on ironing out the issues with the changes in the OS.  We still rely on SFU for the Windows execution daemons, except that it's now called SUA.  The fourth big feature is job-level parallel job resource requests.  Before 6.2u2, whenever a parallel job requested a resource, SGE would implicitly multiply that resource request by the number of assigned slaves (because each slave requests the resource on the host where it runs).  That makes sense with, say, memory, where requesting 4GB really means that every slave should have 4GB.  It doesn't make any sense for other things, like some software licenses.  Now with 6.2u2, the administrator can flag a resource as job level, meaning that it is not multiplied by the number of assigned slaves when requested by a parallel job.  In most cases, a resource that shouldn't be multiplied in for one job, shouldn't be multiplied for any job.  There may be exceptions to the rule, but I doubt there will be many.  I'd love to hear your feedback, though.  The last two new features aren't so much features as improvements.  Starting with 6.2u2, the 64-bit Linux binaries use the  jemalloc  library instead of the default Linux malloc.  The performance and memory footprint impact is significant, in some cases as much as 20% improvement.  Also, starting with 6.2u2, the Linux binaries use poll() instead of select() in the commlib.  For some flavors of Linux, the use of select() made it difficult to scale past a couple thousand hosts.  With the commlib now using poll(), I've seen SGE scale well over 6000 Linux nodes.  And on top of all that, there is the usual pile of bug fixes.  A handful of qmaster and scheduler issues cropped up recently in 6.2 and 6.2u1, but with 6.2u2 those should all now be resolved.  I highly recommend giving 6.2u2 a  try , if for no reason other than JSV.  Let me know what you think!<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[New Installer in Sun Grid Engine 6.2 Update 2
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=New-Installer-in-Sun-Grid-Engine-62-Update-2-1</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=New-Installer-in-Sun-Grid-Engine-62-Update-2-1</comments>
<pubDate>Sat, 05 Nov 2011 08:01:24 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=New-Installer-in-Sun-Grid-Engine-62-Update-2-1</guid>
<description><![CDATA[ In my  previous post , I talked about the new installer that is included with  Sun Grid Engine  6.2u2.   Lubos , one of our core team (as opposed to Service Domain Manager or QA) engineers in Prague, has just posted a couple of videos of the new installer.  The  first one  shows how to make sure the new installer can be used with the machines you're planning to use for your cluster.  Because the new installer can install an entire cluster at once, it has to be able to contact all the machines destined for the cluster, and that's where the setup comes in.  The  second one  actually shows off the new installer.   Lubos  also has some  screenshots of the new installer  posted.<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Podcast: New Installer in Sun Grid Engine 6.2 Update 2
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Podcast-New-Installer-in-Sun-Grid-Engine-62-Update-2-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Podcast-New-Installer-in-Sun-Grid-Engine-62-Update-2-2</comments>
<pubDate>Sat, 05 Nov 2011 08:01:23 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Podcast-New-Installer-in-Sun-Grid-Engine-62-Update-2-2</guid>
<description><![CDATA[ I just posted a new  podcast  on the new installer in  Sun Grid Engine 6.2u2 .   Check it out. <br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Rube Goldberg Gone Wild
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Rube-Goldberg-Gone-Wild-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Rube-Goldberg-Gone-Wild-2</comments>
<pubDate>Sat, 05 Nov 2011 08:01:23 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Rube-Goldberg-Gone-Wild-2</guid>
<description><![CDATA[ I just can't not post  this .  Assuming they're not cheating by editing the film, this is easily the largest Rube Goldberg machine I've ever seen, and they're really creative about the elements they used.  They do lose points for not using live animals, though.   (Anyone have a better link for this video?  I'm sure it's on YouTube or Google Video somewhere, but at the moment, I can't get it to play again, so I don't have details with which to search for it.) <br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Strange Times
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Strange-Times-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Strange-Times-2</comments>
<pubDate>Sat, 05 Nov 2011 08:01:22 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Strange-Times-2</guid>
<description><![CDATA[ I just saw the  news  that  Rackable Systems  just bought  sgi .  Oh, how the mighty have fallen.  Reminds me of when  Wizards of the Coast  bought  TSR .  I hope that's the last acquisition news we here for a while...  By the way, I've started  tweeting  links like this one, rather than blogging them.  If you don't want to miss out on any of the fun,  follow me there .  (I've also started tweeting a  Grid Engine  tip of the day.)<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Shameless
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Shameless-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Shameless-2</comments>
<pubDate>Sat, 05 Nov 2011 08:01:22 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Shameless-2</guid>
<description><![CDATA[ So, you may have noticed that I haven't been blogging much lately.  That's partially because I'm completely swamped and partially because I've started  tweeting  a lot of the things that I would have normally blogged.  I'm finding that for posting links or sending out tips and tricks, Twitter is lower overhead than blogging.  One of the things I've been doing on  Twitter  is a  Grid Engine Tip of the Day .  Most of the time it's something that I just answered on the mailing list.  In general, though, it's intended to be little things that you might not have realized or known about.  Something I really like about  Twitter  is that it's more conversational.  Yes, you can leave comments on my blog posts, and yes it technically fills the same purpose, but it just seems so much more natural to just  ask a question  on  Twitter .  Of course, before asking a question is helpful, I have to build a following.  To that end, I've started doing something else on Twitter.  When people respond to the questions I ask, I've been sending the first ones &amp;quot;thank-you gifts&amp;quot;, which thus far has been 4GB USB memory sticks with the  OpenSolaris  logo.  Think of it as positive reinforcement\*.  I would love to hear your opinions here or on  Twitter  about the use of  Twitter  for conveying the kind of information that I'm prone to try to covey   \*: I reserve the right to be completely arbitrarily about when and to whom I send something and what I send them, if I send them anything.   Proper positive reinforcement  demands randomness. <br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Sun HPC Software Workshop '09
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Sun-HPC-Software-Workshop-09-5</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Sun-HPC-Software-Workshop-09-5</comments>
<pubDate>Sat, 05 Nov 2011 08:01:21 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Sun-HPC-Software-Workshop-09-5</guid>
<description><![CDATA[ Every year, usually in the autumn, we have a Grid Engine workshop, usually at the Grid Engine home base in  Regensburg , Germany.  (Last year was an exception in that we held the conference in the spring in Oakland.  What were we thinking?)  This year will be no exception.  September 7-10 at the  Best Western Premier  in Regensburg, Germany, we'll be holding the  next Grid Engine workshop .  What is exceptional about this year, though, is that we're expanding the scope to be about all of Sun's HPC software offerings.  This year, the workshop will offer three separate tracks.  One track will be essentially the Grid Engine workshop that we all know and love.  The second track will be focused on Open Storage technologies, like Lustre, SAM-QFS, ZFS, etc.  The last track will be about development tools and technologies for HPC and the cloud, including Sun's HPC developer tools, Hadoop, Fortress, the Sun Cloud, etc.  If you're interested in any of these technologies, especially Grid Engine and/or Lustre, this is a conference you won't want to miss.  And as an added incentive, the conference falls squarely in the middle of the  Regensburger Herbstdult , which is the city's autumn festival.  In US terms, it's a lot like a county fair with beer tents.  In general, think mini-Oktoberfest.  Monday (Sept. 7th) night, we'll take a delegation of folks from the conference over to the Dult for an evening of socializing over a few liters of beer.  (I have empirically proven my limit to be 2.5L in a sitting.)  The Call For Presentations for the conference is open until the end of July.  If you're doing something interesting with one, some, or all of these technologies, we'd love to hear from you.  We have presentation slots open that are 15, 25, and 55 minutes long.  In addition, if your talk is selected for the Workshop, you will get a discounted registration fee.  For details, click on the  Call for Presentations  tab on the  Workshop site .  And as if all that wasn't tempting enough, Monday, September 7th, the first day of the Workshop, will be devoted to deep-dive seminars.  These will include a full-day Grid Engine administration training, a Lustre internals deep dive, and a parallel programming class.  These is an additional fee for attending the seminars, and there are a limited number of seats.  If you're interested, sign up now!  I hope to see you there! (Look for updates on  Twitter  via the #sunhpc09 hash tag.)<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[European Students: Want a Free Laptop?
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=European-Students-Want-Free-Laptop-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=European-Students-Want-Free-Laptop-2</comments>
<pubDate>Sat, 05 Nov 2011 08:01:15 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=European-Students-Want-Free-Laptop-2</guid>
<description><![CDATA[ Are you a student in Europe \* ? Do you want a new Toshiba laptop? Willing to write some code to get it? Good. Read on.  The OpenSolaris HPC team is currently running a  programming contest  for European students that was launched at  ISC in Hamburg  last month. The contest is to write the most performant and scalable implementation of a distributed hash table. Submission can be from teams of up to three people. The top prize is a new Toshiba laptop for each member of the winning team.  For more information, check out the  contest site . Better hurry, though, because the contest deadline is coming up quick!  \* Contest participation is limited to legal residents of a specific list of European countries. See the  contest site  for details.    OFFICIAL RULES NO PURCHASE NECESSARY   1. DESCRIPTION OF THE CONTEST: The Sun HPC Software Student Programming Challenge ISC 2009 (&quot;Contest&quot;) is designed to promote the use of the Sun HPC Software, Developer Edition 1.0 for OpenSolaris among students by having them compete to design and implement the most scalable and best-performing implementation of a common parallel algorithm. Prizes will be awarded to those who submit the best entries as determined by the judges in accordance with these Official Rules.  2. ELIGIBILITY: This contest is open only to teams of 1 to 3 currently-enrolled, full- or part-time, undergraduate or graduate, university or college students, who are the legal age of majority in their country, province or state of legal residence and residents of Denmark, France, Germany, Italy, Poland, Russia, Spain, Sweden, Switzerland, and the United Kingdom. Void in Puerto Rico, Quebec and where prohibited by law. Persons in any of the following categories are not eligible to participate or win the prize(s) offered: (a) Employees or agents of Sun Microsystems, their parent companies, affiliates and subsidiaries, participating advertising and promotion agencies, application development partner companies, and prize suppliers; (b) immediate family members (defined as parents, children, siblings and spouse, regardless of where they reside) and/or those living in the same household as any person in (a) above; and (c) employees of any government entity. You must also have access to the Internet and a valid email address in order to enter or win.  3. HOW TO ENTER: This contest begins at 12:01 P.M. Pacific Time (PT) Zone in the United States (e.g. San Francisco time) which is 5:01 A.M. Greenwich Mean Time (GMT) on the 29th of June 2009 and ends at  11:59 P.M. (PT) which is 4:59 A.M. (GMT)  on 10th of August 2009 (&quot;Contest Period&quot;).IMPORTANT NOTICE TO ENTRANTS: ENTRANTS ARE RESPONSIBLE FOR DETERMINING THE CORRESPONDING TIME ZONE IN THEIR RESPECTIVE JURISDICTIONS.  4. THE SUBMISSION: Create an implementation of a fault-tolerant distributed hash table as described at http://wikis.sun.com/display/HPCContest/Sun+HPC+Software+Student+Programming+Challenge+ISC+2009 The implementation must be written in C for the OpenSolaris 2009.06 operating environment using the Sun HPC ClusterTools 8.1 OpenMPI implementation and must be submitted as a Sun Studio 12 project. All Entries must include a valid and complete Sun Studio 12 project that builds without errors on an unmodified instance of the Sun HPC Software, Developer Edition 1.0 for OpenSolaris. Entries may be submitted either electronically or via mail. All Entries must be comprised of original work of the submitter(s). No participant may submit an Entry as a member of more than one team.  Electronic Entries must include a 1-3 page written summary of the implementation approach and the name(s) of the submitter(s). The electronic file must be a gzipped tar file that includes the Sun Studio 12 project directory, including all required files, and must be no larger than 5MB in size. If the electronic file is larger than 5MB in size, it must be submitted by mail in accordance with the instructions below. The electronic entry must be sent via email to hpccontest@sun.com and received no later than 11:59 PM (PDT) on August 10th, 2009 in the United States.  Mailed Entries must include a 1-3 page written summary of the implementation approach and the name(s) of the submitter(s), and a CD or DVD containing the project code as described above. All mailed Entries must be sent to Sun HPC Software Programming Challenge, c/o Sun Microsystems, Inc., 17 Network Circle, Menlo Park, CA 94025, MS-MPK17-207, and must be received no later than 11:59 PM (PDT) on August 10th, 2009 in the United States.  All Entries must be in English. Registration or Entries that are in any other language will not be considered. Entries that are lewd, obscene, pornographic, disparaging of the Sponsor or otherwise contain objectionable material may be disqualified in the Sponsor's sole and unfettered discretion.  5. JUDGING: All Entries will be judged by a panel of experts based on the following equally weighted judging criteria: data retrieval throughput for requests coming from a single node, data retrieval throughput for parallel requests coming from multiple nodes, ability to withstand processing node failure, and scalability with respect to number of processing nodes and number of data items. In the event of a tie, the person or team among the tied Entries with the highest score in scalability with respect to number of processing nodes and number of data items will be declared the winner. In the event that no entries are received, no prize will be awarded. Decisions of judges are final and binding. Winner will be notified by email.  6. PRIZES AND APPROXIMATE RETAIL VALUE: First prize: Toshiba OpenSolaris laptop valued at approximately $2,000. Second and third prizes: Apple iPod valued at approximately $150. Up to three Toshiba laptops and six Apple iPods may be awarded. Prize includes round-trip coach air transportation for one person from major airport nearest winner's residence and hotel accommodations for one person for four nights. Hotel accommodations at Sponsor's discretion. Certain black out dates apply. In the event the Sun HPC Software Workshop is cancelled or postponed for any reason, Sponsor reserves the right to award the remainder of the prize with no further obligation to the winner. All other expenses not specified herein are the responsibility of the winner. ALL TAXES AND ANY APPLICABLE WITHOLDING AND REPORTING REQUIREMENTS ARE THE SOLE RESPONSIBILITY OF THE WINNER. Cash prizes will be awarded in US Dollars. All costs associated with currency exchange are the sole responsibility of the winner.  7. CONDITIONS OF PARTICIPATION. Sponsor reserves the right to substitute a prize for an item of equal or greater value in the event all or part of a prize becomes unavailable. Prizes are awarded without warranty of any kind from Sponsor, express or implied, without limitation, except where this would be contrary to federal, state, provincial, or local laws or regulations. All federal, state, provincial and local laws and regulations apply. Submission of entry into this Contest deems that entrants agree to be bound by the terms of these Official Rules and by the decisions of Sponsor, which are final and binding on all matters pertaining to this Contest. Return of any prize/prize notification may result in disqualification and selection of an alternate winner. Any potential winner who cannot be contacted within 15 days of attempted first notification will forfeit his/her prize. Potential prize winner(s) may be required to sign and return an Affidavit or Declaration of Eligibility/Liability &amp; Publicity Release within 30 days following the date of first attempted notification. Failure to comply within this time period may result in disqualification and selection of an alternate winner. Travel companion of winner must also execute an Affidavit of Eligibility/Liability &amp; Publicity Release prior to ticketing and must possess required travel documents (e.g. valid photo I.D.) prior to departure. Once the travel schedule has been arranged, it cannot be altered and failure of winner to follow such schedule shall not obligate Sponsor in any way to provide the winner with alternate arrangements. The intellectual and industrial property rights to the contest submission, if any, will remain with the participants, except that these terms do not supersede any other assignment or grant of rights according to any other separate agreements between participants and other parties. As a condition of entry, participants agree that Sun shall have the right to use, copy, modify and make available the application or code in connection with the operation, conduct, administration, and advertising and promotion of the Contest via communication to the public, including, but not limited to the right to make screenshots, animations and video clips available to the public for promotional and publicity purposes. Notwithstanding the foregoing, ownership of and all intellectual and industrial property rights in and to the application and code shall remain with the participant. Acceptance of the prize constitutes permission for, and winners consent to, Sponsor and its agencies to use a winner's name and/or likeness and entry for advertising and promotional purposes without additional compensation, unless prohibited by law. To the extent permitted by law, entrants, agree to hold Sponsor, its parent, subsidiaries, agents, directors, officers, employees, representatives and assigns harmless from any injury or damage caused or claimed to be caused by participation in the Contest and/or use or acceptance of any prize won, except to the extent that any death or personal injury is caused by the negligence of the Sponsor. Sponsor is not responsible for any typographical or other error in the printing of the offer, administration of the Contest or in the announcement of the prize. A participant may be prohibited from participating in this Contest if, in the Sponsor's sole discretion, it reasonably believes that the participant has attempted to undermine the legitimate operation of this Contest by cheating, deception, or other unfair playing practices or annoys, abuses, threatens or harasses any other participants, the Sponsor or associated agencies. In the event a winner/potential winner's employer has a policy, which prohibits the awarding of a prize to an employee, the prize will be forfeited and an alternate winner will be selected.  8. NO RECOURSE TO JUDICIAL OR OTHER PROCEDURES: To the extent permitted by law, the rights to litigate, to seek injunctive relief or to make any other recourse to judicial or any other procedure in case of disputes or claims resulting from or in connection with this contest are hereby excluded, and any participant expressly waives any and all such rights.  Participants agree that these Official Rules are governed by the laws of California, USA.  9. DATA PRIVACY: Participants agree that personal data, especially name and address, may be processed, stored and otherwise used for the purposes and within the context of the contest and any other purposes outlined in these Official Rules. The data may also be used by the Sponsor in order to check participants' identity, their postal address and telephone number, or to otherwise verify their eligibility to participate in the Contest and to receive any prize. Participants have a right to access, review, rectify or cancel any personal data held by the Sponsor by writing to Sponsor (Attention: Daniel Templeton) at the address listed below. If participant's data is not provided or is canceled participants' Entries will be ineligible.  10. WARRANTY AND INDEMNITY: Entrants certify that their entry is original and that they are the sole and exclusive owner and right holder of the submitted entry and that they have the right to submit the Entry in the Contest. Each participant agrees not to submit any Entry that (1) infringes any 3rd party proprietary, intellectual property, industrial property, personal rights or other rights, including without limitation, copyright, trademark, patent, trade secret or confidentiality obligation; or (2) otherwise violates applicable law in any countries in the world. To the maximum extent permitted by law, each participant indemnifies and agrees to keep indemnified the Sponsor its parent, subsidiaries, agents, directors, officers, employees, representatives and assigns harmless at all times from and against any liability, claims, demands, losses, damages, costs and expenses resulting from any act, default or omission of the participant and/or a breach of any warranty set forth herein. To the maximum extent permitted by law, each participant indemnifies and agrees to keep indemnified the Sponsor, its parent, subsidiaries, agents, directors, officers, employees, representatives and assigns harmless at all times from and against any liability, actions, claims, demands, losses, damages, costs and expenses for or in respect of which the Sponsor will or may become liable by reason of or related or incidental to any act, default or omission by a participant under these Official Rules including without limitation resulting from or in relation to any breach, non-observance, act or omission whether negligent or otherwise, pursuant to these official rules by a participant.  11. ELIMINATION: Any false information provided within the context of the Contest by any participant concerning identity, postal address, telephone number, ownership of right or non-compliance with these rules or the like may result in the immediate elimination of the participant from the Contest. Sponsor further reserves the right to disqualify any Entry that it believes in its sole and unfettered discretion infringes upon or violates the rights of any third party or otherwise does not comply with these official rules.  12. INTERNET: Sponsor is not responsible for electronic transmission errors resulting in omission, interruption, deletion, defect, delay in operations or transmission. Sponsor is not responsible for theft or destruction or unauthorized access to or alterations of entry materials, or for technical, network, telephone equipment, electronic, computer, hardware or software malfunctions or limitations of any kind. Sponsor is not responsible for inaccurate transmissions of or failure to receive entry information by Sponsor on account of technical problems or traffic congestion on the Internet or at any Web site or any combination thereof, except to the extent that any death or personal injury is caused by the negligence of the Sponsor. If for any reason the Internet portion of the program is not capable of running as planned, including infection by computer virus, bugs, tampering, unauthorized intervention, fraud, technical failures, or any other causes which corrupt or affect the administration, security, fairness, integrity, or proper conduct of this Contest, Sponsor reserves the right at its sole discretion to cancel, terminate, modify or suspend the Contest. Sponsor reserves the right to select winners from eligible entries received as of the termination date. Sponsor further reserves the right to disqualify any individual who tampers with the entry process. Caution: Any attempt by a contestant to deliberately damage any Web site or undermine the legitimate operation of the game is a violation of criminal and civil laws and should such an attempt be made, Sponsor reserves the right to seek damages from any such contestant to the fullest extent of the law.  13. If any provision(s) of these Official Rules are held to be invalid or unenforceable, all remaining provisions hereof will remain in full force and effect.  14. WINNER'S LIST: For winner's name,  log onto  http://wikis.sun.com/display/HPCContest  on or about August 14th, available for a period of up to 60 days .  15. SPONSOR: The Sponsor of this Contest is Sun Microsystems, Inc., 4220 Network Circle, Santa Clara, CA 95054.<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Lies, Damned Lies, &amp; DRMs
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Lies-Damned-Lies-DRMs-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Lies-Damned-Lies-DRMs-2</comments>
<pubDate>Sat, 05 Nov 2011 08:01:14 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Lies-Damned-Lies-DRMs-2</guid>
<description><![CDATA[ Some of our competitors seem to be very fond of spreading the rumor that the  Sun Grid Engine  product team has been laid off and/or that the product has been discontinued.  It would appear that since they can't claim to have a better, more scalable, or more cost-effective product, they're willing to go with lying through their teeth to make the sale.  Since I keep getting asked this question, I figured it would be worthwhile to post an official response.  To plagiarize Mark Twain, the rumors of our death have been greatly exaggerated.  We're still here and going strong.  The team is now roughly four times the size it was when I joined six years ago.  It spans six offices in five countries on three continents.  The product has a road map that reaches out past 2012 (which is as far as we're willing to speculate).  We have a massive (if not leading) share in both the open source and licensed DRM system markets, and we're not planning to go away any time soon.  Of course, with the deal with Larry pending, nothing is certain. The only comment I can make there is &amp;quot;no comment.&amp;quot;  That said, for now at least, it's business as usual. We're still writing code, preparing releases, doing trainings,  holding our annual Workshop , etc.  Look for the next update this quarter.  Look for the next release next year.  And look for a whole lot more good stuff coming from our team over the next several updates and releases.  With the features that have been added in the 6.2, 6.2u2 and 6.2u3 releases,  Sun Grid Engine  is in a great position. With what's coming up, I'd resort to lying too, if I worked for one of our competitors.<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Sun HPC Software Workshop '09 -- Early Bird's Almost Over!
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Sun-HPC-Software-Workshop-09-Early-Birds-Almost-Over-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Sun-HPC-Software-Workshop-09-Early-Birds-Almost-Over-2</comments>
<pubDate>Sat, 05 Nov 2011 08:01:13 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Sun-HPC-Software-Workshop-09-Early-Birds-Almost-Over-2</guid>
<description><![CDATA[ Just wanted to remind everyone that the early bird registration for the  Sun HPC Software Workshop '09 , Sept 7-10 in Regensburg, Germany, ends tomorrow (31 July 2009).  It's your last chance to sign up at the discounted rate.  After tomorrow, you will still be able to register, but the cost of registration will be higher.  In a nutshell, the  Sun HPC Software Workshop '09  is a combination of our annual  Grid Engine Workshop , a European edition of the popular  Lustre Users Group  meeting, and a conference on developing applications and services for HPC and cloud environments.  The  Workshop  lasts three days, with a presentation track representing each of these topics.  One the day before the main  Workshop  starts, we're also holding deeper technology seminars: a Lustre Deep Dive, a Grid Engine admin training, and a class on parallel application development taught by  Ruud van der Pas .  The  Workshop  and the preceding seminars are an excellent opportunity to learn more about these technologies and connect with the product engineers, partners, and other community members.  There is an open Call for Presentations for the  Workshop , but it also closes tomorrow.  If you're interested in proposing a talk for the  Workshop  (and getting a discounted registration fee if it's accepted), send a title, duration, and brief summary to the email address listed on the  Agenda  page.  But, hurry.  We'll be making our final decisions and notifying the speakers soon.  I look forward to seeing you there!<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Another Undocumented Feature
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Another-Undocumented-Feature-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Another-Undocumented-Feature-2</comments>
<pubDate>Sat, 05 Nov 2011 08:01:12 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Another-Undocumented-Feature-2</guid>
<description><![CDATA[ In reading the comments for  Issue 409 , I came across another undocumented feature I hadn't seen before.  Apparently, if you pass a variable to your job through qsub or qrsh with the -v switch, and if that variable starts with  SGE_COMPLEX_ , the  SGE_COMPLEX_  part will be stripped off, and the remainder will be treated as a resource request whose value will be placed in the job's environment.  An example will make it easier to explain.  If your job is able to run on multiple architectures, but you always select on which architecture you're running it when you submit, you could add &amp;quot;-v SGE_COMPLEX_arch&amp;quot; to the qsub submission parameters, and the job's environment would then contain the value of  arch  that was requested as the  -l arch=...  resource request.  In action, it would look like:  % qrsh -l arch=sol-amd64 -v SGE_COMPLEX_arch echo \\$SGE_COMPLEX_archsol-amd64  Nice, but why is it useful?  Well, maybe your script is capable of operating in multiple environments, but it needs to know about how it was submitted.  For example, maybe the script changes your application's startup parameters based on the memory limits.  The script could use this feature to get the memory limits from the submission parameters and act accordingly.  Of course, it could also get the memory limits from  ulimit(1) , so maybe not the best example.  Licenses may be a better example.  The OS is blissfully unaware of license assignments.  The only way for your script to find out about how many licenses were requested for it would be to use this feature (or do some clever digging with qstat).  You might have noticed by now that you could get the same effect by just passing in the requested complex value as an environment variable, e.g. &amp;quot;qsub -l arch=sol-amd64 -v arch=sol-amd64 ...&amp;quot;  The difference between using the  SGE_COMPLEX_  feature and using an environment variable explicitly is that with the  SGE_COMPLEX_  feature you don't have to know what the requested value was, i.e. you can add it to an  sge_request(5)  file or write it into your script.  And now we come to the real value.  If you have a job that needs to know about its submission parameters, you can embed submission directives to add the needed complexes' values to the environment.  Pretty handy.  Whenever you can, it's a good idea to make your jobs and scripts as self-contained as possible.   Update:  It would appear that this feature no longer works in 6.2.  The last version I was able to verify it in was 6.1u2.  Not such a big deal, though, because with 6.2 we introduced JSVs, which let you do the same thing and a tremendous amount more.<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Beta Testing the Sun Grid Engine Hadoop Integration
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Beta-Testing-Sun-Grid-Engine-Hadoop-Integration-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Beta-Testing-Sun-Grid-Engine-Hadoop-Integration-2</comments>
<pubDate>Sat, 05 Nov 2011 08:01:09 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Beta-Testing-Sun-Grid-Engine-Hadoop-Integration-2</guid>
<description><![CDATA[ In case you haven't heard yet, the upcoming release of  Sun Grid Engine  will include an integration with  Apache Hadoop  that will allow Map/Reduce jobs to be submitted to a Sun Grid Engine cluster while minding HDFS data locality.  The 6.2u5 release will be out by the end of the year, but it's currently in the beta testing phase.  And that's where you come in.  I'm looking for some volunteers to test the integration.  To that end, this blog post will provide instructions for how to get the beta code checked out and built.  The Hadoop integration is actually only loosely dependent on the Sun Grid Engine software itself.  While it's planned to be part of u5, the integration should be usable with a cluster as old to 6.2u2, although I would  really  recommend at least 6.2u4.  In a nutshell, the integration consists of two components.  The first is the  hadoop  parallel environment that allows Map/Reduce jobs to be started as parallel jobs in a Sun Grid Engine cluster.  The second is the integration with HDFS, called  Herd , that makes the Sun Grid Engine scheduler aware of the locations of the HDFS data blocks.  Herd has two parts.  One part is a load sensor that runs on every execution machine and reports the HDFS blocks on that machine.  The other part is a JSV that translates HDFS data paths included in the job submission into a list of HDFS blocks needed by the job.  How to check out the source code   Make sure you have a functional  CVS  client.   cvs -d :pserver:guest@cvs.sunsource.net:/cvs login    cvs -d :pserver:guest@cvs.sunsource.net:/cvs checkout gridengine/source    Technically, the above will only check out the  source  directory, but for the Hadoop integration, that's all you need.  The Hadoop integration lives in three places.  First, the scripts live in  source/dist/hadoop .  Second, the Herd code lives at  source/libs/herd .  Third, the JSV Java language binding upon which the Herd code depends lives at  source/libs/jjsv .  How to build the source code   Make sure you're using at least Ant 1.6.3 and the Java Standard Edition 6 platform.  Copy the  source/build.properties  file to  build_private.properties .  Edit the  build_private.properties  file to include the corrects paths for the Java Standard Edition 6 platform and junit 3.8.  Change to the gridengine/source directory.   ant jjsv    ant herd    After the above steps, you will find  herd.jar  at  source/CLASSES/herd/herd.jar  and  JSV.jar  at  source/CLASSES/jjsv/JSV.jar . How to install the integration   Copy  herd.jar  and  JSV.jar  to the  $SGE_ROOT/lib  directory.  Copy the  source/dist/hadoop  directory to somewhere accessible by all the execution nodes.   How to configure the integration   Get HDFS up and running on your cluster.  The most useful configuration will be to have every execution host be a data node, and to only have execution hosts as data nodes.  Also, because of the way Hadoop does authentication and authorization, you'll need to make sure that either HDFS has security disabled or that root and the SGE admin user are in the HDFS super user group.  Copy your Hadoop configuration directory to  &amp;lt;hadoop&amp;gt;/conf , where  &amp;lt;hadoop&amp;gt;  is the directory that you copied in step 2 of  How to install the integration .  Delete the  &amp;lt;hadoop&amp;gt;/conf/mapred.xml ,  &amp;lt;hadoop&amp;gt;/conf/masters , and  &amp;lt;hadoop&amp;gt;/conf/slaves  files.  Edit the  &amp;lt;hadoop&amp;gt;/env.sh  file to contain the paths to the Java platform, the Hadoop install directory, and the Hadoop configuration directory you just created ( &amp;lt;hadoop&amp;gt;/conf ).  Change into the  &amp;lt;hadoop&amp;gt;  directory.   ./setup.pl -i   Add the hadoop parallel environment to one or more of your queues   The  setup.pl  script will install the hadoop parallel environment and the complexes needed by Herd.  It will also start the Herd load sensor on all the execution hosts.  At this point, you should be ready to go.  Wait for a couple of minutes to give all of the execution hosts a chance to start running the load sensor and reporting values.  You can run  qhost -F hdfs_primary_rack  to check that the load sensor is functioning correctly.  Every execution host should report an hdfs_primary_rack value.  If one or more machines have not reported a value within about five minutes, see the troubleshooting section below.  Using the integration  To submit a job that uses the hadoop parallel environment, use  -pe hadoop &amp;lt;n&amp;gt; , where  &amp;lt;n&amp;gt;  is the number of nodes.  The hadoop parallel environment uses an allocation rule that guarantees that no more than one task tracker per job will run on a single host.  To tell the scheduler what data the job needs, request the  hfds_input  resource with a value of the HDFS path to the job's data.  The data path must be an absolute path.  Here's an example.  Say I want to use the grep example to find occurrences of the word 'Sun' in a series of documents.  First, I'd copy those document into HDFS to  /user/dant/sungrep  (e.g.  bin/hadoop fs -copyFromLocal ~/Documents/\* /user/dant/sungrep ).  I would then submit the job with  echo `pwd`/bin/hadoop --config \\$TMPDIR/conf jar `pwd`/hadoop-0.20.1-examples.jar grep sungrep output Sun | qsub -pe hadoop 16 -l hdfs_input=/user/dant/sungrep -jsv &amp;lt;hadoop&amp;gt;/jsv.sh .  Let's look at that in a little more detail.  First, we're echoing the Hadoop command and piping it to qsub.  Why?  Well, when the integration runs, it creates a conf directory in the job's temp directory that is properly set up for the assigned hosts.  Until the job runs, though, we don't know where the temp directory is.  We get it's path from the  $TMPDIR  variable once the job starts.  We therefore need to wrap the Hadoop command in a script.  We could either write a script that contains the command, or we could let qsub write one for us by piping the command to qsub's stdin.  Note that we used  --config \\$TMPDIR/conf  in the command.  The backslash is important because it prevents the shell on the submission host from interpreting the  $TMPDIR  variable.  Next, the qsub command uses  -pe hadoop 16  to request 16 nodes.  When this job is run, a job tracker will be started on the &amp;quot;master&amp;quot; host, and a task tracker will be started on each of the 16 assigned nodes.  The master host is the host where the parallel job's master task is started.  After the job tracker and task trackers are running, the grep job itself will be started, launched from the master host.  The  hadoop  PE is a tight integration with an allocation rule of &amp;quot;1&amp;quot;.  In order to run a Hadoop job on top of SGE, you must use the PE, even if it's only a single-node job.  The qsub command also uses  -l hdfs_input=/user/dant/sungrep -jsv &amp;lt;hadoop&amp;gt;/jsv.sh .  The  -l  resource request tells SGE what data will be used by the job.  It must be specified as an absolute path.  The  -jsv  switch actually translates the resource request for hdfs_input into requests for specific racks and blocks.  Without the  -jsv  switch, the job would never run because no node offers the hdfs_input resource.  (No node offers it because it doesn't really exist.  It's just a placeholder for the JSV to replace with rack and block requests.  In programming terms, it's a reference injection point.)  The resource request and JSV can be left out of the qsub command.  If they're left out, the scheduler will not take the HDFS data locality into consideration when scheduling the job.  You can also use the Hadoop integration to set up the job tracker and task trackers and then submit jobs to them directly.  Instead of echoing the Hadoop command to qsub, echo  sleep 300000  instead.  That will cause the job tracker and task trackers to be set up, but instead of running a job, it will just sleep for a long time.  You can then run  qstat -j &amp;lt;jobid&amp;gt; | grep context  to show the job's context.  One of the context variables will be the URL for the job tracker.  Using that URL, you can set up a Hadoop configuration to talk to the job tracker so that you can submit jobs to it from the command line.  It is also highly recommended that the use of the Hadoop integration be coupled with exclusive host access.  The Hadoop task trackers all assume that they have exclusive access to their nodes.  If you don't use exclusive host access with the Hadoop integration, you'll end up oversubscribing the nodes.  Troubleshooting  Hopefully everything will work perfectly the first time.  If for some reason it doesn't, here are some tips to help diagnose the problem:   The execds aren't reporting any hdfs resources, i.e.  qhost -F | grep hdfs  shows nothing.  Sometimes it takes several minutes for the nodes to start reporting the hdfs resources.  If after several minutes there's still nothing, pick an execution host and check if the load sensor is running:  jps -l .  Look for  com.sun.grid.herd.HerdJsv .  Note that it might be running as root or as the SGE admin user.  Also note that jps may only show you your own processes.  If the load sensor isn't running, look for log files in /tmp.  They will be called  sge_hadoop_loadsensor.out  and  sge_hadoop_&amp;lt;n&amp;gt;.log .  The .out file is the output from starting the load sensor.  The .log files are the logging output from the load sensor.  One will be the log file from the load sensor framework, and the other will be the log file from the Herd load sensor.  (You can control the logging verbosity from the logging.properties file in the &amp;lt;hadoop&amp;gt; directory.)  The most common problem is that the load sensor is started as the user root on most platforms (for a reason I don't yet understand), but that HDFS usually is not.  With HDFS, the user who started it is the super user, and only the super user can query the kind of information that the load sensor needs.  As stated in the configuration section, you must either disable HDFS security or set a super user group that contains root (and probably the SGE admin user).  The next most common problems are that the path to Hadoop or the Java platform is not correct in env.sh or that the conf directory contains bad configuration information.  You can test the load sensor manually by changing into the &amp;lt;hadoop&amp;gt; directory and running  loadsensor.sh .  If it works, it will &amp;quot;hang&amp;quot;.  Press enter, and it should spit out the hdfs resource values for that host.  Type  QUIT  and press enter to exit the load sensor.  The job tracker and/or task trackers aren't starting.  The first place to look is the PE output and error files.  The output from starting the job tracker should be found there.  The next place to look is the log files.  The log files are written where the Hadoop configuration says to put them.  Make sure that wherever that is, all the users have access to it from all the nodes.  Inability to write the log file is a common reason why the job tracker and/or task trackers won't start.  In addition to the usual Hadoop log files, the integration also write a  hadoop-&amp;lt;adminuser&amp;gt;-sge-&amp;lt;hostname&amp;gt;.log  file.  That file contains the output from starting the task trackers from the master host.  Another common reason for the job tracker and/or task trackers not to start is that the path to the Java platform isn't correctly configured in the hadoop-env.sh file. <br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Sun Grid Engine for Dummies
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Sun-Grid-Engine-Dummies-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Sun-Grid-Engine-Dummies-2</comments>
<pubDate>Sat, 05 Nov 2011 08:01:07 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Sun-Grid-Engine-Dummies-2</guid>
<description><![CDATA[ I've recently been asked for a  really  introductory doc on  Sun Grid Engine , and I was dismayed to realize that there really isn't anything like that out there.  Even the  Beginner's Guide  I wrote has some fairly high expectations of the reader's experience level.  So, this post will be my attempt at a truly introductory introduction to Sun Grid Engine.  Let's Begin at the Beginning   Servers tend to be used for one of two purposes: running services or processing workloads.  Services tend to be long-running and don't tend to move around much.  Workloads, however, such as running calculations, are usually done in a more &amp;quot;on demand&amp;quot; fashion.  When a user needs something, he tells the server, and the server does it.  When it's done, it's done.  For the most part it doesn't matter on which particular machine the calculations are run.  All that matters is that the user can get the results.  This kind of work is often called  batch ,  offline , or  interactive  work.  Sometimes batch work is called a  job . Typical jobs include processing of accounting files, rendering images or movies, running simulations, processing input data, modeling chemical or mechanical interactions, and data mining.  Many organizations have hundreds, thousands, or even tens of thousands of machines devoted to running jobs.  Now, the interesting thing about jobs is that (for the most part) if you can run one job on one machine, you can run 10 jobs on 10 machines or 100 jobs on 100 machines.  In fact, with today's multi-core chips, it's often the case that you can run 4, 8, or even 16 jobs on a single machine.  Obviously, the more jobs you can run in parallel, the faster you can get your work done.  If one job takes 10 minutes on one machine, 100 jobs still only take ten minutes when run on 100 machines.  That's much better than 1000 minutes to run those 100 jobs on a single machine.  But there's a problem.  It's easy for one person to run one job on one machine.  It's still pretty easy to run 10 jobs on 10 machines.  Running 1600 jobs on 100 machines is a tremendous amount of work.  Now imagine that you have 1000 machines and 100 users all trying to running 1600 jobs each.  Chaos and unhappiness would ensue.  To solve the problem of organizing a large number of jobs on a set of machines, distributed resource managers (DRMs) were created.  (A DRM is also sometimes called a workload manager.  I will stick with the term, DRM.)  The role of a DRM is to take a list of jobs to be executed and distributed them across the available machines.  The DRM makes life easier for the users because they don't have to track all their jobs themselves, and it makes life easier for the administrators because they don't have to manage users' use of the machines directly.  It's also better for the organization in general because a DRM will usually do a much better job of keeping the machines busy than users would on their own, resulting in much higher utilization of the machines.  Higher utilization effectively means more compute power from the same set of machines, which makes everyone happy.  Here's a bit more terminology, just to make sure we're all on the same page.  A  cluster  is a group of machines cooperating to do some work.  A DRM and the machines it manages compose a cluster.  A cluster is also often called a  grid .  There has historically been some debate about what exactly a grid is, but for most purposes  grid  can be used interchangeably with  cluster .   Cloud computing  is a hot topic that builds on concepts from grid/cluster computing.  One of the defining characteristics of a  cloud  is the ability to &amp;quot;pay as you go.&amp;quot;  Sun Grid Engine offers an accounting module that can track and report on fine grained usage of the system.  Beyond that, Sun Grid Engine now offers deep integration to other technologies commonly being used in the cloud, such as  Apache Hadoop .  How Does It Work?  A Sun Grid Engine cluster is composed of execution machines, a master machine, and zero or more shadow master machines.  The execution machines all run copies of the Sun Grid Engine execution daemon.  The master machine runs the Sun Grid Engine qmaster daemon.  The shadow master machines run the Sun Grid Engine shadow daemon.  In the event that the master machine fails, the shadow daemon on one of the shadow master machines will become the new master machine.  The qmaster daemon is the heart of the cluster, and without it the no jobs can be submitted or scheduled.  The execution daemons are the work horses of the cluster.  Whenever a job is run, it's run by one of the execution daemons.     To submit a job to the cluster, a user uses one of the submission commands, such as qsub.  Jobs can also be submitted from the graphical user interface, qmon, but the command-line tools are by far more commonly used.  In the job submission command, the user includes all of the important information about the job, like what it should actually run, what kind of execution machine it needs, how much memory it will consume, how long it will run, etc.  All of that information is then used by the qmaster to schedule and manage the job as it goes from pending to running to finished.  For example, a qsub submission might look like:  qsub -wd /home/dant/blast -i /home/dant/seq.tbl -l mem_free=4G cross-blast.pl ddbdb .  This job searches for DNA sequences from the input file /home/dant/seq.tbl in the ddbdb sequence database.  It requests that it be run in the /home/dant/blast directory, that the /home/dant/seq.tbl file be piped to the job's standard input, and that it run on a machine that has at least 4GB of free memory.  Once a job has been submitted, it enters the pending state.  On the next scheduling run, the qmaster will rank the job in importance versus the other pending jobs.  The relative importance of a job is largely determined by the configured scheduling policies.  Once the jobs have been ranked by importance, the most important jobs will be scheduled to available job  slots .  A  slot  is the capacity to run a job.  Generally, the number of slots on an execution machine is set to equal the number of CPU cores the machine has; each core can run one job and hence represents one slot.  Every available slot is filled with a pending job, if one is available.  If a job requires a resource or a slot on a certain type of machine that isn't currently available, that job will be skipped over during that scheduling run.  Once the job has been scheduled to an execution machine, it is sent to the execution daemon on that machine to be run.  The execution daemon executes the command specified by the job, and the job enters the running state.  Once the job is running, it is allowed to continue running until it completes, fails, is terminated, or is requeued (in which case we start over again).  Along the way the job may be suspended, resumed, and/or checkpointed any number of times.  (Sun Grid Engine does not handle checkpointing itself.  Instead, Sun Grid Engine will trigger whatever checkpointing mechanism is available to a job, if any is available.)  After a job has completed or failed, the execution daemon cleans up after it and notifies the qmaster.  The qmaster records the job's information in the accounting logs and drops the job from its list of active jobs.  If the submission client was synchronous, the qmaster will notify the client that the job ended.  Information about completed jobs is available through the qacct command-line tool or the Accounting and Reporting Console's web console.  In addition to traditional style batch jobs, as in the BLAST example above, Sun Grid Engine can also manage interactive jobs, parallel jobs, and array jobs.  An interactive job is like logging into a remote machine, except that Sun Grid Engine decides to which machine to connect the user.  While the user is logged in, Sun Grid Engine is monitoring what the user is doing for the accounting logs.  A parallel job is a distributed job that runs across multiple nodes.  Typically a parallel job relies on a parallel environment, like MPI, to manage its inter-process communication.  An array job is similar to a parallel job except that it's processes don't communicate; they're all independent.  Rendering an image is a classic array job example.  The main difference between a parallel job and an array job is that a parallel job needs to have all of its processes running at the same time, whereas an array job doesn't; it could be run serially and would still work just fine.  What's So Special About Sun Grid Engine?  If any old DRM (and there are quote a few out there) solves the problem, why should you be particularly interested in Sun Grid Engine?  Well, there are a few reasons.  My top reasons (in no particular order) why Sun Grid Engine is so great are:   Scalability &amp;mdash; Sun Grid Engine is a  highly  scalable DRM system.  We have customers running clusters with thousands of machines, tens of thousands of CPU cores, and/or processing tens of millions of jobs per month.  Flexibility &amp;mdash; Sun Grid Engine makes it possible to customize the system to exactly fit your needs.  Advanced scheduler &amp;mdash; Sun Grid Engine does more than just spread jobs evenly around a group of machines.  The Sun Grid Engine qmaster supports a variety policies to fine-tune how jobs are distributed to the machines.  Using the scheduling policies, you can configure Sun Grid Engine to make its scheduling decisions match your organization's business rules. <br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Welcome Sun Grid Engine 6.2 update 5
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Welcome-Sun-Grid-Engine-62-update-5-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Welcome-Sun-Grid-Engine-62-update-5-2</comments>
<pubDate>Sat, 05 Nov 2011 08:01:02 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Welcome-Sun-Grid-Engine-62-update-5-2</guid>
<description><![CDATA[ The  Sun Grid Engine 6.2 update 5  release is now available.  Don't let the unassuming version number fool you; there's quite a few interesting features packed into this release.  Let's talk about them, shall we?  Integration with Apache Hadoop  SGE 6.2u5 gets to claim the title of first workload manager with direct support for  Apache Hadoop  applications.  What does that mean?  First, it means that you can submit Hadoop applications to an SGE cluster just like you would any other parallel job.  The cluster will take care of setting up the Hadoop jobtracker and tasktrackers for you.  Second, it means that the SGE scheduler knows about the HDFS data locality such that it can route Hadoop jobs to nodes where the jobs' data already lives.  The net result is that you can now realistically consolidate your Hadoop cluster into your SGE cluster, saving you time, money, and lots of headaches.  See the  docs  for  more info .  [Also see my  next post .]  Topology-aware Scheduling  Many applications benefit greatly by being tied to specific CPU sockets and/or cores.  For example, some cache-hungry applications will execute in half the time if run on four cores on different sockets versus running on four cores in the same socket.  With SGE 6.2u5, we've added the ability to specify these topology preferences when submitting your jobs.  Whenever possible, the scheduler will honor the topology preferences when assigning jobs to nodes.  For topology-sensitive applications and clusters with lots of Nehalem boxes, SGE 6.2u5 can speed up application execution considerably.  See the  docs  for  more info .  [Also see my  follow-up post .]  Slotwise Subordination  The SGE preemption model is what I call &amp;quot;after-market preemption&amp;quot; meaning that it's not an inherit aspect of every cluster.  You have to take preemption (AKA subordination) into account when designing your cluster layout.  Prior to SGE 6.2u5, the preemption model was rather coarse grained.  SGE could only suspend an entire queue instance at a time, meaning that one high-priority job might be suspending two or four or sixteen or more lower-priority jobs.  With SGE 6.2u5, we're introducing finer grained preemption.  Now, rather than declaring that just Queue A is subordinated to Queue B, you can say that between Queues A and B there shouldn't be more than 4 jobs running, and given a conflict, Queue B wins.  This new finer-grained preemption model means that you can now use subordination without paying for it with utilization.  See the  docs  for  more info .  [Also see my  follow-up post .]  User-controlled Array Task Throttling  One of the unique things about Sun Grid Engine is that it handles array jobs extremely efficiently.  In many cases users will consolidate individual batch jobs together into array jobs to take advantage of that fact.  The down side is that all tasks within an array job are considered equal with regard to scheduling policies.  If an array job is the highest priority job in the system, all of it's tasks are also higher priority than any other jobs.  If that array job has ten thousand tasks (something not uncommon or really even all that stressful for SGE), then all ten thousand tasks will be run before any other jobs (unless another job later becomes higher priority), at least by default.  An administrator can configure a global limit to the number of tasks from a single array job that are allowed to execute at a time.  Better than nothing, but global policies always leave something to be desired.  With SGE 6.2u5, we've introduced the ability for a user to apply self-imposed limits to his individual array jobs.  Why would a user voluntarily set limits?  In most cases it turns out that users want to do the right thing and will gladly do so given the chance.  Self-imposed limits help the cluster run more smoothly, meaning that everyone gets what they want faster, and no one gets bonked on the head by the administrator.  Additionally, if a user has more than one large array job pending, setting self-imposed limits allows them all to make progress instead of completing them serially.  For more than one customer I know about, this feature alone will be reason enough to upgrade.  [See my  follow-up post  for more info.]  Extended SGE Inspect  SGE Inspect, the new UI introduced in SGE6.2u3, was previously only a monitoring tool.  With SGE 6.2u5, we've added the ability to manage parallel environments.  Going forward we will continue adding management functionality.  See the  docs  for  more info .  Improved Cloud Connectivity  With SGE 6.2u3, we added the ability through the Service Domain Manager component to automatically provision additional cluster nodes from Amazon EC2 during peak periods.  With SGE 6.2u5, we've expanded that functionality a bit and made it easier to use.  See the  docs  for  more info .  Improved Power Management  Same story as the cloud connectivity, really.  We introduced the ability to automatically power down idle or underused nodes with SGE 6.u3 through the Service Domain Manager component.  With SGE 6.2u5, we've fleshed it out a bit more and more it easier to use. &amp;nbsp; &amp;nbsp;  Over the next couple of weeks I'll try to write some posts about these features individually.  If you're already Grid Engine savvy, go  grab a copy  and get started.  If you need more info, try starting with  the beginner's guide .<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Leading the Herd
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Leading-Herd-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Leading-Herd-2</comments>
<pubDate>Sat, 05 Nov 2011 08:00:51 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Leading-Herd-2</guid>
<description><![CDATA[ Wow!  There's been a surprising amount of  noise  lately about the  Apache Hadoop  integration with  Sun Grid Engine 6.2u5 .  Since folks seem to be interested, I figure it's a good place to start on my feature deep-dive posts that  I promised .  I'm going to assume that you already understand the many virtues of Hadoop.  (And if you don't,  Cloudera  will be happy to  tell you all about it .)  Instead, to set the stage, let's talk about what Hadoop doesn't do so well.  I currently see two important deficiencies in Hadoop: it doesn't play well with others, and it has no real accounting framework.  Pretty much every customer I've seen running Hadoop does it on a dedicated cluster.  Why?  Because the tasktrackers assume they own the machines on which they run.  If there's anything on the cluster other than Hadoop, it's in direct competition with Hadoop.  That wouldn't be such a big deal if Hadoop clusters didn't tend to be so huge.  Folks are dedicating hundreds, thousands, or even tens of thousands of machines to their Hadoop applications.  That's a lot of hardware to be walled off for a single purpose.  Are those machines really being used?  You may not be able to tell.  You can monitor state in the moment, and you can grep through log files to find out about past usage (Gah!), but there's no historical accounting capability there.  Coincidentally, these two issues are things that most workload managers (like  Sun Grid Engine ) do really well.  And I'm not the first to notice that.  The  Hadoop on Demand  project, which is included in the Hadoop distribution, was an attempt to integrate Hadoop first with  Condor  and then with  Torque , probably for those same reasons.  It's easy enough to have the Hadoop framework started on demand by a workload manager.  The problem is that most workload managers know nothing about HDFS data block locality.  When a typical workload manager assigns a set of nodes to a Hadoop application, it's picking the nodes it thinks are best, generally the ones with the least load, not the ones with the data.  The result is that most of your data is going to have to be shipped to the machines where the tasks are executing.  Since the great innovation of Map/Reduce is that we move the execution to the data instead of vice versa, bringing a workload manager into the picture shoots Hadoop in the foot.  Enter Sun Grid Engine 6.2 update 5.  One of the main strengths of the Sun Grid Engine software is its ability to model just about anything as a  resource  (called a &amp;quot;complex&amp;quot; in SGE terms) and then use those resources to make scheduling decisions.  Using that capability, we've modeled HDFS rack location and the locally present HDFS data blocks as resources.  We then taught SGE how to translate an HDFS path into a set of racks and blocks.  Finally, we taught SGE how to start up a set of jobtrackers and tasktrackers, and voila!  Ze Hadoop integration iz born.  More detail?  Glad you asked.  The Gory Details  The Hadoop integration consists of two halves.  The first half is a parallel environment that can start up a jobtracker and tasktrackers on the nodes assigned by the scheduler.  (HDFS is assumed to already be running on all the nodes in the cluster.)  In the end, it's really no different than an MPI integration (especially MPICH2).  The second half is called  Herd .  It's the part that talks to HDFS about blocks and racks, and it has two parts.  The first part is the  load sensor  that reports on the block and rack data for each execution host (hosts that are running the SGE execution daemon).  The second part is a  Job Submission Verifier  that translates requests for HDSF data paths into requests for racks and blocks.  The process for running a Hadoop job as an SGE job looks something like this:     At regular intervals, all of the execution hosts report their load.  This includes the rack and block information collected by the Herd load sensors.    User submits a job, e.g.  echo $HADOOP_HOME/hadoop --config \\$TMP/conf jar $HADOOP_HOME/hadoop-\*-examples.jar grep input output SGE | qsub -jsv jsv.sh -l hdfs_input=/user/dant/input -pe hadoop 128     The jsv.sh script starts the Herd JSV that talks to the HDFS namenode.  It removes the hard hdfs_input request and replaces it with a soft request for hdfs_primary_rack, hdfs_secondary_rack, and a set of hdfs_blk&amp;lt;n&amp;gt;&amp;lt;n&amp;gt; resources.  (A hard request is one that is required for a job to run.  A soft request is one that is desired but not required.)  The primary rack resource lists the racks where most of the data live.  The secondary rack resource lists all of the racks where any of the data lives.  Because the HDFS data block id space is so large, we aggregate blocks into 256 chunks by their first two hex digits.    The scheduler will do its best to satisfy the job's soft resource requests when assigning it nodes, 128 in this example.  It's probably not going to be able to assign the perfect set of nodes for the desired data, but it should get pretty close.    After the scheduler assigns hosts, the qmaster will send the job (everything between the &amp;quot;echo&amp;quot; and the &amp;quot;|&amp;quot;) to one of the assigned execution hosts.    Before the job is started on that host, the Hadoop parallel environment kicks in.  It starts a tasktracker remotely on every node assigned to the job (all 128 in this example) and a single jobtracker locally.  An important point here is that the tasktrackers are all started through SGE rather than through ssh.  Because SGE starts the tasktrackers, it is able to track their resource usage and clean up after them later.    After the Hadoop PE has done its thing, the job itself will run.  Notice in the example that I told it to look in $TMP/conf for its configuration.  The Hadoop PE sets up a conf directory for the job that points to the jobtracker it set up.  That conf directory gets put in the job's temp directory, which is exported into the job's environment as $TMP.    After the job completes, the Hadoop parallel environment takes down the jobtracker and tasktrackers.    Information about the job, how it ran, and how it completed is logged by SGE into the accounting files.   Since everyone loves pretty pictures, here's the diagram of the process:     The Hadoop integration will attempt to start a jobtracker (and corresponding tasktrackers) per job.  For most uses, that should be perfectly fine.  If, however, you wan to use the HoD allocate/deallocate model, you can do that, too.  Instead of giving SGE a Hadoop job to run, give it something that blocks (like &amp;quot;sleep 10000000&amp;quot;).  When the job is started, the address of its jobtracker is added to its job context.  Just query the job context, grab the address, and build your own conf directory to talk to the jobtracker.  You can then submit multiple Hadoop jobs within the same SGE job.  Hopefully this gives you a clear picture of how the Hadoop integration works.  You can find more information in  the docs .  I think it's a testament to the flexibility of Sun Grid Engine that the integration did not require and changes to the product.  All I did was add in some components through the hooks that SGE already provides.  One more thing I should also point out.  This integration is in the Sun Grid Engine product, but not in the  Grid Engine  courtesy binaries that we  just announced .<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[The Sun'll Come Out Toworrow
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Sunll-Come-Out-Toworrow-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Sunll-Come-Out-Toworrow-2</comments>
<pubDate>Sat, 05 Nov 2011 08:00:48 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Sunll-Come-Out-Toworrow-2</guid>
<description><![CDATA[ I've always had a tendency to say &amp;quot;tomorrow,&amp;quot; when I really mean &amp;quot;next working day.&amp;quot;  Most of the time there's no difference, but Fridays and the day before a holiday, people look at me funny.  I find it silly that I have to figure out the next day I'll be at work so I can reference it by name.  Instead, I'm now coining a new word:   to⋅wor⋅row  [tuh- wawr -oh, - wor -oh]   -noun     the working day following today:  Toworrow I have a big meeting.     Your homework is to use &amp;quot;toworrow&amp;quot; in a sentence at least three times this weekend.  We'll compare results toworrow.<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Topology-Aware Scheduling
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=TopologyAware-Scheduling-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=TopologyAware-Scheduling-2</comments>
<pubDate>Sat, 05 Nov 2011 08:00:45 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=TopologyAware-Scheduling-2</guid>
<description><![CDATA[ Continuing in my feature deep dives, let's talk about topology-aware scheduling.  Some applications have serious resource needs.  Not only do they need raw CPU cores, but they also beat the snot out of the local cache or burn up the I/O channels.  These sorts of applications don't play well with others.  In fact, they often don't play well with themselves.  For these applications, how the threads/processes are distributed across the CPUs makes a huge difference.  If, for example, all the threads/processes have their own core but are all sharing a socket, they might end up fighting over cache space or I/O bandwidth.  Depending on the CPU architecture, the conflicts may be more subtle, such as only the processes on specific groups of cores colliding.  The price for making a bad choice of how to assign these applications to cores is poor performance, in some cases doubling the time to completion.  It's not just the powerhouse apps that care about CPU topology, though.  Most operating systems will schedule processes and threads to execute on available cores rather willy-nilly, with no sense of core affinity.  Because an average OS does context switches at a rather high frequency, an application may find itself executing on a different CPU and core every time it gets the chance to run.  If that application makes any use of the CPU cache, for example, its performance will suffer for it.  The performance might not suffer much, but the difference is usually measurable.  For these reasons, we've added topology-aware scheduling to  Sun Grid Engine 6.2 update 5 .  With topology-aware scheduling, the user who submits the job can specify how that job should be laid out across a machine's CPUs.  Users are allowed to specify three different flavors of distribution strategy: linear, striding, or explicit.  In linear distribution, the execution daemon will place the job's threads/processes on consecutive cores if possible.  If it can't fit the entire job on a single socket, it will span the job across sockets.  The striding strategy tells the execution daemon to place the job on every nth core, e.g. every 4th core or every other core.  The explicit strategy lets the user decide exactly which cores will be assigned to the job.  Note that the core binding is a request, not a requirement.  If for some reason the execution daemon can't fulfill the request, the job will still be executed; it just won't be bound.  In addition to the three binding strategies, there are also three possible binding mechanisms.  You can either allow Sun Grid Engine to do the binding automatically as part of the job execution, or you can have Sun Grid Engine add the binding parameters to the machines file for OpenMPI jobs, or you can have Sun Grid Engine just describe the intended binding in an environment variable with the expectation that the job will bind itself based on that information.  When the job is bound by Sun Grid Engine during execution, the job will be tied to specific CPU cores using an OS-specific system call.  On Linux, the bound processors may be shared with other processes.  On Solaris, the bound processors are used exclusively for the job.  In either case, the job will only be allowed to execute on the bound processors.  In order to allow users to tell what kinds of topologies are provided by the machines in the cluster, some new default complexes have been added that describe the socket/core/thread layouts of the machines.  These new complexes can be used during job submission to request specific topologies, or they can be used with  qhost  to report what's available.  Let's look at a couple of examples (taken from the  docs ).   % qsub -binding linear:4 -l m_core=8 -l m_socket=2 -l arch=lx26-amd64 job.sh   This example will look for a machine with 8 cores and 2 sockets (i.e. dual-socket, quad-core) and try to bind to four consecutive cores.  The execution daemon will try to put all four cores on the same socket, but if that's not possible, it will spread the job out over as many sockets as required (but as few as possible).   % qsub -binding striding:2:4 -l m_core=8 -l m_socket=2 -l arch=lx26-amd64 job.sh   This example will again look for a dual-socket, quad-core machine, but this time the job will occupy the third core on both sockets.  (The first core is number 0.)  If the third core on either socket is occupied, the job will not be bound.   % qsub -binding explicit:0,0:0,3:1,0:1,3 -l m_core=8 -l m_socket=2 -l arch=lx26-amd64 job.sh   This last example will yet again look for a dual-socket, quad-core machine.  This time the job will be bound to the first and fourth cores on both sockets.  Again, if any of those core are already bound to another job, the job will not be bound.  It's clear that jobs that benefit from specific process placement with respect to CPU cores will perform much better in a 6.2u5 cluster, thanks to this new feature.  Even for regular old run-of-the-mill jobs, though, submitting with  -binding linear:1  should provide a small performance bump because it will keep them from being jostled around between context switches.  In fact, I won't be surprised if 12 months from now I include adding that switch to the  sge_request  file in my top 10 list of best practices.<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Better Preemption
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Better-Preemption-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Better-Preemption-2</comments>
<pubDate>Sat, 05 Nov 2011 08:00:41 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Better-Preemption-2</guid>
<description><![CDATA[ Continuing with the new feature theme, this week we're talking about slotwise subordination (AKA slotwise preemption).  Preemption is the notion that a higher priority job can bump a lower priority job out of the way so it can execute.  Pretty simple notion.  Some workload managers have an implicit concept of preemption.   Sun Grid Engine  does not.  We have what I like to call &amp;quot;after-market preemption&amp;quot;.  The net result is the same.  In a workload manager with &amp;quot;built-in&amp;quot; preemption, like Platform LSF, it works by temporarily relaxing the slot count limit on a node and then resolving the oversubscription by bumping the lowest job on the totem pole to get the number of jobs back under the slot count limit.  In Sun Grid Engine, the same thing happens, except that instead of the scheduler temporarily relaxing the slot count limits, you as the administrator configure the host with more slots than you need and a set of rules that create an artificial lower limit on the job count that is enforced by bumping the lowest priority jobs.  It nets out to the same thing.  With Sun Grid Engine you have a little more control over the process, but you pay for it with some added complexity.  That set of rules that defines the artificial limit is called subordination.  By subordinating one queue to another, you tell the master that jobs running in the subordinated queue are lower priority and should be preempted when necessary.  Specifically, all jobs in the subordinated queue are suspended when a threshold number of jobs (usually 1) are scheduled into the queue to which it is subordinated.  Queue subordination in Sun Grid Engine was implemented long ago, when single-socket, single-core machines still roamed the Earth.  Back in those days, there was generally only one job running per host, so the queuewise subordination scheme worked out just fine.  Now that we're in the era of multi-core machines, suspending the entire subordinate queue tends to be a bad idea.  Enter slotwise preemption.  In a nutshell, slotwise preemption lets you set a specific limit on the number of jobs allowed to be running on a host, regardless of how many queues and slots there are.  If too many jobs land on the host, jobs in the lowest ranking queue(s) will be suspended until the number of running jobs is under the limit.  (Note that slotwise subordination deals only with the running job count.  If you want to limit the active job count (running + suspended), you can do that by making the slots complex a host-level resource and setting it to the desired limit.)  Let's look at some examples from the  queue_conf(5) man page :  Assume we have a cluster of dual-core machines and two queues that span all the machines, A.q and B.q, each with two slots:    % qconf -sq A.q | grep subordinate_listsubordinate_list      slots=2(B.q:0:sr)% qconf -sq B.q | grep subordinate_listsubordinate_list      NONE    This configuration says that there are four slots available on each host (2 in each queue), but that only 2 jobs may be running on any host at any given time.  If more than 2 jobs end up on a node, it will result in the excess jobs being suspended.  Because B.q is subordinated to A.q, the  excess  jobs will always come from B.q.  Let's talk about the difference between queue-wise and slot-wise suspension for this example.  With queue-wise suspension, you'd have two choices: either a single job in A.q would suspend all jobs in B.q, or two jobs in A.q would suspend all jobs in B.q.  The choice is either undersubscribing (with one running job in A.q and two suspended jobs in B.q) or oversubscribing (with one running job in A.q and two running jobs in B.q).  With slot-wise suspension, a job running in A.q will only suspend a job running in B.q if there are more than two running jobs on the host.  We will therefore never oversubscribe, and we'll never undersubscribe as long as there's a job available to run.  Let's look at a more complex example:    % qconf -sq A.q | grep subordinate_listsubordinate_list      slots=2(B.q:1:sr,C.q:2:lr)% qconf -sq B.q | grep subordinate_listsubordinate_list      NONE% qconf -sq C.q | grep subordinate_listsubordinate_list      NONE    We've added a third queue, and we now have a very simple tree.  Both B.q and C.q are subordinated to A.q, but there are still only 2 slots available for running jobs.  If a host is scheduled with more than two running jobs, jobs will be suspended until we get down to two, just like before.  What's different is that there's now a pecking order for the subordinated queues.  Because B.q has a lower sequence number (1) than C.q (2), it is higher priority.  That means we'll suspend jobs from C.q first, before suspending jobs from B.q.  What's also different is how we pick the job to suspend.  In B.q in both examples, the action is listed as &amp;quot;sr&amp;quot;, which means to suspend the shortest running job.  In C.q in this example, the action is &amp;quot;lr&amp;quot;, which means to suspend the longest running job.  One more example:    % qconf -sq A.q | grep subordinate_listsubordinate_list      slots=3(B.q:0:sr)% qconf -sq B.q | grep subordinate_listsubordinate_list      slots=2(C.q:0:sr)% qconf -sq C.q | grep subordinate_listsubordinate_list      NONE    Now we have a tree with more than a two levels: C.q is subordinated to B.q is subordinated to A.q.  Between B.q and C.q up to two jobs are allowed to be running, with B.q's jobs taking priority.  Among A.q, B.q, and C.q, up to three jobs are allowed to be running, with A.q's jobs taking priority over B.q's jobs, and B.q's jobs taking priority over C.q's jobs.  Now look carefully.  Where did I specify that C.q should be subordinated to A.q?  I didn't.  It's implicit.  Whenever you have a multi-level subordination tree, a node has its entire subtree subordinated to it, whether it's explicitly specified or not, with priority handled between nodes according to depth in the tree and priority with levels handled according to sequence numbers.  Because of this implicit subordination, it does not make sense to ever have a higher slot limit lower down in the tree.  The higher-level lower slot limit will always take precedence.  Hopefully slotwise subordination now makes sense, and you can see why it's important.  Basically it brings Sun Grid Engine's preemption capabilities up to date with modern hardware, making it more efficient and more useful.  There is, however, one notable caveat I have to point out.  With queue-wise suspension, when a subordinated queue has its jobs suspended, the queue itself is also suspended, preventing any other jobs from landing in that queue.  That's not the case with slotwise subordination.  It's possible for the scheduler to place a job into a subordinated queue where that job will immediately be suspended.  Imagine in our first example above that A.q has two running jobs in it while B.q is empty.  B.q remains a valid scheduling target, and any job that lands there will immediately be suspended because it violates the slotwise limit.  The workaround is to use job load adjustments to make sure that hosts with running jobs are appropriately unattractive scheduling targets.  Not a show-stopper, but definitely important to be aware of.  We will address the issue in the next couple of releases.<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Self Control
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Self-Control-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Self-Control-2</comments>
<pubDate>Sat, 05 Nov 2011 08:00:39 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Self-Control-2</guid>
<description><![CDATA[ Good day, and welcome to week four of my continuing attempt to cover all the features added in the  latest release (6.2u5)  of  Sun Grid Engine .  This week we'll talk about array task throttling.  Sun Grid Engine supports four classes of jobs.   Interactive  jobs are the equivalent of doing an rsh/rlogin/ssh to a node in the cluster, except that the connection is managed by Sun Grid Engine.   Batch  jobs are your traditional &amp;quot;go run this somewhere&amp;quot; type of job.  They represent a single instance of an executable.   Parallel  jobs consist of multiple processes working in collaboration.  All of the processes need to be scheduled and running at the same time in order for the job to run.   Parametric  or  array  jobs are like what you see in  Apache Hadoop , where multiple copies of the same executable are run across multiple nodes against different parts of the data set.  The important characteristic that distinguishes array jobs from parallel jobs is that the tasks of an array job are completely independent from each other and hence do not need to all be running together.  The way that Sun Grid Engine processes array jobs is particularly efficient.  In fact, a common trick to improve cluster throughput is to bundle many batch jobs together to be submitted as a single array job.  Because array jobs are so efficient, users use lots of them, sometimes with huge task counts.  There is no explicit limit on the number of tasks that an array job can contain.  Hundreds of thousands of tasks in a single array job are not uncommon.  There is a problem, however.  From the Sun Grid Engine scheduler's perspective, all of the tasks of an array job are equal.  That means that if the highest priority job waiting to execute is an array job, then all of that job's tasks are higher priority than any other job (or task) waiting to run.  If that job has a million tasks, then the cluster is going to have to process all million of those tasks before anything else will be executed.  Now, the policies do come into play here, and if a higher priority job is submitted or if the array job loses priority through some policy (like the fair share policy), then it and its remaining tasks will fall back in the execution order.  Nonetheless, this approach makes it possible for a user to unintentionally execute a denial of service attach on the cluster.  For quite some time there has been an option that an administrator can configure to set a limit on the maximum number of tasks that can be simultaneously executed from a single array job ( max_aj_instances  in  sge_conf(5) ).  That solves the problem, but only in a very general and somewhat suboptimal way.  As with any such global setting, the administrator has to make a trade-off between having a limit that works well for the majority and having a limit that doesn't unduly restrict certain users.  (The default is 2000 tasks per array job.)  Well, it turns out that given the opportunity, most users will willing set such a limit themselves, both to avoid being bonked on the head by the administrator for abusing the cluster, and for reasons of self interest, such as by allowing multiple of their array jobs to share cluster time rather than being processed sequentially.  So, with 6.2u5, we've given users exactly that ability.  Let's look at an example:   % qsub -t 1-100000 myjob.sh   will submit an array job that will run the  myjob.sh  script one hundred thousand times.  Each time it runs, an environment variable ( $SGE_TASK_ID ) will be set to tell that instance which task number it is.  The  myjob.sh  script must be able to translate that task ID into a pointer to its portion of the data set.  In a cluster with default settings, up to 2000 of the tasks of this job will be allowed to be running at a time.  If the cluster only has 2000 slots, that could be a bad thing.   % qsub -t 1-100000 -tc 20 myjob.sh   submits the same job, except that it places a limit of 20 on the number of tasks allowed to be running simultaneously.  In our fictitious 2000-slot cluster, that's a quite neighborly thing to do.  If you try to set the limit above the global limit set by the administrator, the global limit prevails.  While this feature is pretty simple, it can mean a large difference in job throughput for some clusters.  I know one customer in particular that went  way  out of their way to implement this feature themselves using clever configuration tricks.  The massive headache of hacking together a solution was worth it to them to be able to set per-job task limits.<br/><br/>0 Vote(s) ]]></description>
</item>

<item>
<title><![CDATA[Intro to Service Domain Manager
    ]]></title>
<link>http://smetube.com/TheGridPlace/story.php?title=Intro-to-Service-Domain-Manager-2</link>
<comments>http://smetube.com/TheGridPlace/story.php?title=Intro-to-Service-Domain-Manager-2</comments>
<pubDate>Sat, 05 Nov 2011 08:00:35 CDT</pubDate>
<dc:creator></dc:creator>
<category>Sun Grid Engine</category>
<guid>http://smetube.com/TheGridPlace/story.php?title=Intro-to-Service-Domain-Manager-2</guid>
<description><![CDATA[ Let's take a break from the  Sun Grid Engine 6.2u5  feature posts and talk about something that's been in the product since 6.2.  (It's actually the foundation of two of the remaining three features, so consider this ground work for finishing my u5 features series.)  Service Domain Manager (or the open source  Project Hedeby  (formerly Project Haithabu)) is an add-on component for Sun Grid Engine that enables multiple clusters to share resources.  It was designed to allow for services of all types to share resources with each other.  The basic idea is this: each cluster has a set of performance metrics specified via service level objectives (SLOs).  If at any point a cluster is in violation of its SLOs, it appeals to the SDM  resource provider  service for additional resources.  The resource provider will look for resources wherever they're available: in spare resource pools, from cloud service providers, or from other less-loaded clusters.  If resources are available, the resource provider will (re)assign the resources to the cluster in need.  From the users' perspective, nothing really changes, except that the overloaded cluster is now feeling better.  Let's get into a little more detail.  A Little More Detail  The resource provider is the heart and brain of SDM.  It's job is to keep track of services and resources and adjust resource assignments as needed.  At the level of the resource provider, everything is very abstract.  It doesn't know (or care) what any of its managed services do, as long as they implement the required interface.  It also doesn't care about the details of the resources its managing, beyond the fact that there are details, and that the services it's managing may care about those details.  One other abstract concept that the resource provider understands is a  need .  When a service managed by the resource provider needs more resources, it tells the resource provider about its need.  That need is expressed as a description of the desired resources to satisfy the need (including quantity), and how important the need is.  For example, a managed service might say to the resource provider, &amp;quot;Hey! I want two OpenSolaris x86 resources with at least 4GB memory each.  This need is critical to me continuing to service my users!&amp;quot;  To satisfy this request, the resource provider will look around at the other services it's managing to see who could potentially give up the requested resources.  Among the other services there might be  spare pools  (basically just holding tanks for idle resources), cloud service providers (e.g.  Amazon EC2 ), or other services.  If the requested resources are free, they will be reassigned to the requesting service.  With a spare pool, the decision is easy: any resources in the spare pool are fair game.  Same for the cloud.  With other services, though, it's not so simple.  In general, if a service is still holding a resource, that's because it's still using it to some degree.  How do we know when it's OK to take a resource away from a service?  Well, the resource provider has a set of policies that govern the relative importance of the services.  Using those policies, the resource provider will decide if the importance of the requesting service plus the criticality of its need outweighs the importance of the potential donor service and how much it's using the resources in question.  If, in the end, there are no resources that can reasonably be reassigned to the needy cluster, then the request stays pending and will be reevaluated again later.  On the service side of things there is a  service adapter .  The job of the service adapter is to be the shim between the service itself and the resource provider.  It implements that abstracted service interface that the resource provider expects and translates those abstract concepts we just talked about into concrete artifacts understood by the service.  In particular, it's up to the service adapter to define and implement the SLOs for the service.  Why?  Well, consider this use case.  Imagine you have a cluster of application servers and a Sun Grid Engine cluster, and you want to share resources between them.  The service level criteria will be very different between them, and it wouldn't make any sense to expect the service provider to understand them all.  Instead, it's more flexible and more scalable to allow the service adapters to manage the SLOs and only report the results (e.g. needs) to the resource provider.  Let's use the Sun Grid Engine adapter to illustrate how a service adapter works.  Starting with 6.2, the Sun Grid Engine qmaster includes a JMX interface known as JGDI.  (While JGDI is openly accessible, we don't really advertise it because it's not really abstract enough for public consumption.)  The Sun Grid Engine service adapter uses the JGDI interface to monitor the state of the qmaster.  The service adapter implements one unique policy: maximum number of pending jobs.  (It actually inherits a couple other policies from the service adapter SDK that are universally applicable, such as the minimum number of resources that should be assigned.)  When the state of the cluster changes, the qmaster sends an event to the service adapter.  The service adapter then checks the new cluster state against the SLOs that have been configured to see if any SLO has been violated.  If an SLO has been violated, the SLO configuration specifies what kind of resource is needed to address the issue.  For example, suppose there's an SLO that states that there should never be more than 100 pending Solaris x86 jobs.  If the service adapter finds out that the 101st Solaris job is pending, it will appeal to resource provider and request an additional Solaris x86 resource.  When the resource provider assigns a resource to the service, the service adapter is responsible for prepping the resource and adding it into the service.  Now, here's the interesting part.  After the new resource takes on its share of the workload and the service is happy again, we don't take the resource away.  The resource stays with the service until someone else needs it more.  Resources are shared, not leased.  It is possible to configure SDM to behave in a fashion that is in effect leasing, but it's something you have to explicitly set up.  On the other side of the coin, when the resource provider is asked for a resource, it talks to the service adapters for the managed services to find out who has something that can be borrowed.  The resource provider keeps a map of where all the resources are assigned, so it can immediately tell which services are currently holding resources that are candidates for reassignment.  It then contacts those services' service adapters to find out whether the resources are in use.  The service adapter's job is to look at the service and place a numerical value of how well the resources are being used by the service.  Once the resource provider has collected the usage values for all the candidate resources, it applies policies (such as relative importance of the services) and picks the resources that seem most available.  This process applies equally to services, spare pools\*, and cloud service providers.  (\* There is a built-in spare pool in the resource provider that doesn't actually have its own service adapter, but it works as though it did.)  With the 6.2u5 release, we have two service adapter implementations.  One is for the Sun Grid Engine software itself.  The other is a generic cloud adapter that comes with integration scripts for use with Amazon EC2 and for use with IPMI power management.  Out of the box, you can use SDM to manage Sun Grid Engine clusters and to resource those clusters on demand from EC2.  You can also configure a spare pool\* that powers down idle or underutilized machines.  (\* It's not technically a spare pool, but it behaves like one.)  The intention is to add additional service adapter implementations as we uncover the concrete demand for them.  In addition, the original plan was to make the service adapter API clean, public, and well-documented.  So far, it's fairly clean, fairly well documented, but only public in so far as the Hedeby Project is open source.  If you have interest in seeing or (even better) developing a service adapter for a particular service, please do let us know, and we'll see what we can do to help.  Hopefully this overview gives you a pretty good idea of what SDM does and at least an inkling of how it does it.  If not, let me know!<br/><br/>0 Vote(s) ]]></description>
</item>

</channel>
</rss>

