Ver el post completo:http://www.sharepointpromag.com/content1/topic/sharepoint-2010-misconfigurations-141636/catpath/sharepoint
Mistake #1: Scrimping on SharePoint's RAM or Hard Disk Space
Virtualization itself isn't bad, but it must be done intelligently and without sacrificing SharePoint's ability to do its job.
If SharePoint finds itself starved for RAM, it starts shutting off functionality so that it can fit into the available space. It also caches less in the web application pools and recycles those pools more often. Less caching and more recycles result in a degraded end-user experience, as SharePoint must compile the same ASP.NET code over and over. And no one likes unhappy users, not even their mothers.
The solution to this particular issue is easy: Add RAM.
Mistake #2: Using Virtualized Microsoft SQL Server
Virtualization isn't bad. But virtualization allows administrators to make mistakes on a much grander scale. Take virtualizing SQL Server. Everything in SharePoint is stored in SQL Server, if SQL Server is slow, SharePoint is slow.
The obvious solution is to move SQL Server to a physical box.
Mistake #3: Using the Farm Configuration Wizard
All the databases that the wizard creates have nasty globally unique identifiers (GUIDs) at the end of their names. The wizard also creates a content web app, at http://servername, that just doesn't scale well. To add insult to injury, the wizard creates your My Site host on that same web app, at http://servername/my. Finally, the wizard encourages you to create service applications that you might not actually use.
Mistake #4: Using an Incorrect URL when Creating a Content Web App
SharePoint doesn't tell IIS about changes that you might make to a web app after it is created. For instance, if you create an Alternate Access Mapping (AAM) for a web app in Central Administration, you still need to go into IIS and add the host header for the new address.
Mistake #5: Running Web Apps or Service Apps in Separate App Pools
Web apps and service applications run inside of an application pool, which is a W3WP.exe process that runs on your server. Unless you have reason to do otherwise, you should run all SharePoint web apps inside one application pool; the same goes the service applications. Running each web app in its own application pool makes inefficient use of the server's memory. Each application pool has a minimum overhead of more than 100MB, and its memory footprint increases as it caches content that is frequently rendered. multiple application pools mean that the same content is cached multiple times.
For service applications, this problem is easy to fix. First, make sure that you have a good service application pool to use. I recommend calling this pool Default SharePoint Service App Pool so that it floats to the top of all your drop-down lists. Use a dedicated sp_serviceapps account for the pool's identity. Most service applications allow you to assign them to a new service application pool by modifying their properties in Central Administration. If the option is unavailable there, look for it in PowerShell.
Mistake #6: Using One Account for Everything
if you use one dedicated account for SharePoint, you leave yourself vulnerable to attack. If that account is compromised via a security exploit, the bad guys will have access to everything in SharePoint.
To fix this mistake, start by creating the accounts that I outline in this blog post . Add the sp_webapps and sp_serviceapps accounts as managed accounts.
Mistake # 7: Keeping Default SharePoint Database Settings
When SharePoint creates its multitudes of databases, it makes some bad assumptions. Take the autogrow settings: The database files grow by 1MB at a chunk, almost ensuring that they're going to autogrow with every upload. Not only does this slow down SQL Server (which slows down SharePoint), but it also results in database files that are spread all over your drives in itty-bitty 1MB chunks.
SharePoint also creates most of its databases, notably the Config and Content databases, with the recovery model set to Full. Although this is great if you want to recover data, you must manage the process correctly or those sneaky .ldf files will slowly, methodically fill your hard disk. If you think users get upset when SharePoint is slow because of fragmented databases, you should see how angry they get when SharePoint stops completely because the SQL Server drives are full.
To fix this mistake, set your databases' autogrow settings in such a way that they don't need to grow frequently. For most farms, I recommend changing the 1MB autogrow to something like 500MB or 1GB. Autogrow should also be a last resort. Someone, either the SharePoint administrator or a dedicated DBA, should pregrow your databases so that autogrow is unnecessary.
Your recovery model setting needs to be consistent with your disaster recovery plans. If you need your transaction logs, make sure you're performing routine log backups to keep those .ldf files in check. If you don't need your transaction logs, then consider switching your databases to the simple recovery model. Doing so will keep your .ldf files from swelling up like a nasty bee sting.
Mistake #8: Not Enabling BLOB Caching
Enable BLOB caching, of course! BLOB caching is actually a function of IIS; SharePoint just takes advantage of it. Therefore, to enable BLOB caching requires a change to each web app's web.config file on each server. Fortunately, the setting already exists and just needs to be enabled. By default, the web.config files are in a directory under C:\inetpub\wwwroot\wss\virtualdirectories\. Each web app has a directory and a web.config file. Open one of these files and look for the following line:
<BlobCache location="C:\blobcache\14" path="\.(gif|jpg|jpeg|jpe|jfif|bmp|dib|tif|tiff|ico|png|wdp|hdp|css|js|asf|avi|flv|m4v|mov|mp3|mp4|mpeg|mpg|rm|rmvb|wma|wmv)$" maxSize="10" enabled="false" />
To enable BLOB caching, replace "false" with "true" and save the web.config file. You should also move the file to a directory on a drive other than the C drive. The maxSize parameter is measured in gigabytes, with a default of 10GB. If the space is available, you might want to increase this size.
If editing this file in Notepad on all your servers isn't your idea of fun, you can use PowerShell to automate the process. You still need to perform the process on each server, but using PowerShell is quicker and reduces the chances of a mistake. To begin, download the script and save it to a file named blobcache.ps1. This script contains two functions: Enable-SPBlobCache and Disable-SPBlobCache. Each function takes a web app from the pipeline and enables or disables BLOB caching on that app. The code to enable BLOB caching on each web application in the farm looks like this:
PS E:\Install\Scripts> . .\blobcache.ps1
PS E:\Install\Scripts> Get-SPWebApplication | Enable-SPBlobCache
Mistake #9: Not Installing a PDF iFilter
Mistake #10: Not Pointing Your SharePoint Servers at Themselves
make sure that every server in the SharePoint farm points to itself for all web apps. If I get sporadic reports about SharePoint not responding
Pointing your Search indexer at itself has another advantage: It improves performance for your end users. If you don't point your Search server at itself, then when it starts to perform a crawl, it lets DNS do its work and then starts crawling whichever web front end DNS points it to.
There is a simple fix for this mistake: Open the hosts file (C:\windows\system32\drivers\etc\hosts) on each SharePoint box, and add all the URLs that SharePoint knows about. Point those URLs to 127.0.0.1, which translates to "this computer."
This approach provides all the benefits that I've mentioned but uncovers a nasty beast: loopback detection. This monster, as well as how to defeat it, is scary and too long for this article, but you can read all about it in my blog post "Can’t crawl web apps you KNOW you should be able to crawl."
Fuente:
No hay comentarios:
Publicar un comentario