Right now got an APP and WFE server with a SQL server (SQLA)  - the farm has an SQL alias towards the SQL server

The company have a lot of site collections and these are divided into 12 different content sources  

The creation of a site takes approx +50 sec. while the Search crawl is running  - if I stop all the crawls it only takes 10 sec.

So I'm wondering:

 if I build a new SQL server (SQLB) - delete the current SSA on the farm - build a new SSA but point it towards the new SQLB - and that way isolate all crawl SQL i/O to use SQLB server  - that would reduce the SQL load on SQLA - correct? 

Any problems in doing this ? 

Hi,

this falls under capacity planning and management, what is the amount of data you are crawling and number of items.

what are the specs of each server?

Around 1 tb data is crawled - in 7 ContentDB's and 12 content sources and 1 external content source (not currently running)  

Both the App server and the SQLA server has 8 cores (hyper-v) and 32Gb memory and is isolate on one hyper-v host (96GB memory total) 

• Edited by JmATK Monday, February 16, 2015 1:44 PM

Around 1 tb data is crawled - in 7 ContentDB's and 12 content sources and 1 external content source (not currently running)  

Both the App server and the SQLA server has 8 cores (hyper-v) and 32Gb memory and is isolate on one hyper-v host (96GB memory total) 

• Edited by JmATK Monday, February 16, 2015 1:44 PM

this is small search farm,

check those links for proposed topology

https://technet.microsoft.com/en-us/library/dn342836.aspx

u will need to scale out the servers

Yes - I know the links - another thread is stating that a Separate Search farm is "overkill"... 

https://social.msdn.microsoft.com/Forums/en-US/eb815cf1-e2d5-47b3-b953-1ff263e29b74/dedicated-search-farm?forum=sharepointsearch 

So before going into a dedicated search farm I would try the separate and do the SSA approach...will this not work?

i didn't say to go for a dedicated search farm, I said you need to scale out, add servers on the same farm for the search, for SQL you can 1 server for content and other to host the services DBs.

I don't think creating new SQL would help as you mentioned that it takes time only when the crawl is performed so when the crawl is performed check the CPU utilization of the server,Memory consumption and when you stop the crawl check the same. It seems like there aren't enough resources available on your server so you may have to boost RAM and increase cores of the server.

The APP server utilize 100% CPU - so I'll Increase the resources on the APP server and not on the SQL server? 

If that's the bottleneck then that's where to add more resources.

Of course by increasing the CPU available there you'll put more pressure on other parts of the farm such as the SQL box, possibly to the point where they become the bottleneck.

Yes and as this is SP 2013 you can also scale your search by adding multiple crawl component to load balance the load however if your concern is only about the consumption of time when you create site coll during crawl then try below:-

Stop the central administratio service from the app server and host it only on WFE server.

• Edited by switch2sharepoint Monday, February 16, 2015 3:35 PM

Yes and as this is SP 2013 you can also scale your search by adding multiple crawl component to load balance the load however if your concern is only about the consumption of time when you create site coll during crawl then try below:-

Stop the central administratio service from the app server and host it only on WFE server.

• Edited by switch2sharepoint Monday, February 16, 2015 3:35 PM

Can't add crawl componet to the WFE ... the search won't provision to that server... but that's another story

It's ordinary sites that takes a long time to create - not the sitecollection..

• Edited by JmATK Monday, February 16, 2015 3:47 PM

Can't add crawl componet to the WFE ... the search won't provision to that server... but that's another story

It's ordinary sites that takes a long time to create - not the sitecollection..

• Edited by JmATK Monday, February 16, 2015 3:47 PM

If it is sub-sites then do no provision CA on WFE.

Do we have problem as in when we are crawling http://contoso and creating sub-site on http://contoso? 

yes - and the APP server has a host file entry to crawl itself so it doesn't hit the WFE....  

Open SP management shell>Get-SPServer | select address , id

Go to the database of the concerned site collection>Dbo.timerlock

Make a note of the ID of the server who is processing timer job

If it is App server who is processing timerjob for this DB then turn off the timer service for 15 minutes and check again ( Assuming you have timer service turned on on WFE ) till the timerlock reflects WFE server and once that is done check the behavior.

• Marked as answer by JmATK Wednesday, March 04, 2015 5:02 AM

Open SP management shell>Get-SPServer | select address , id

Go to the database of the concerned site collection>Dbo.timerlock

Make a note of the ID of the server who is processing timer job

If it is App server who is processing timerjob for this DB then turn off the timer service for 15 minutes and check again ( Assuming you have timer service turned on on WFE ) till the timerlock reflects WFE server and once that is done check the behavior.

• Marked as answer by JmATK Wednesday, March 04, 2015 5:02 AM

The "preferred server for timer jobs"  (in CA -> contentdb is not set...

Should I set this to be the APP server?  

You can set it to WFE for the above test or leave it as it is.

I've paused this "troubleshooting" as I'm building a new farm...

But it just stroke my mind - the Managed Property Sizes has been adjusted - but how big is this factor in the overall performance?