Joel Oleson's Blog - SharePoint Land

Why WSS 3.0 x64 and MOSS 2007 x64... What's the deal?

Well the MOSS 2007 x64 downloads are available via MSDN and MVLS.  On MSDN, the ISO contains both x86 and x64.  The WSS x64 is on download center. Just last week I think I was asked when to use x64 over x86 at least 3-4 times.  First off, there is no difference as far as features go.  The feature set is exactly the same.  The install is not different, just the fact that you should have already installed Windows Server 2003 x64 and the x64 of the .Net Framework 3.0 (X64 Redist Package). I did a post on why upgrade to SQL 2005 when it began to be supported with WSS 2.0 SP2 and SPS 2003 SP2.

One forum post in reference to Windows 2003 x64 suggests... 64-Bit is the future. Its more secure because all Kernel level drivers have to be signed.
 

The next topic that comes up around x64 is the mixed environment.  What about backend x64 SQL Servers and x86 SharePoint Servers.  Totally ok.  Mixed environments?  Like an x64 Excel Server or x64 Index Server... again, totally ok.

So now that I've explained that it's a flexible server environment, the question still remains.  When do I use x64?  Let me break this down...  First let me say that in relation to SharePoint this is my opinion and based on my own experience and perceptions, not official testing, which is why I have this posting on my personal blog.  There are links to some good info such as in the "Benefits of Windows x64 editions."

Let me start with the obvious.  x64 is about addressing memory beyond the 32 bit memory space.  There is overhead to the larger address tables.  I'll discuss this in relation to the application.  Small medium customers leveraging newer existing x86 servers (as in last year or 2), not worth it to purchase new if you can reallocate.  There is overhead in x64 and things will be slightly slower (not noticable) if you were to compare the same system with x86 and x64.  If you aren't going to use it... period, then it will simply be overhead.

As far as servers go, I'd say, SQL first, then Excel (if used), WFEs, Index, then Query as far as order of RAM consumption goes.

SQL Servers - SQL loves CPU, it loves Memory, and now you need to watch Disk I/O on your Search and SSP databases.  With SQL x64 will help you scale out to support more databases and provide the ability to have more MTL memory.  The upload space in SQL in x86 is tight.  For large uploads on servers with 2GB, you may run into "out of memory" errors in your SQL error log.  If you do see this, you can add memory.  In the SPS 2003 with SQL 2000 in MS IT we use to add the -g512 to the startup parameters add additional MTL.  With SQL 2005 and x64 with 4GB, 8GB etc... we haven't had to use the -g switch.  In SharePoint using SQL I've found the 4GB SQL was the sweet spot for x86 systems.  This SQL guy, Slava Ok, King of x64 and SQL memory managment, seems to agree.  Now with x64 the number of connections that SQL can handle goes way up!  The number of transactions the server can support goes way up as well.  SQL is more of a no brainer for x64 if you are trying to scale.  Here's my recommendation...  If you expect to store more than 5GB go with SQL Server.  If you plan to support more than 5000 users I'd seriously recommend the x64.  With low usage systems you may not see the ROI, but you may find the cost is minimal.  If you're looking for an improvement or greater difference in end user performance on a system that isn't using more than 3GB you won't see it.  There was a performance test done with SPS 2003 to compare SQL 2000 and SQL 2005 on x64 systems.  Not very eventful.  My conclusion from this, it's a memory thing, not an end user performance thing.  Hitting pages, and navigating the site even under some load isn't going to show much of a difference.  Not until you surpass where 32 bit can't address the memory are you going to see x64 pick up and continue to scale.  That's when you want to be running x64.  SQL does have some good resources on scalability with 64 bit platform.  Great article on "When and Why should I move to 64-bit computing with SQL 2005?"

Excel Application Server - The Excel services are mostly about CPU.  I really don't have a lot to say here, but usually this role is on the WFE which if these services are being used will add to the stack.  With more in memory, the computation can be more efficient than if there is high paging resulting in disk contention.  If you've offloaded the Excel servers onto their own servers, the x64 will allow for further scale.  If you've decided it's worth investing in servers for these processes you're likely to consider that it will continue to scale with x64.

WFE - Web Front End & WFE/Query & the All in One - Web Front Ends are a really key scenario for x64.  The top scenarios are blob caching, additional RAM for worker processes.  Worker processes love memory.  If you're trying to provide memory for one or more of your SSP app pool worker process, and one or more content app pool worker process, and any additional services that may be running.  My mantra has been 800 MB per worker process max memory.  With the new SSP w3wp.exe you now have a few more services running and consuming RAM.  Even if you are a medium business, but want to push the single box to provide as much as it can, the x64 will benefit you.  8GB of RAM on a WFE compared to a 4GB WFE isn't something I've done much work with in the lab, but based on anecdotal evidence, you can get more out of that same box.  More as in your worker processes will continue to scale without hitting limits.  In a 4GB system the OS and worker processes do start to contend for memory with just 2-3 worker processes.  With the out of the box worker processes, the mssearch.exe, and the excel services on a utilized system you're going to be pushing the 4GB.  Increasing the RAM to 8GB and changing to x64 will allow the system to scale and provide a bunch more overhead.  I'm not sure if it's 25% more overhead just by adding RAM, but that's my current... guess.  In a small environment, a dev virtual server, less than a 100 users 2GB and x86 should be fine.  Want to do much more than that and I'd recommend 4GB x86 to 500 users.  Want an intranet to support 10-25K users go to 4GB and seriously consider a second WFE.  Want to hit the internet and do blob caching and support 50K on a box look at 8GB (my opinion).

Index Server and Index/WFE - Index servers love CPU, they also love to create lots of connections.  Disk I/O is another thing to look at as your indexing is occuring, the number of connections to SQL is.  Addressing the additional memory on the Index server will support more connections and allow hold more in memory processing.  The MSSearch service is what you'll see consuming CPU and RAM.  CPU is most important on the Index server, but the additional memory will help on efficiency and reduce Disk I/O to the swap file. Again 4GB on an Index box is 90% of the time going to be sufficient, but if you're looking to reduce crawl times you may find that the ability to put more in memory which will ultimately be faster.  I can't tell you how much, but you will see the Index server is a work horse, and increasing the threads will reduce crawl times.  You may consider making the Index Server a WFE as well, in this case, the RAM will go to good use and you will see crawl times go down significantly/noticeably.

<Update>What about Indexing with PDF Ifilters?  Yes, this is a critical question.  It is true that today Adobe does not have a 64 bit Ifilter.  Here's a link to an Adobe support article for 64 bit for Adobe 8 and Adobe 7. 

Article: 333360

"Support policy for Adobe Acrobat in Windows XP x64 and Windows Server 2003 x64

Adobe Acrobat 8.0 were not developed for the Windows XP x64 or Windows 2003 Server x64 operating systems running on a 64-bit processor machine. Adobe Acrobat 8.0 was developed for Windows 2000 SP4, XP Professional, Home Edition, or Tablet PC Edition.

If you use Adobe Acrobat 8.0 in Windows XP x64 or Windows Server 2003 x64, Adobe Technical Support can assist you with Adobe Acrobat 8.0 features and with issues that also occur in supported operating systems. Any unique issues found to occur when you run Adobe Acrobat 8.0 on a 64-bit environment will be reported to Adobe development teams for consideration in a future release. " 

"Can't open PDF within Internet Explorer 64-bit version.

Internet Explorer 64-bit and 32-bit versions are both bundled with Windows XP 64-bit and Windows Server 2003 x64 systems.  Adobe Acrobat 8.0 and Acrobat 3D can open PDF files inside the browser window only if you use the 32-bit version of Internet Explorer. Acrobat installs a 32-bit ActiveX control (pdf.ocx) that enables Acrobat to open PDF files within Internet Explorer; the 64-bit version of Internet Explorer 6 does not support 32-bit ActiveX controls. "

FoxIT has released a 64 bit IFilter for PDF - (Thanks Sammy) Download the FREE x32 Bit here and Download the FREE x64 Bit here.  I haven't heard of anyone sharing their success stories yet.  I'm anxious to hear.  More detail on the FoxITReader here: http://www.foxitsoftware.com/foxitreader.  Remember the Ifilters are installed on the Index Server in the case of MOSS and on the WFE (which would have Search and Index components in 99.9% of cases) in the case of WSS 3.0.  "Foxit Reader runs on Windows 95/98/NT/2000/XP/2003. It is provided by Foxit Software Company for free non-commercial use. This product is provided AS IS without any explicit or implicit warranty. Please see the End User License Agreement."  There is a user license, not sure how it would apply for an index server.  Again I haven't heard of this working, so I'm interested to hear.  This is the best reference to configuring the Ifilter for WSS 3.0 that I've come across.  I've heard it simply works with MOSS, but WSS needed a bit of tweaking, that article appears to do the trick.  According to the comments it works for RTM as well.

This Ifilter blog post has some great comments look at "Why can't I use a 32 bit PDF filter with 64 Bit Sharepoint Server?"  Someone recently asked if they could have an x86 Index server until there is a x64 PDF Ifilter.  Sure.  That should work.  Otherwise, you could wait on your indexing of Adobe PDFs.  It does appear that either they or fox is working on it.  Looking for steps on adding the Ifilter?  I came across this which related to the B2TR config and has a comment about x64.  I really liked this post on config great tidbits.

http://www.foxitsoftware.com/pdf/others/ifilter/ 

According to Foxit, they do support Microsoft's "Search Engine" technologies including Portal Server and WSS.

Overview
Foxit PDF IFilter is designed to help users to index a large amount of PDF documents and then quickly find text within these documents. The PDF documents can be files, email attachments or database records.

Foxit PDF IFilter supports following Microsoft products: Windows Indexing Service, MSN Desktop Search, Internet Information Server, SharePoint Portal Server, Windows SharePoint Services (WSS), Site Server, Exchange Server, SQL Server and all other products based on Microsoft Search technology. Hereafter, we use term "search engine" to refer to these products.

Installation Instructions

Follow the steps below to install the Foxit PDF IFilter.

• 1. Download PDF IFilter.
• 2. Stop all appropriate clients.
• 3. Uninstall any previous version of Foxit PDF IFilter.
• 4. Double-click the downloaded file and follow the on-screen instructions.
• 5. After the installation completes, start all appropriate clients.
• 6. (SharePoint only) Add PDF as a file type to be included in the content index.
• 7. Re-index your system with the appropriate clients.

Add Notes Indexing to this list.  From what I understand there is no x64 Notes client and that this is required for indexing Notes content.

</Update> 

Query Server - I have a tough time justifying dedicated query servers with the new awesome contiuous replication feature.  Before it was the network load that was more of a concern.  Query servers from what I've seen don't use that much memory.  If you are getting enough search requests to justify their own query servers to offload those requests, then if you anticipate using the memory, then the system can leverage it.  Basically in my experience, these are the quietest servers in the farm.  If I'm trying to save on costs, this is where I put 2GB where I put 4GB on all the other servers in the farm.  Beyond what more you can put in memory, I don't see a lot of benefit.  It's good for consistency if everything else is x64.

x64 Trial of Microsoft Office SharePoint Server 2007 (English)

x64 Trial of Microsoft Office SharePoint Server 2007 (24 Languages) 

SharePoint Server 2007 Language Pack (x64) (8 Languages and more coming... Thai, Korean, Japanese, Hindi, Hebrew, Arabic, Chinese Simplified and Traditional)

x64 version of Windows SharePoint Services 3.0 (31 Languages)

Windows SharePoint Services 3.0 Language Pack x64 = SharePointLanguagePack.exe