Forum Discussion

Kevin_Stewart's avatar
Kevin_Stewart
Icon for Employee rankEmployee
Mar 12, 2014

Okay, so based on what we now know (please correct me if I'm wrong):

 

  1. You don't have OneConnect enabled, so it's likely not a keep-alive persistent connection thing.

     

  2. When it fails you can actually get to SharePoint, but the page doesn't completely load. This would presume no lack of network connectivity at least between the F5 and the SharePoint server.

     

  3. A restart of the app pool clears it up. Perhaps splitting hairs here but do you mean a complete service restart or recycling an app pool (subtle but different things). Recycling would just be creating and swapping out worker processes, but a service reset would be destroying all of the existing state, connections, and threads.

     

  4. When it fails you can ping the SQL server. Does ping also go through the F5 gateway?

     

  5. When it fails you can RDP to the SharePoint server and see IIS logs for the failed attempts. Are there any other clues in the logs about what is going on? Have you considered running a set of performance monitors to observe the app pools/IIS throughout the day to see if memory or thread count is steadily increasing? Does the Windows event log give you any additional detail? How about the SQL server itself, does it log anything?

     

We almost have to assume that it's not so much a connectivity issue between the F5 and web server, because you never technically lose that, but perhaps a lack of connectivity to something SharePoint needs to function. At the point of failure, SharePoint is struggling to either keep up with current threads, or unable to access some external resource that it needs. Let's then also assume for the moment that it is a connectivity issue, and that we have several connections that are potentially suspect:

 

  1. Client to F5 (web)
  2. F5 to SharePoint (web)
  3. SharePoint to F5 gateway (to SQL server)
  4. F5 gateway to SQL server

While it's working, try to tcpdump on these individual connections so that you know what it looks like. Then when it fails, tcpdump again to see if any patterns emerge. So for example, if we suspect SQL connectivity problems, you might see SharePoint trying to get to SQL around the proxy, failing to get through the proxy, or SQL not returning responses. Are there any other off-box dependencies for this SharePoint instance?