Limit | Maximum value | Limit type | Notes |
Alerts
|
100,000 per Search service application
|
Supported
|
This is the limit for a Search service application with a mix of end user queries (75%) and alert queries (25%). The limit for a Search service application with only alert queries is 400,000 alerts. These limits are based on a system with five queries per second (QPS).
|
Analytics processing components
|
6 per Search service application; 1 per server
|
Threshold
|
|
Analytics reporting database
|
4 per Search service application
|
Threshold
|
Add an analytics reporting database when the size of any of the deployed analytics databases reaches 250 GB. This way repartitioning is as balanced as possible.
|
Authoritative pages
|
1 top level and minimal second and third level pages per Search service application
|
Supported
|
Use as few second- and third-level pages as possible while still achieving the desired relevance.
The boundary is 200 authoritative pages per relevance level per Search service application. If you add additional pages, you may not achieve the desired relevance. Add the key site to the first relevance level. Add more key sites at either second or third relevance levels, one at a time. Evaluate relevance after each addition to ensure that you have achieved the desired relevance effect.
|
Concurrent crawls
|
20 per Search service application
|
Threshold
|
|
Content processing components
|
1 per server
|
Supported
|
The topology supports scaling out the number of Content processing components. Although a specific physical host or virtual machine does support multiple Content processing components, you achieve better usage of the CPU capacity by using one Content processing component. The reason is that a built-in mechanism maximizes CPU usage by adjusting the number of feeding sessions in accordance with available CPU cores. Multiple feeding sessions allow the Content processing component to process incoming documents in parallel. This mechanism assumes a single Content processing component per host.
If the number of physical cores on the host equals N, then the Content processing component will have N*K feeding sessions. K is a constant coefficient with the initial value 3. A 4-core server will have 12 feeding sessions, which means that the Content processing component can process 12 documents in parallel. You can change the value of K by setting theNumberOfCssFeedersPerCPUForRegularCrawl property of the Search Service Application. SharePoint 2013 limits the value of N upwards to 12, even if a server has more than 12 physical cores. Therefore a 16-core server will have N*K = 12 * 3 = 36 feeding sessions.
In the case that there still is idle CPU time, consider increasing the K coefficient instead of adding an extra Content processing component. If you increase the K coefficient, you must ensure that the host has sufficient available memory.
|
Content sources
|
50 per Search service application
|
Supported
|
|
Crawl components
|
2 per Search service application;1 per server
|
Supported
|
|
Crawl databases
|
5 per Search service application
|
Boundary
|
|
Crawl impact rule
|
No limit
|
Supported
|
|
Crawl log entries
|
100 million per Search service application
|
Supported
|
|
Crawl rules
|
No limit
|
Supported
|
|
Crawled properties
|
500,000 per Search service application
|
Supported
|
The contents and metadata of the items that you crawl are represented as crawled properties. You can map these crawled properties to managed properties. When the number of crawled properties exceeds this supported limit, indexing speed will be reduced.
|
Default eDiscovery query MaxRowLimit
|
10,000 rows
|
Supported
|
This is the default maximum row limit for eDiscovery queries. The Search service application property MaxRowLimit defines the maximum value of the eDiscovery query property RowLimit. RowLimit defines the number of rows each page contains in a result set.
|
Default query MaxRowLimit
|
500 rows
|
Supported
|
This is the default maximum row limit for queries. The Search service application property MaxRowLimit defines the maximum value of the query property RowLimit. RowLimit defines the number of rows each page contains in a result set.
|
Index components
|
60 per Search service application; 1 per server
|
Supported
|
To calculate the number of index components you have, multiply the number of index partitions with the number of index replicas.
|
Index partitions
|
20 per Search service application
|
Supported
|
An index partition holds a subset of the Search service application index. Increasing the number of index partitions results in each partition holding a smaller subset of the index, reducing the RAM and disk space that is needed on the servers hosting the index components.
|
Index replicas
|
3 per index partition
|
Supported
|
Each index partition can have a set of replica. If you increase the number of index replicas, this will have a positive effect on the query performance and it provides better fault tolerance. However, if you add too many replicas to your index partition, this can have a negative effect on indexing.
For Internet sites scenarios, which typically have a high query rate but low content volume (less than 4 million items per partition), the supported limit is 6 index replicas per partition.
|
Indexed items
|
100 million per Search service application
10 million per index partition
|
Supported
|
Each index partition contains a subset of the entire search index. If the number of indexed items is high in relation to the amount of memory the server has, this will affect the query response time negatively.
|
Indexed managed property size
|
512 KB per searchable/queryable managed property
|
Threshold
|
This is the default limit for the size of a searchable or queryable managed property. If you increase this limit, you will enable indexing of more data per managed property. Indexing more data per managed property uses more disk space and increases the overall load on the system. You can configure this limit by using Windows PowerShell cmdlets and the schema object model to set the MP.MaxCharactersInPropertyStoreIndex attribute.
|
Length of machine host name
|
15 characters
|
Threshold
|
NetBIOS limits the maximum machine host name length to this value.
|
Link database
|
2 per Search service application
|
Threshold
|
Each link database can contain up to 50 million items.
|
Managed properties
|
50,000 per Search service application
|
Supported
|
Search uses managed propertied in queries. Crawled properties are mapped to managed properties. When you exceed the supported limit for managed properties, this reduces indexing speed.
|
Managed property mappings
|
100 per managed property
|
Supported
|
Crawled properties can be mapped to managed properties. Exceeding this limit may decrease crawl speed and query performance.
|
Maximum allowed KeywordQuery text length
|
20 KB
|
Boundary
|
The Keyword Query Language is a language for building search queries. This is the boundary limit for the Search service application properties MaxKeywordQueryTextLength and DiscoveryMaxKeywordQueryTextLength. These properties define the maximum query text length for keyword queries and eDiscovery keyword queries.
|
Maximum allowed query MaxRowLimit
|
100,000 rows
|
Boundary
|
This is the boundary limit for the Search service application properties MaxRowLimit and DiscoveryMaxRowLimit. These properties define the maximum value of the query property RowLimit for queries and eDiscovery queries. RowLimit defines the number of rows each page contains in a result set.
|
Maximum eDiscovery KeywordQuery text length
|
16 KB
|
Supported
|
The Keyword Query Language is a language for building search queries. This is the supported default limit for the Search service application property DiscoveryMaxKeywordQueryTextLength. This property defines the maximum query text length of an eDiscovery keyword query.
|
Maximum KeywordQuery text length
|
4 KB
|
Supported
|
The Keyword Query Language is a language for building search queries. This is the supported default limit for the Search service application property MaxKeywordQueryTextLength. This property defines the maximum query text length of a keyword query.
|
Maximum size of documents pulled down by crawler
|
64 MB (3 MB for Excel documents)
|
Boundary
|
|
Metadata properties recognized
|
10,000 per crawled item
|
Supported
|
This is the number of metadata properties that can be determined and potentially mapped or used for queries when an item is crawled.
|
Navigable results from search
|
100,000 per query request per Search service application
|
Boundary
|
This is the limit for how many hits that a query requests. Increasing this limit will affect the query performance negatively.
|
Number of entries in a custom entity extraction dictionary
|
1 million
|
Supported
|
This is the tested limit.
|
Number of entries in a custom search dictionary
|
5,000 terms per tenant
|
Boundary
|
This limits the number of terms allowed for inclusions and exclusions dictionaries for query spelling correction and company extraction.
|
Number of entries in a thesaurus
|
1 million
|
Supported
|
This is the tested limit.
|
Query processing components
|
1 per server
|
Supported
|
SharePoint only supports one query processing component per physical machine or virtual machine.
|
Ranking models
|
1,000 per tenant
|
Boundary
|
Approaching this limit can have negative effect on the overall system performance.
|
Results removal
|
No limit
|
Threshold
|
|
Retrievable managed property size
|
16 KB per managed property
|
Threshold
|
This is the default maximum limit for the size of a retrievable managed property. Increasing this limit will enable indexing of more data per managed property. It will also enable retrieval of more data per managed property with the search results. Indexing and retrieving more data per managed property increases the overall load on the system and uses more disk space. You can configure this limit per managed property by using Windows PowerShell cmdlets and the schema object model to set the P.MaxCharactersInPropertyStoreForRetrievalattribute.
|
Search service applications
|
20 per farm
|
Supported
|
Multiple Search service applications can be deployed on the same farm, because you can assign search components and databases to separate servers. This limit is lower than the limit for the total number of service applications in a farm.
|
Sortable and refinable managed property size
|
16 KB per managed property
|
Boundary
|
This is the default maximum limit for the size of a sortable and refinable managed property. Increasing this limit will enable indexing of more data per managed property. This uses more disk space and increases the overall load on the system. You can configure this limit per managed property by using Windows PowerShell cmdlets and the schema object model to set theMP.MaxCharactersInPropertyStoreForRetrieval attribute.
|
Start addresses
|
100 per content source
|
Supported
|
|
Term size
|
300 characters
|
Boundary
|
SharePoint Search will split terms that are longer than this boundary into two or more terms where no term has more than 300 characters. For example, a 612-character term will be split into two 300-character terms and one 12-character term. SharePoint Search only considers the first 1000 characters of a term for splitting, it ignores any remaining characters.
|
Unique contexts used for ranking
|
15 unique contexts per rank model
|
Boundary
|
This is the maximum boundary for the number of unique contexts per rank model.
|
Unique terms in the index
|
2^31 (>2 billion terms)
|
Boundary
|
This is the maximum boundary for the number of unique terms that can exist in the index of a Search service application.
|
User defined full text indexes
|
10
|
Boundary
|
This is the maximum boundary for the number of full text indexes.
|
Values per managed property
|
100
|
Supported
|
A managed property can have multiple values of the same type. This is the supported number of values per managed multi-valued managed property per document. Exceeding this limit may have a negative effect on query performance, index disk size and/or memory usage.
|