SOLUTION: NTASKLDR.EXE consumes high or 100% CPU on >R6.5.3

Hoping this helps others who may have fun with the NTASKLDR.EXE process hogging their CPU . . .

SUMMARY: NTASKLDR.EXE can hog your CPU when trying to build/reindex a View in a local .NSF, when the Views index is very large.

SOLUTION: Remove the local intance of the database and access it from a server (or replace your laptop with a Cray :wink: ).


BACKGROUND:

There are many topics in this forum relating to resource problems with NTASKLDR.EXE and a bunch of ā€˜interesting’ solutions, such as it being essential to have your ID file in your data folder (wrong), cleaning out your NOTES.INI (wrong), it being a problem with IBM Thinkpads (wrong), removing the FT index on database (may help), turning round 3 times and aligning all the ubuntu stickers on your PC to the server room (this will defiitely help :wink: ) etc.

Prior to R6.5.3 there was a bug: Technote 1164456: ā€œNotes 6.x client pages out after 60 seconds of activity and or Ntaskldr.exe spikes CPUā€ (see http://www-01.ibm.com/support/docview.wss?uid=swg21164456 or search for NOTES.INI and DISABLE_TRIMWS=1).

However, you can still have NTASKLDR.EXE ā€˜steal’ your CPU on versions >6.5.3 (or with DISABLE_TRIMWS=1). I just did on 6.5.4 and here is why: Building/updating of large View indexes in a local .NSF and your PC has poor I/O performance.

I had a local replica of an application that has a really knarly View: Deep categorisation that lists the same 1000s of documents in 100s of categories that are sub-categorised and sub-categorised again . . . adding up to a View index of >600MB.

Recently we must have hit a tipping point with the amount of data/categories, because the View index on our server got messed up and thought it was -1.2GB (yes minus!). We fixed the .NSF on the server, but my laptop way dying: NTASKLDR.EXE would kick in after the Notes client has been running for a little while and would then hog my laptop’s CPU/thrash the disk for hours (I left it for 5hrs and it was still going!).

I solved the problem by turning off scheduled background agents, re-starting Notes, then trying to open the troublesome View in the Notes client . . . NLNOTES.EXE kicked in to index the View and my Notes client did not respond for over 3hrs! But it did finally index/open the View and NTASKLDR.EXE then left it alone.

But this is not the solution, because as soon as more data is added to the .NSF, NTASKLDR.EXE will studiously try to update the View’s index. The problem is that its ā€˜background’ operation is far from throttled to low priority/background processing. This is particularly apparent on laptops, as they have poor disk I/O performance.

SOLUTION: Delete the local replica of the .NSF with the large View index. This may not be a solution for some, but it worked for me. I can still access the application from our server/VPN when out & about. Sure I’d like to have a local replica, but without a seriously powerful laptop (= 0 battery life) NTASKLDR.EXE is always going to struggle.

I have not had a chance to test how an 8.5 client responds to indexing the ā€˜knarly’ View, but will post a response back if/when I do.

Hth.