September 12, 2012 at 5:09 pm
Can anybody tell me what the wait type PREEMPTIVE_OS_GETFILEATTRIBUTES is/means?
We are having an issue with our SharePoint/SQL Server setup, specifically around backups.
All backups (SQL-initiated and SharePoint-initiated) are sent to a disk (via UNC) on a backup server. All SQL and SharePoint machines are VMWare virtual machines on ESX 5.
We have been getting an issue where the SharePoint-initiated backups will stall in some way. Symptoms are:
* Unable to RDP to the SQL Server
* Presence of active sessions with the PREEMPTIVE_OS_GETFILEATTRIBUTES wait type
* Subsequent backups to UNC queue up with the same wait state (both SQL- and Sharepoint-initiated)
* Unable to kill the offending SPIDs (message posted in ERRORLOG to say it's done, but that's it)
* SQL Server can be stopped but not started again
In all other respects, SQL Server seems to tick along quite happily. SharePoint can talk to it and it can be managed remotely.
The only fix we have got is to stop SQL Server (from a remote machine) and power cycle the VM.
The disks underpinning the ESX farm are iSCSI. Just recently we have done a revamp of the environment to address known latency issues (although there are still some remaining). The network side of things is idling along nicely. The backup server has its own dedicated disks, separate from the iSCSI disks.
We are pretty sure it is something OS/infrastructure related, but haven't been able to pin it down. If we knew what this wait type was, it would give us a better idea of where to look.
Thanks in advance...
MARCUS. Why dost thou laugh? It fits not with this hour.
TITUS. Why, I have not another tear to shed;
--Titus Andronicus, William Shakespeare
August 7, 2014 at 4:12 pm
Did you ever find a cause for this?
We are seeing the same wait type with one of three nodes in a SQL Server 2012 Availability Group cluster running as guest VM's under Hyper-V. Most interesting is that the PREEMPTIVE_OS_GETFILEATTRIBUTES wait is long only on one of the 3 nodes. We operate our AG cluster active-active-active and backup logs from preferred Secondary servers. Two of the servers consistently experience minimal PREEMPTIVE_OS_GETFILEATTRIBUTES waits when writing backups to a UNC location. One has consistently long waits (30 seconds or more) for each file access.
This wait type extends to executing RESTORE VERIFYONLY commands on the UNC, as well as the use of xp_delete_file to remove old files on the UNC. Each independent OS file operation gets delayed resulting for example in a 10 minute wait to delete 3 old LOG files with xp_delete_file.
Todd Oberman
September 19, 2016 at 4:42 pm
I know it's old thread but I found that there is some 30-65 sec wait/timeout during any backup/restore from UNC path when it's short UNC name. With full FQDN it's working fast.
So better is to use \\server.domain.local\uncpath
October 13, 2016 at 9:01 am
Lukasz H. (9/19/2016)
I know it's old thread but I found that there is some 30-65 sec wait/timeout during any backup/restore from UNC path when it's short UNC name. With full FQDN it's working fast.So better is to use \\server.domain.local\uncpath
This worked for me. I still can't believe the dramatic performance increase from using the FQDN.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply