none
SharePoint Server 2010 - Search Service Application - Scopes - SlowQuery RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    auf unserem SharePoint Server 2010 (Windows Server 2008 R2 Standard) haben wir folgendes Problem.

    Rufe ich den "Scopes" Bereich auf ("Central Administration" - "Manage Service applications" - "Search Service Application" - "Scopes"), lädt der Server ein paar Minuten bis die Seite erscheint. Die einzige Erklärung, die ich dafür habe ist, dass die Crawl Log DB mittlerweile sehr groß geworden ist (ca. 88 GB). Aber eigentlich dürfte das doch keine ungewöhnliche Größe für ein SharePoint Server sein oder irre ich mich da?

    Im SP Log finde ich dann folgende Einträge:

    09/25/2012 15:26:56.00  
    OWSTIMER.EXE (0x1274)                    
    0x15E8 SharePoint Server              
    Database                       
    fa43 High     
    Slow Query Duration: 83326.3557239817 

    09/25/2012 15:26:56.00  
    OWSTIMER.EXE (0x1274)                    
    0x15E8 SharePoint Server              
    Database                       
    fa44 High     
    Slow Query StackTrace-Managed:    at Microsoft.Office.Server.Data.SqlSession.OnPostExecuteCommand(SqlCommand command, SqlQueryData monitoringData)    
    at Microsoft.Office.Server.Data.SqlSession.ExecuteNonQuery(SqlCommand command)    
    at Microsoft.Office.Server.Search.Administration.CrawlLogReport.ProcessCommandsOnStore(SqlSession storeSession, SqlCommand[] cmds)    
    at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)    
    at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)    
    at System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.ThreadPoolCallBack(Object o)    
    at System.Threading.ExecutionContext.runTryCode(Object userData)
    at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)    
    at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)    
    at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)    
    at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)   

    09/25/2012 15:26:56.00  
    OWSTIMER.EXE (0x1274)                    
    0x15E8 SharePoint Server              
    Database                       
    tzku High     
    ConnectionString: 'Data Source=server;Initial Catalog=Search_Service_Application_CrawlStoreDB_20d0a2e750f24d1fb02b0c9b39dbe1eb;Integrated Security=True;Enlist=False;Asynchronous Processing=False;Connect Timeout=15'   
    ConnectionState: Open ConnectionTimeout: 15 

    09/25/2012 15:26:56.00  
    OWSTIMER.EXE (0x1274)                    
    0x15E8 SharePoint Server              
    Database                       
    tzkv High     
    SqlCommand: 'dbo.proc_MSS_CrawlReportUpdateItems'    
    CommandType: StoredProcedure CommandTimeout: 0    
    Parameter: '@timepoint'
    Type: DateTime
    Size: 0
    Direction: Input
    Value: '09/25/2012 13:25:27' 

    09/25/2012 15:26:56.01  
    OWSTIMER.EXE (0x1274)                    
    0x0C90 SharePoint Server Search       
    Administration                 
    dmd1 Medium   
    SetStringProperty: Changing property 'LastCrawlReportProccessed' from '09/25/2012 13:20:27' to '09/25/2012 13:25:27'. 3723eb1f-8032-4766-8bb4-8a5824c3f989

    09/25/2012 15:26:56.01  
    OWSTIMER.EXE (0x1274)                    
    0x0C90 SharePoint Server Search       
    Administration                 
    dj5b High     
    CrawlLogReport.ProccessLogReport() - Done for time:      00:01:28.7924720 3723eb1f-8032-4766-8bb4-8a5824c3f989

    09/25/2012 15:26:56.01  
    OWSTIMER.EXE (0x1274)                    
    0x0C90 SharePoint Server Search       
    Administration                 
    dj5o High     
    CrawlReportTimerJob finished for SearchApplication 'Search Service Application'. 3723eb1f-8032-4766-8bb4-8a5824c3f989

    09/25/2012 15:26:56.02  
    OWSTIMER.EXE (0x1274)                    
    0x0C90 SharePoint Foundation          
    Monitoring                     
    b4ly High     
    Leaving Monitored Scope (Timer Job Crawl Log Report for Search Application b91cd924-50d8-46fc-bd41-6dbcc226c2fc.).
    Execution Time=88805.541486418 3723eb1f-8032-4766-8bb4-8a5824c3f989

    Kann mir dort jemand einen Ansatz liefern, wie ich dieses Verhalten des SharePoint Servers wieder normalisieren kann?

    Vielen Dank im Voraus.

    Dennis Nxxxxx

    Dienstag, 25. September 2012 14:23
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Dennis,

    88 GB sind schon eine Menge. Welche größe hat denn die Content DB die gecrawlt wird?
    Unsere Content Datenbank ist jetzt fast 4,5 GB groß. Die Suchdatenbank wurde 20 GB auber auch nur weil die LUN des Datenbankservers voll war. Sonst wäre die Datenbank sicherlich noch mehr angewachsen. Ich kenn die interne Crawlsuche von Sharepoint leider nicht. Aber bei 4,5 GB kann doch die SuchDB nicht über 20 GB groß werden normalerweise. Der Crawl ist dann auch irgendwie gegen die Wand gelaufen von einen auf den anderen Tag.

    Da ich auch zu keiner Lösung (leider) gekommen bin habe ich den Index einfach gelöscht und die Suche derzeit deaktiviert! :(
    Also im Prinzip habe ich fast das gleiche Problem wie du!

    Gruß
    Daniel

    Mittwoch, 26. September 2012 09:24
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Daniel,

    die Content DB, die gecrawlt wird ist ca. 10 GB groß.

    Mir ist noch aufgefallen, dass es nicht der SQL Server ist, der zu stark unter Last steht, sondern der SharePoint Server, der fast die ganze Zeit über einer CPU Last von 100% hat. Das verursacht die mssdmn.exe, die mehrfach gestartet ist. Ich habe bereits recherchiert, dass dies wohl auch mit dem Crawler zusammenhängt. Ob das aber der Grund ist, kann ich nicht sagen.

    Mittwoch, 26. September 2012 13:49
    |
  • Question
    Anmelden
    0
    Anmelden

    Zumindest kann ich mittlerweile die mssdmn.exe als Grund ausschließen. Auch bei niedriger CPU Last, lädt der Scopes Bereich sehr langsam.

    Wir suchen weiter...

    Montag, 1. Oktober 2012 13:35
    |
  • Question
    Anmelden
    0
    Anmelden

    Wir haben mittlerweile noch etwas versucht, was aber leider auch nicht den gewünschten Effekt gebracht hat.

    Aber vielleicht hilft es dem ein oder anderen ja:

    Es gibt seit dem CU April 2011 eine neue PowerShell Einstellung für die Search Service Application:

    CrawlLogCleanUpIntervalInDays

    Hier ein Beispiel, um diese Einstellung zu setzen. Auch nachzulesen auf https://gavinmckay.wordpress.com/2011/01/25/sharepoint-2010-content-source-loading-very-slow-in-central-admin-website/

    1. Run the following to get a list of the search service application Ids.

    Get-SPServiceApplication | Where {$_.TypeName -eq "Search Service Application"}

    2. Run the following command to get the Search Service Application Object. Replace the Id with the Id of your search application that was output in the previous PowerShell command.

    $searchApp = Get-SPServiceApplication | Where {$_.Id -eq "<your content service application id>"}

    3. Set CrawlLogCleanUpIntervalInDays to 10

    $searchApp.CrawlLogCleanUpIntervalInDays = 10
$searchApp.Update()
    Donnerstag, 4. Oktober 2012 08:04
    |