configuration cache clearing sharepoint 2019 step by step

in this post we will discuss how configuration cache clearing sharepoint 2019 is done in on-premise environment step by step. clearing configuration cache involves below steps

  • Stop the sharepoint “SharePoint Timer Service (SPTimerV4)” “.
  • Delete all files of type “XML Document” from “Config” folder.
  • Take Back up of file “cache.ini” file.
  • Edit the value present in the file “cache.ini” and save.
  • Restart timer job “SharePoint Timer Service (SPTimerV4)“.
Advertisements

Stop timer job service SharePoint Timer Service (SPTimerV4)

first you need to stop the timer job service “sharepoint timer serivce (SPTimerV4)“. You can stop the timer service either directly opeining from services or you can use powershell command to stop sharepoiint timer service job.

Open “Run” from windows server or click button “Windows + R” to open “Run“.

how to open services.msc from windows server 2019
open services.msc
Advertisements

identifty the timer job “SharePoint Timer Service (SPTimerV4)“. Right click on the timer job, click on “Stop“.

how to stop services sharepoint timer services SPTimerV4 during configuration cache clearing
stop services sharepoint timer services
Advertisements

you can stop timer job “SharePoint Timer Service (SPTimerV4)” using powershell command as well. Open sharepoint timer services preoperties.

sharepoint timer services preoperties
sharepoint timer services preoperties
Advertisements

Open “Windows Powershell ISE” as an administrator and enter the command below to stop services.

Stop-Service -Name SPTimerV4
stop-service using powershell
stop-service using powershell
Advertisements

Navigate to sharepoint configuration cache location “C:\ProgramData\Microsoft\SharePoint\Config“. There will be one folder under which cache files will be there. click on that folder as per the screenshot below.

sharepoint configuration cache location
Advertisements

Delete all “XML Document” files present in that folder except “cache.ini“.

delete configuration cache files sharepoint during configuration cache clearing sharepoint 2019
Delete configuration cache files (XML Document)
Advertisements

Open the file “cache.ini” and edit value to “1” and “Save” the file.

edit the vluse present under file cache
Edit the vluse present under file cache
Advertisements

Restart the timer job now which will recreate the cache files. Run the below command so as to start sharepoint timer service.

Start-Service -Name SPTimerV4
start-service
start-service
Advertisements

Cache files will be recreated in the folder “Cache”.

configuration cache clearing
configuration cache created again
Advertisements

Configuration Cache Clearing SharePoint 2019 | #SharePoint, #SharePoint2019, #ConfigCache

Configuration Cache Clearing SharePoint 2019 | #SharePoint, #SharePoint2019, #ConfigCache
Advertisements

Monitor cache performance SharePoint 2016

SharePoint Server 2016 provides three types of caches that help improve the speed at which web pages load in the browser: the BLOB cache, the ASP.NET output cache, and the object cache.

The BLOB cache is a disk-based cache that stores binary large object files that are used by web pages to help the pages load quickly in the browser.

The ASP.NET output cache stores the rendered output of a page. It also stores different versions of the cached page, based on the permissions of the users who are requesting the page.

The object cache reduces the traffic between the web server and the SQL database by storing objects such as lists and libraries, site settings, and page layouts in memory on the front-end web server. As a result, the pages that require these items can be rendered quickly, increasing the speed with which pages are delivered to the client browser.

The monitors measure cache hits, cache misses, cache compactions, and cache flushes. The following list describes each of these performance monitors.

A cache hit occurs when the cache receives a request for an object whose data is already stored in the cache. A high number of cache hits indicates good performance and a good end-user experience.

A cache miss occurs when the cache receives a request for an object whose data is not already stored in the cache. A high number of cache misses might indicate poor performance and a slower end-user experience.

Cache compaction (also known as trimming), happens when a cache becomes full and additional requests for non-cached content are received. During compaction, the system identifies a subset of the contents in the cache to remove, and removes them. Typically these contents are not requested as frequently.

Compaction can consume a significant portion of the server’s resources. This can affect both server performance and the end-user experience. Therefore, compaction should be avoided. You can decrease the occurrence of compaction by increasing the size of the cache. Compaction usually happens if the cache size is decreased. Compaction of the object cache does not consume as many resources as the compaction of the BLOB cache.

A cache flush is when the cache is completely emptied. After the cache is flushed, the cache hit to cache miss ratio will be almost zero. Then, as users request content and the cache is filled up, that ratio increases and eventually reaches an optimal level. A consistently high number for this counter might indicate a problem with the farm, such as constantly changing library metadata schemas.

You can monitor the effectiveness of the cache settings to make sure that the end-users are getting the best experience possible. Optimum performance occurs when the ratio of cache hits to cache misses is high and when compactions and flushes only rarely occur. If the monitors do not indicate these conditions, you can improve performance by changing the cache settings.

The following sections provide specific information for monitoring each kind of cache.

Monitoring BLOB cache performance:

monitor-blob-cache

Note:
For the BLOB cache, a request is only counted as a cache miss if the user requests a file whose extension is configured to be cached. For example, if the cache is enabled to cache .jpg files only, and the cache gets a request for a .gif file, that request is not counted as a cache miss.

Monitoring ASP.NET output cache performance :

monitoring-asp-net-output-cache-performance

Note:
For the ASP.NET output cache, all pages are cached for a fixed duration that is independent of user actions. Therefore, there are flush-related monitoring events.

Monitoring object cache performance :

The object cache is used to store metadata about sites, libraries, lists, list items, and documents that are used by features such as site navigation and the Content Query Web Part.

This cache helps users when they browse to pages that use these features because the data that they require is stored or retrieved directly from the object cache instead of from the content database.

The object cache is stored in the RAM of each web server in the farm. Each web server maintains its own object cache.

You can monitor the effectiveness of the cache settings by using the performance monitors that are listed in the following table.

monitoring-object-cache-performance

Tips Tricks Distributed Cache Service SharePoint2013

If you, like me, are playing with SharePoint 2013 or if you have plans to migrate/deploy SharePoint 2013, you may have already heard about Distributed Cache (a.k.a. Velocity or AppFabric).  In this post, I’d like to make you aware of some tips from the field that may help you avoid some serious issues in your production Farm.

First things first, see the following articles to learn about planning and managing Distributed Cache on SharePoint 2013:

Plan for feeds and the Distributed Cache service in SharePoint Server 2013

Manage the Distributed Cache service in SharePoint Server 2013

As you know, real world scenarios are always different and more challenging than TechNet “ideal world” and some tips that we noted from Premier support cases are really valuable:

  • When you run Configuration Wizard on SharePoint 2013 (a.k.a. psconfig), Distributed Cache service is enabled by default on that server.  If you run the wizard on all SharePoint servers in the Farm, the service will be running on all those servers which is not the ideal configuration for your production environment.  To avoid this problem, configure your servers via PowerShell instead of the wizard.  After the first Farm server is configured, you can use connect-spconfigurationdatabase with –skipregisterasdistributedcachehost parameter.
  • Plan to have a dedicated server or servers run only the Distributed Cache service.  Avoid sharing that server(s) with any other service, even Central Administration, because Distributed Cache needs special considerations with respect to resources and maintenance activities.
  • Recommended resources for dedicated servers are:
    • 4 cores processor
    • 24 GB RAM (8-16 GB dedicated for Distributed Cache)
    • 1 Gbps network interface
    • Physical and Virtual environments are supported, however on virtual environments dynamic memory is not supported
  • Distributed Cache must be configured manually to use dedicated resources, so please run the following actions during the Farm Configuration process before starting the User Profile Service:
    1. Stop Distributed Cache service on all servers running it, wait on each one until the service stops
      Stop-SPDistributedCacheServiceInstance –Graceful
      (the graceful parameter helps to move cache on that server to another available server)
    2. Then run cmdlet:
      Update-SPDistributedCacheSize –CacheSizeinMB <size in MB>
      Remember to use between 8 GB and 16 GB (16 GB used on real world scenarios with 24 GB RAM on server).
    3. Restart the service on all dedicated servers from Central Administration –> Services on the server
  • If you need to run a maintenance window or remove a server from the Cache Cluster (name used to identify all dedicated servers to Distributed Cache service) then you need stop and remove the service as follows:
    1. Stop the service using the following cmdlet
      Stop-SPDistributedCacheServiceInstance –Graceful
      on the server to be removed or on all dedicated servers (a.k.a. Cache Hosts)
      TIP: If you need Distributed Cache to always be available then leave the service running on one server.
    2. Run the following cmdlet on all the servers except the one left running for availability:
      Remove-SPDistributedCacheServiceInstance
      If all servers have the service stopped then leave one without running this cmdlet, which will be your first server to restart.
    3. When your maintenance is over, go to Central Administration and start Distributed Cache service from Services on Server page, then wait until service is listed as “started.”
    4. Finally go to each Cache Host and run cmdlet:
      Add-SPDistributedCacheServiceInstance
    5. To verify everything is ok, run the following cmdlets from any Cache Host to see if all Cache Hosts are listed and service status is “UP”:
      Use-CacheCluster
      Get-CacheHost
  • Never stop the AppFabric service from the Services applet in Windows or restart servers running AppFabric without gracefully stopping the Distributed Cache service.
  • The Distributed Cache service is based on AppFabric, which is a prerequisite when you install SharePoint 2013.  AppFabric has its own administration via PowerShell and developers can use it to deploy new features, however direct management and development on AppFabric in a SharePoint Farm is not supported.  If you have issues with AppFabric or Distributed Cache then get support from Microsoft, do not use the AppFabric management directly.  If you want to develop new features, use a dedicated AppFabric environment outside the SharePoint Farm.
  • AppFabric has his own updates, so SharePoint Administrators must be aware of those updates and their interaction with SharePoint Farm.  Follow the AppFabric Team Blog to learn more about it.