Two internal full-text search waits share this page: FT_IFTSHC_MUTEX, a thread in a full-text operation synchronising with other full-text workers around fdhost control operations (fdhost.exe is the filter daemon host process that does the actual word-breaking), and FT_IFTS_RWLOCK, synchronisation on the full-text background task queue while removing items from it.
They pair with FT_IFTS_SCHEDULER_IDLE_WAIT (the scheduler idling) to complete the full-text background picture.
Are They a Problem?
No; both are filtered as benign, and neither has been a contention point. Their presence tracks full-text components being installed and mildly active, which describes a great many instances that never consciously use the feature.
Real full-text performance questions, crawl throughput, population lag, query speed, live in catalog properties (FULLTEXTCATALOGPROPERTY), the crawl logs in the instance’s log directory, and fdhost’s resource behaviour, none of which reads through these mutexes.
What To Do
- Filter both in routine analysis.
- For genuine full-text work, check population status and the crawl logs, and stagger indexing versus reorganize operations (see the
FT_MASTER_MERGEpage for the known concurrency issue).
How To See It
Rank waits with Get-WaitStatistics; expect background traces on any instance with full-text installed.
These waits are background noise on a healthy instance. If you are chasing a real problem, start with the waits that actually cost you time.
- The waits that usually matter, ranked, with what each one is telling you.
- Performance & Troubleshooting, the scripts and guides for this part of the stack.
Leave a Reply