大文件的Windows fsync (FlushFileBuffers)性能

7

根据确保数据在磁盘上的信息(http://winntfs.com/2012/11/29/windows-write-caching-part-2-an-overview-for-application-developers/),即使发生例如停电等情况,似乎在Windows平台上需要依赖其“fsync”版本FlushFileBuffers来获得最佳保证,即缓存实际上从磁盘设备缓存中刷新到存储介质本身。如果这些信息是正确的,则FILE_FLAG_NO_BUFFERINGFILE_FLAG_WRITE_THROUGH的组合不能确保刷新设备缓存,而只对文件系统缓存产生影响。

鉴于我将处理相当大的文件,需要进行“事务性”更新,这意味着在事务提交结束时执行“fsync”。因此,我创建了一个小应用程序来测试执行此操作的性能。它基本上使用8次写入按顺序写入一批8个内存页面大小的随机字节,然后刷新。该批处理在循环中重复,并且每写入一定数量的页面后记录性能。此外,它有两个可配置选项:在刷新时进行fsync以及在开始页面写入之前是否向文件的最后位置写入一个字节。
// Code updated to reflect new results as discussed in answer below.
// 26/Aug/2013: Code updated again to reflect results as discussed in follow up question.
// 28/Aug/2012: Increased file stream buffer to ensure 8 page flushes.
class Program
{
    static void Main(string[] args)
    {
        BenchSequentialWrites(reuseExistingFile:false);
    }
    public static void BenchSequentialWrites(bool reuseExistingFile = false)
    {
        Tuple<string, bool, bool, bool, bool>[] scenarios = new Tuple<string, bool, bool, bool, bool>[]
        {   // output csv, fsync?, fill end?, write through?, mem map?
            Tuple.Create("timing FS-E-B-F.csv", true, false, false, false),
            Tuple.Create("timing NS-E-B-F.csv", false, false, false, false),
            Tuple.Create("timing FS-LB-B-F.csv", true, true, false, false),
            Tuple.Create("timing NS-LB-B-F.csv", false, true, false, false),
            Tuple.Create("timing FS-E-WT-F.csv", true, false, true, false),
            Tuple.Create("timing NS-E-WT-F.csv", false, false, true, false),
            Tuple.Create("timing FS-LB-WT-F.csv", true, true, true, false),
            Tuple.Create("timing NS-LB-WT-F.csv", false, true, true, false),
            Tuple.Create("timing FS-E-B-MM.csv", true, false, false, true),
            Tuple.Create("timing NS-E-B-MM.csv", false, false, false, true),
            Tuple.Create("timing FS-LB-B-MM.csv", true, true, false, true),
            Tuple.Create("timing NS-LB-B-MM.csv", false, true, false, true),
            Tuple.Create("timing FS-E-WT-MM.csv", true, false, true, true),
            Tuple.Create("timing NS-E-WT-MM.csv", false, false, true, true),
            Tuple.Create("timing FS-LB-WT-MM.csv", true, true, true, true),
            Tuple.Create("timing NS-LB-WT-MM.csv", false, true, true, true),
        };
        foreach (var scenario in scenarios)
        {
            Console.WriteLine("{0,-12} {1,-16} {2,-16} {3,-16} {4:F2}", "Total pages", "Interval pages", "Total time", "Interval time", "MB/s");
            CollectGarbage();
            var timingResults = SequentialWriteTest("test.data", !reuseExistingFile, fillEnd: scenario.Item3, nPages: 200 * 1000, fSync: scenario.Item2, writeThrough: scenario.Item4, writeToMemMap: scenario.Item5);
            using (var report = File.CreateText(scenario.Item1))
            {
                report.WriteLine("Total pages,Interval pages,Total bytes,Interval bytes,Total time,Interval time,MB/s");
                foreach (var entry in timingResults)
                {
                    Console.WriteLine("{0,-12} {1,-16} {2,-16} {3,-16} {4:F2}", entry.Item1, entry.Item2, entry.Item5, entry.Item6, entry.Item7);
                    report.WriteLine("{0},{1},{2},{3},{4},{5},{6}", entry.Item1, entry.Item2, entry.Item3, entry.Item4, entry.Item5.TotalSeconds, entry.Item6.TotalSeconds, entry.Item7);
                }
            }
        }
    }

    public unsafe static IEnumerable<Tuple<long, long, long, long, TimeSpan, TimeSpan, double>> SequentialWriteTest(
        string fileName,
        bool createNewFile,
        bool fillEnd,
        long nPages,
        bool fSync = true,
        bool writeThrough = false,
        bool writeToMemMap = false,
        long pageSize = 4096)
    {
        // create or open file and if requested fill in its last byte.
        var fileMode = createNewFile ? FileMode.Create : FileMode.OpenOrCreate;
        using (var tmpFile = new FileStream(fileName, fileMode, FileAccess.ReadWrite, FileShare.ReadWrite, (int)pageSize))
        {
            Console.WriteLine("Opening temp file with mode {0}{1}", fileMode, fillEnd ? " and writing last byte." : ".");
            tmpFile.SetLength(nPages * pageSize);
            if (fillEnd)
            {
                tmpFile.Position = tmpFile.Length - 1;
                tmpFile.WriteByte(1);
                tmpFile.Position = 0;
                tmpFile.Flush(true);
            }
        }
        // Make sure any flushing / activity has completed
        System.Threading.Thread.Sleep(TimeSpan.FromMinutes(1));
        System.Threading.Thread.SpinWait(50); // warm up.

        var buf = new byte[pageSize];
        new Random().NextBytes(buf);
        var ms = new System.IO.MemoryStream(buf);

        var stopwatch = new System.Diagnostics.Stopwatch();
        var timings = new List<Tuple<long, long, long, long, TimeSpan, TimeSpan, double>>();
        var pageTimingInterval = 8 * 2000;
        var prevPages = 0L;
        var prevElapsed = TimeSpan.FromMilliseconds(0);

        // Open file
        const FileOptions NoBuffering = ((FileOptions)0x20000000);
        var options = writeThrough ? (FileOptions.WriteThrough | NoBuffering) : FileOptions.None;
        using (var file = new FileStream(fileName, FileMode.Open, FileAccess.ReadWrite, FileShare.ReadWrite, (int)(16 *pageSize), options))
        {
            stopwatch.Start();
            if (writeToMemMap)
            {
                // write pages through memory map.
                using (var mmf = MemoryMappedFile.CreateFromFile(file, Guid.NewGuid().ToString(), file.Length, MemoryMappedFileAccess.ReadWrite, null, HandleInheritability.None, true))
                using (var accessor = mmf.CreateViewAccessor(0, file.Length, MemoryMappedFileAccess.ReadWrite))
                {
                    byte* base_ptr = null;
                    accessor.SafeMemoryMappedViewHandle.AcquirePointer(ref base_ptr);
                    var offset = 0L;
                    for (long i = 0; i < nPages / 8; i++)
                    {
                        using (var memStream = new UnmanagedMemoryStream(base_ptr + offset, 8 * pageSize, 8 * pageSize, FileAccess.ReadWrite))
                        {
                            for (int j = 0; j < 8; j++)
                            {
                                ms.CopyTo(memStream);
                                ms.Position = 0;
                            }
                        }
                        FlushViewOfFile((IntPtr)(base_ptr + offset), (int)(8 * pageSize));
                        offset += 8 * pageSize;
                        if (fSync)
                            FlushFileBuffers(file.SafeFileHandle);

                        if (((i + 1) * 8) % pageTimingInterval == 0)
                            timings.Add(Report(stopwatch.Elapsed, ref prevElapsed, (i + 1) * 8, ref prevPages, pageSize));
                    }
                    accessor.SafeMemoryMappedViewHandle.ReleasePointer();
                }
            }
            else
            {
                for (long i = 0; i < nPages / 8; i++)
                {
                    for (int j = 0; j < 8; j++)
                    {
                        ms.CopyTo(file);
                        ms.Position = 0;
                    }
                    file.Flush(fSync);
                    if (((i + 1) * 8) % pageTimingInterval == 0)
                        timings.Add(Report(stopwatch.Elapsed, ref prevElapsed, (i + 1) * 8, ref prevPages, pageSize));
                }
            }
        }
        timings.Add(Report(stopwatch.Elapsed, ref prevElapsed, nPages, ref prevPages, pageSize));
        return timings;
    }

    private static Tuple<long, long, long, long, TimeSpan, TimeSpan, double> Report(TimeSpan elapsed, ref TimeSpan prevElapsed, long curPages, ref long prevPages, long pageSize)
    {
        var intervalPages = curPages - prevPages;
        var intervalElapsed = elapsed - prevElapsed;
        var intervalPageSize = intervalPages * pageSize;
        var mbps = (intervalPageSize / (1024.0 * 1024.0)) / intervalElapsed.TotalSeconds;
        prevElapsed = elapsed;
        prevPages = curPages;
        return Tuple.Create(curPages, intervalPages, curPages * pageSize, intervalPageSize, elapsed, intervalElapsed, mbps);
    }

    private static void CollectGarbage()
    {
        GC.Collect();
        GC.WaitForPendingFinalizers();
        System.Threading.Thread.Sleep(200);
        GC.Collect();
        GC.WaitForPendingFinalizers();
        System.Threading.Thread.SpinWait(10);
    }

    [DllImport("kernel32.dll", SetLastError = true)]
    static extern bool FlushViewOfFile(
        IntPtr lpBaseAddress, int dwNumBytesToFlush);

    [DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Auto)]
    static extern bool FlushFileBuffers(SafeFileHandle hFile);
}

我所获得的性能结果(64位Win 7,慢速磁盘)并不令人鼓舞。看起来,“fsync”性能非常依赖于要刷新的文件大小,以至于它占据了时间的主导地位,而不是要刷新的“脏”数据量。下面的图表显示了小型基准应用程序的4个不同设置选项的结果。

Benchmark timing for 4 the scenarios

如您所见,“fsync”的性能随文件大小指数级下降(直到几个GB时真的会停滞不前)。此外,磁盘本身似乎并没有做很多事情(即资源监视器显示其活动时间只有几个百分点左右,而其磁盘队列在大部分时间内都是空闲的)。

我显然预计“fsync”性能要比执行正常的缓冲刷新差得多,但我预计它会更或多或少保持稳定,并且与文件大小无关。如此一来,它似乎表明它不能与单个大型文件组合使用。

是否有人能够提供解释、不同的经验或不同的解决方案,以确保数据在磁盘上,并具有较为恒定、可预测的性能呢?

更新 请参见下面答案中的新信息。

4个回答

5
您的测试结果显示同步运行速度呈指数级下降,因为您每次都重新创建文件。在这种情况下,它不再是纯顺序写入 - 每次写入还会增加文件大小,这需要多次寻找以更新文件系统中的文件元数据。如果您使用预先存在的完全分配的文件运行所有这些作业,则会看到更快的结果,因为没有这些元数据更新会干扰。

我在我的Linux机器上进行了类似的测试。每次重新创建文件时的结果如下:

mmap    direct  last    sync    time
0   0   0   0    0.882293s
0   0   0   1    27.050636s
0   0   1   0    0.832495s
0   0   1   1    26.966625s
0   1   0   0    5.775266s
0   1   0   1    22.063392s
0   1   1   0    5.265739s
0   1   1   1    24.203251s
1   0   0   0    1.031684s
1   0   0   1    28.244678s
1   0   1   0    1.031888s
1   0   1   1    29.540660s
1   1   0   0    1.032883s
1   1   0   1    29.408005s
1   1   1   0    1.035110s
1   1   1   1    28.948555s

使用现有文件的结果(显然,最后一个字节的情况在这里不相关。同时,第一个结果也必须创建文件):
mmap    direct  last    sync    time
0   0   0   0    1.199310s
0   0   0   1    7.858803s
0   0   1   0    0.184925s
0   0   1   1    8.320572s
0   1   0   0    4.047780s
0   1   0   1    4.066993s
0   1   1   0    4.042564s
0   1   1   1    4.307159s
1   0   0   0    3.596712s
1   0   0   1    8.284428s
1   0   1   0    0.242584s
1   0   1   1    8.070947s
1   1   0   0    0.240500s
1   1   0   1    8.213450s
1   1   1   0    0.240922s
1   1   1   1    8.265024s

(请注意,我只使用了10,000个块而不是25,000个块,因此只写入了320MB,使用的是ext2文件系统。我没有更大的ext2fs,我的大文件系统是XFS,它拒绝允许mmap+直接I/O。)
(如果您有兴趣,以下是代码:)
#define _GNU_SOURCE 1

#include <malloc.h>
#include <string.h>
#include <stdlib.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>

#define USE_MMAP    8
#define USE_DIRECT  4
#define USE_LAST    2
#define USE_SYNC    1

#define PAGE    4096
#define CHUNK   (8*PAGE)
#define NCHUNKS 10000
#define STATI   1000

#define FSIZE   (NCHUNKS*CHUNK)

main()
{
    int i, j, fd, rc, stc;
    char *data = valloc(CHUNK);
    char *map, *dst;
    char sfname[8];
    struct timeval start, end, stats[NCHUNKS/STATI+1];
    FILE *sfile;

    printf("mmap\tdirect\tlast\tsync\ttime\n");
    for (i=0; i<16; i++) {
        int oflag = O_CREAT|O_RDWR|O_TRUNC;

        if (i & USE_DIRECT)
            oflag |= O_DIRECT;
        fd = open("dummy", oflag, 0666);
        ftruncate(fd, FSIZE);
        if (i & USE_LAST) {
            lseek(fd, 0, SEEK_END);
            write(fd, data, 1);
            lseek(fd, 0, SEEK_SET);
        }
        if (i & USE_MMAP) {
            map = mmap(NULL, FSIZE, PROT_WRITE, MAP_SHARED, fd, 0);
            if (map == (char *)-1L) {
                perror("mmap");
                exit(1);
            }
            dst = map;
        }
        sprintf(sfname, "%x.csv", i);
        sfile = fopen(sfname, "w");
        stc = 1;
        printf("%d\t%d\t%d\t%d\t",
            (i&USE_MMAP)!=0, (i&USE_DIRECT)!=0, (i&USE_LAST)!=0, i&USE_SYNC);
        fflush(stdout);
        gettimeofday(&start, NULL);
        stats[0] = start;
        for (j = 1; j<=NCHUNKS; j++) {
            if (i & USE_MMAP) {
                memcpy(dst, data, CHUNK);
                if (i & USE_SYNC)
                    msync(dst, CHUNK, MS_SYNC);
                dst += CHUNK;
            } else {
                write(fd, data, CHUNK);
                if (i & USE_SYNC)
                    fdatasync(fd);
            }
            if (!(j % STATI)) {
                gettimeofday(&end, NULL);
                stats[stc++] = end;
            }
        }
        end.tv_usec -= start.tv_usec;
        if (end.tv_usec < 0) {
            end.tv_sec--;
            end.tv_usec += 1000000;
        }
        end.tv_sec -= start.tv_sec;
        printf(" %d.%06ds\n", (int)end.tv_sec, (int)end.tv_usec);
        if (i & USE_MMAP)
            munmap(map, FSIZE);
        close(fd);
        for (j=NCHUNKS/STATI; j>0; j--) {
            stats[j].tv_usec -= stats[j-1].tv_usec;
            if (stats[j].tv_usec < 0) {
                stats[j].tv_sec--;
                stats[j].tv_usec+= 1000000;
            }
            stats[j].tv_sec -= stats[j-1].tv_sec;
        }
        for (j=1; j<=NCHUNKS/STATI; j++)
            fprintf(sfile, "%d\t%d.%06d\n", j*STATI*CHUNK,
                (int)stats[j].tv_sec, (int)stats[j].tv_usec);
        fclose(sfile);
    }
}

谢谢您关注这个问题,霍华德。我会研究这些结果,并使用您提到的预先存在的文件场景重新运行我的测试。但是,由于我怀疑操作系统文件缓存和/或内核分页层可能在性能下降中发挥了重要作用,因此Linux和Windows平台上的结果可能会有所不同。但也许正如您所提到的那样,这与文件元数据更新有关。 - Alex

2
这是我 synctest 代码的 Windows 版本。我只在 VirtualBox 虚拟机中运行过它,所以我没有可供比较的有用数字,但你可以尝试将其与你的机器上的 C# 数字进行比较。我向 CreateFile 传递了 OPEN_ALWAYS,因此它会重用现有文件。如果您想每次使用空文件进行测试,请将该标志更改为 CREATE_ALWAYS。
我注意到一件事情是,第一次运行这个程序时结果要快得多。也许 NTFS 不太擅长覆盖现有数据,并且文件碎片化效应在随后的运行中显示出来。
#include <windows.h>
#include <stdio.h>

#define USE_MMAP    8
#define USE_DIRECT  4
#define USE_LAST    2
#define USE_SYNC    1

#define PAGE    4096
#define CHUNK   (8*PAGE)
#define NCHUNKS 10000
#define STATI   1000

#define FSIZE   (NCHUNKS*CHUNK)

static LARGE_INTEGER cFreq;

int gettimeofday(struct timeval *tv, void *unused)
{
    LARGE_INTEGER count;
    if (!cFreq.QuadPart) {
        QueryPerformanceFrequency(&cFreq);
    }
    QueryPerformanceCounter(&count);
    tv->tv_sec = count.QuadPart / cFreq.QuadPart;
    count.QuadPart %= cFreq.QuadPart;
    count.QuadPart *= 1000000;
    tv->tv_usec = count.QuadPart / cFreq.QuadPart;
    return 0;
}

main()
{
    int i, j, rc, stc;
    HANDLE fd;
    char *data = _aligned_malloc(CHUNK, PAGE);
    char *map, *dst;
    char sfname[8];
    struct timeval start, end, stats[NCHUNKS/STATI+1];
    FILE *sfile;
    DWORD len;

    printf("mmap\tdirect\tlast\tsync\ttime\n");
    for (i=0; i<16; i++) {
        int oflag = FILE_ATTRIBUTE_NORMAL;

        if (i & USE_DIRECT)
            oflag |= FILE_FLAG_NO_BUFFERING|FILE_FLAG_WRITE_THROUGH;
        fd = CreateFile("dummy", GENERIC_READ|GENERIC_WRITE, 0, NULL,
            OPEN_ALWAYS, oflag, NULL);
        SetFilePointer(fd, FSIZE, NULL, FILE_BEGIN);
        SetEndOfFile(fd);
        if (i & USE_LAST)
            WriteFile(fd, data, 1, &len, NULL);
        SetFilePointer(fd, 0, NULL, FILE_BEGIN);
        if (i & USE_MMAP) {
            HANDLE mh;
            mh = CreateFileMapping(fd, NULL, PAGE_READWRITE,
                0, FSIZE, NULL);
            map = MapViewOfFile(mh, FILE_MAP_WRITE, 0, 0,
                FSIZE);
            CloseHandle(mh);
            dst = map;
        }
        sprintf(sfname, "%x.csv", i);
        sfile = fopen(sfname, "w");
        stc = 1;
        printf("%d\t%d\t%d\t%d\t",
            (i&USE_MMAP)!=0, (i&USE_DIRECT)!=0, (i&USE_LAST)!=0, i&USE_SYNC);
        fflush(stdout);
        gettimeofday(&start, NULL);
        stats[0] = start;
        for (j = 1; j<=NCHUNKS; j++) {
            if (i & USE_MMAP) {
                memcpy(dst, data, CHUNK);
                FlushViewOfFile(dst, CHUNK);
                dst += CHUNK;
            } else {
                WriteFile(fd, data, CHUNK, &len, NULL);
            }
            if (i & USE_SYNC)
                FlushFileBuffers(fd);
            if (!(j % STATI)) {
                gettimeofday(&end, NULL);
                stats[stc++] = end;
            }
        }
        end.tv_usec -= start.tv_usec;
        if (end.tv_usec < 0) {
            end.tv_sec--;
            end.tv_usec += 1000000;
        }
        end.tv_sec -= start.tv_sec;
        printf(" %d.%06ds\n", (int)end.tv_sec, (int)end.tv_usec);
        if (i & USE_MMAP)
            UnmapViewOfFile(map);
        CloseHandle(fd);
        for (j=NCHUNKS/STATI; j>0; j--) {
            stats[j].tv_usec -= stats[j-1].tv_usec;
            if (stats[j].tv_usec < 0) {
                stats[j].tv_sec--;
                stats[j].tv_usec+= 1000000;
            }
            stats[j].tv_sec -= stats[j-1].tv_sec;
        }
        for (j=1; j<=NCHUNKS/STATI; j++)
            fprintf(sfile, "%d\t%d.%06d\n", j*STATI*CHUNK,
                (int)stats[j].tv_sec, (int)stats[j].tv_usec);
        fclose(sfile);
    }
}

谢谢Howard,我也会运行它。它可能会为我的重新运行结果提供一些启示,因为我使用了一个完全编写的文件。我正在添加这些问题。您将看到一些未解释和意外的行为仍然存在,而您提供的解释与该测试中观察到的某些性能变化非常吻合。 - Alex

1
我进行了更多的实验和测试,并找到了一个对我来说可能可接受的解决方案(尽管目前我只测试了顺序写入)。在这个过程中,我发现了一些意外的行为,引发了许多新问题。我将发布一个新的SO问题(Explanation/information sought: Windows write I/O performance with "fsync" (FlushFileBuffers))。

我向我的基准测试中添加了以下两个额外选项:

  • 使用未缓存/直写写入(即指定FILE_FLAG_NO_BUFFERINGFILE_FLAG_WRITE_THROUGH标志)
  • 通过内存映射文件间接写入文件。

这为我提供了一些意外的结果,其中之一给我提供了一个或多或少可接受的解决方案。当与未缓存/直写I/O结合使用时,“fsync”不会观察到写入速度呈指数衰减。因此(尽管不是非常快),这为我提供了一种解决方案,允许确保数据在磁盘上,并具有恒定可预测的性能,不受文件大小的影响。

其他一些意外的结果如下:

  • 如果在使用“fsync”和“unbuffered/writethrough”选项执行页面写入之前,将一个字节写入文件的最后位置,则写入吞吐量几乎增加一倍。
  • 使用或不使用“fsync”的无缓冲/直写性能几乎相同,但当一个字节被写入文件的最后位置时除外。空文件上“unbuffered/writethrough”方案无“fsync”的写入吞吐量约为12.5 MB/s,在同样的方案下,文件中最后一个位置写入一个字节后,吞吐量高达37 MB/s,是前者的三倍。
  • 通过与“fsync”结合使用的内存映射文件间接地写入文件,即使在文件上设置了“unbuffered/writethrough”,也会显示出与直接写入文件的缓冲写入一样的指数级吞吐量降低。

我已经在我的原始问题中添加了用于基准测试的更新代码。

下面的图表显示了一些额外的新结果。

Throughput for different combinations of options


0

[错误;请参见评论。]

我认为你引用的文章在陈述FlushFileBuffers对未缓冲I/O有任何有用影响时是不正确的。它提到了一个微软的论文,但该论文并没有做出这样的声明。

根据文档,使用未缓冲I/O具有与在每次写入后调用FlushFileBuffer相同的效果,但更高效。因此,实际解决方案是使用未缓冲I/O而不是使用FlushFileBuffer。

但请注意,使用内存映射文件会破坏缓冲设置。如果您想尽快将数据推送到磁盘上,我不建议使用内存映射文件。


据我所知,该文章是正确的。 这也在例如此处得到确认:http://support.microsoft.com/kb/332023 (请参见“更多信息”部分)。 FlushFileBuffers 将翻译为 SCSI 设备的 SYNCHRONIZE CACHE 命令和 IDE / ATAPI 设备的 FLUSH CACHE 命令。 “Write Through” 被发出为 ForceUnitAccess,而这显然通常不被 IDE / ITAPI 设备接受。 我相信这也是所提到的文章中ftp://ftp.research.microsoft.com/pub/tr/TR-2008-36.pdf 中提到的。 - Alex
@alex 这些文章讨论的是磁盘/控制器内部的缓存,而不是操作系统级别的。当使用写穿透时,它应该已经到达了这个“在磁盘缓存”中,但实际上并没有“在磁盘上”。对于像您的 Q 这样的测试,这个缓存可能会解释随着 IO 体积增长而出现的经验下降。当这些“在磁盘上”的缓存在写入扇区之前在断电情况下失败时,这个缓存对于数据库来说是一个大问题,请参见 http://support.microsoft.com/kb/234656。 - rlb
我在那篇论文中找不到任何关于Win32 API的内容。但是KB文章中肯定有! - Harry Johnston

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接