PostgreSQL ทำการคอมมิชชันช้า


9

เรากำลังประสบปัญหาบางอย่างกับการกำหนดค่า PostgreSQL หลังจากการวัดประสิทธิภาพบางอย่างฉันพบว่าการสืบค้นที่ง่ายมากใช้เวลาค่อนข้างนานเมื่อทำการตรวจสอบอย่างละเอียดยิ่งขึ้นดูเหมือนว่าคำสั่ง COMMIT ที่แท้จริงนั้นช้ามาก

ฉันทดสอบง่ายมากโดยใช้ตารางต่อไปนี้:

CREATE TABLE test (
    id serial primary key,
    foo varchar(16),
);

หลังจากเปิดการบันทึกในทุกงบฉันใช้แบบสอบถามต่อไปนี้ 10,000 ครั้ง:

BEGIN;
INSERT INTO test (a) VALUES ('bar');
COMMIT;

BEGIN และ INSERT กำลังใช้เวลา <1 มิลลิวินาทีในการดำเนินการให้เสร็จสมบูรณ์ แต่ COMMIT ใช้เวลาเฉลี่ย 22 มิลลิวินาทีในการดำเนินการให้เสร็จสมบูรณ์

ใช้มาตรฐานเดียวกันบนพีซีของฉันเองซึ่งช้ากว่ามากทำให้ค่าเฉลี่ยเดียวกันสำหรับคำสั่ง BEGIN และ INSERT แต่ COMMIT เฉลี่ยอยู่ที่ประมาณ 0.4ms (เร็วกว่า 20 เท่า)

หลังจากอ่านเสร็จฉันก็ลองใช้pg_test_fsyncเครื่องมือเพื่อลองแก้ปัญหา บนเซิร์ฟเวอร์ฉันได้รับผลลัพธ์เหล่านี้:

$ ./pg_test_fsync -o 1024
1024 operations per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
        open_datasync                      14.875 ops/sec
        fdatasync                          11.920 ops/sec
        fsync                              30.524 ops/sec
        fsync_writethrough                            n/a
        open_sync                          30.425 ops/sec

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
        open_datasync                      19.956 ops/sec
        fdatasync                          23.299 ops/sec
        fsync                              21.955 ops/sec
        fsync_writethrough                            n/a
        open_sync                           3.619 ops/sec

Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB
in different write open_sync sizes.)
        16kB open_sync write                5.923 ops/sec
         8kB open_sync writes               3.120 ops/sec
         4kB open_sync writes              10.246 ops/sec
         2kB open_sync writes               1.787 ops/sec
         1kB open_sync writes               0.830 ops/sec

Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written
on a different descriptor.)
        write, fsync, close                34.371 ops/sec
        write, close, fsync                36.527 ops/sec

Non-Sync'ed 8kB writes:
        write                           248302.619 ops/sec

ในพีซีของฉันเองฉันได้รับ:

$ ./pg_test_fsync -o 1024
1024 operations per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
        open_datasync                      69.862 ops/sec
        fdatasync                          68.871 ops/sec
        fsync                              34.593 ops/sec
        fsync_writethrough                            n/a
        open_sync                          26.595 ops/sec

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
        open_datasync                      26.872 ops/sec
        fdatasync                          59.056 ops/sec
        fsync                              34.031 ops/sec
        fsync_writethrough                            n/a
        open_sync                          17.284 ops/sec

Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB
in different write open_sync sizes.)
        16kB open_sync write                7.412 ops/sec
         8kB open_sync writes               3.942 ops/sec
         4kB open_sync writes               8.700 ops/sec
         2kB open_sync writes               4.161 ops/sec
         1kB open_sync writes               1.492 ops/sec

Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written
on a different descriptor.)
        write, fsync, close                35.086 ops/sec
        write, close, fsync                34.043 ops/sec

Non-Sync'ed 8kB writes:
        write                           240544.985 ops/sec

การกำหนดค่าเซิร์ฟเวอร์:

CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
RAM: 32GB
Disk: 2x 2TB SATA disk in Software RAID 1

เครื่องที่ใช้สำหรับการเปรียบเทียบคือ i5 พร้อม RAM ขนาด 16GB และดิสก์ SATA แบบธรรมดา (ไม่ต้องทำการโจมตี)

ข้อมูลเพิ่มเติม:

  • ระบบปฏิบัติการ: เซิร์ฟเวอร์ Ubuntu 12.10
  • เคอร์เนล: Linux ... 3.5.0-22- ทั่วไป # 34-Ubuntu SMP อังคาร 8 มกราคม, 21:47:00 UTC 2013 x86_64 x86_64 x86_64 GNU / Linux
  • ซอฟต์แวร์ RAID 1
  • ระบบไฟล์คือ ext4
  • ไม่ได้ระบุตัวเลือกการเมานท์อื่น ๆ
  • Postgres เวอร์ชัน 9.1
  • Linux mdadm raid

ผลลัพธ์ของ dump2efs:

dumpe2fs 1.42.5 (29-Jul-2012)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          16e30b20-0531-4bcc-877a-818e1f5d5fb2
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              182329344
Block count:              729289039
Reserved block count:     36464451
Free blocks:              609235080
Free inodes:              182228152
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      850
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   256
RAID stride:              1
Flex block group size:    16
Filesystem created:       Sat Jan 19 12:42:19 2013
Last mount time:          Wed Jan 23 16:23:11 2013
Last write time:          Sat Jan 19 12:46:13 2013
Mount count:              8
Maximum mount count:      30
Last checked:             Sat Jan 19 12:42:19 2013
Check interval:           15552000 (6 months)
Next check after:         Thu Jul 18 13:42:19 2013
Lifetime writes:          257 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           128
Journal inode:            8
First orphan inode:       17304375
Default directory hash:   half_md4
Directory Hash Seed:      a71fa518-7696-4a28-bd89-b21c10d4265b
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x000df5a4
Journal start:            31733

Mdadm - เอาต์พุตรายละเอียด:

/dev/md2:
        Version : 1.2
  Creation Time : Sat Jan 19 12:42:05 2013
     Raid Level : raid1
     Array Size : 2917156159 (2782.02 GiB 2987.17 GB)
  Used Dev Size : 2917156159 (2782.02 GiB 2987.17 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Fri Mar 22 11:16:45 2013
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : rescue:2
           UUID : d87b98e7:d584a4ed:5dac7907:ae5639b0
         Events : 38

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       1       8       19        1      active sync   /dev/sdb3

อัปเดต 2013-03-25 : ฉันรันการทดสอบอัจฉริยะทั้งสองบนดิสก์ซึ่งไม่พบปัญหาใด ๆ ดิสก์ทั้งสองมาจาก Seagate รุ่น: ST3000DM001-9YN166

อัปเดต 2013-03-27 : ฉันรัน pg_test_fsync ของเวอร์ชันล่าสุด (9.2.3) บนเครื่องที่ไม่ได้ทำงานอย่างสมบูรณ์:

$ ./pg_test_fsync -s 3
3 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
        open_datasync                      39.650 ops/sec
        fdatasync                          34.283 ops/sec
        fsync                              19.309 ops/sec
        fsync_writethrough                            n/a
        open_sync                          55.271 ops/sec

ก่อนหน้านี้จะดีขึ้นเล็กน้อย แต่ก็ยังน่าเสียดาย พาร์ติชันบนดิสก์ทั้งสองถูกจัดตำแหน่ง:

$ sudo parted /dev/sdb unit s print
Model: ATA ST3000DM001-9YN1 (scsi)
Disk /dev/sdb: 5860533168s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start      End          Size         File system  Name  Flags
 4      2048s      4095s        2048s                           bios_grub
 1      4096s      25169919s    25165824s                       raid
 2      25169920s  26218495s    1048576s                        raid
 3      26218496s  5860533134s  5834314639s                     raid

เอาท์พุทเมา -v:

$ mount -v | grep ^/dev/
/dev/md2 on / type ext4 (rw,noatime)
/dev/md1 on /boot type ext3 (rw)

กำลังใช้อุปกรณ์ md2 สำหรับการทดสอบ กำลังจะทำลายพาร์ทิชันการแลกเปลี่ยนและเรียกใช้ pg_test_fsync ในแต่ละดิสก์

ถ้าฉันรัน pg_test_fsync บนดิสก์ทั้งสองทีละตัวฉันจะได้รับประสิทธิภาพการทำงานที่เหมือนกันพาร์ติชั่นก็ถูกเมาท์ด้วยเวลากลางคืน:

$ pg_test_fsync/pg_test_fsync -s 3

3 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
        open_datasync                      75.111 ops/sec
        fdatasync                          71.925 ops/sec
        fsync                              37.352 ops/sec
        fsync_writethrough                            n/a
        open_sync                          33.746 ops/sec

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
        open_datasync                      38.204 ops/sec
        fdatasync                          49.907 ops/sec
        fsync                              32.126 ops/sec
        fsync_writethrough                            n/a
        open_sync                          13.642 ops/sec

Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB
in different write open_sync sizes.)
         1 * 16kB open_sync write          25.325 ops/sec
         2 *  8kB open_sync writes         12.539 ops/sec
         4 *  4kB open_sync writes          6.207 ops/sec
         8 *  2kB open_sync writes          3.098 ops/sec
        16 *  1kB open_sync writes          1.208 ops/sec

Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written
on a different descriptor.)
        write, fsync, close                27.275 ops/sec
        write, close, fsync                20.561 ops/sec

Non-Sync'ed 8kB writes:
        write                           562902.020 ops/sec

หลังจากรันการทดสอบสองสามครั้งทั้งในอาเรย์และบนดิสก์เดียวตัวเลขดูเหมือนจะแตกต่างกันมาก ประสิทธิภาพที่แย่ที่สุดคือประมาณ 50% ของสิ่งที่ฉันโพสต์ที่นี่ (ประมาณ 30 ops / s สำหรับการทดสอบครั้งแรก) นี่เป็นเรื่องปกติหรือไม่ เครื่องไม่มีการใช้งานอย่างสมบูรณ์ตลอดเวลา

นอกจากนี้ตามเอาต์พุต dmesg คอนโทรลเลอร์อยู่ในโหมด AHCI


คุณสามารถให้รายละเอียดบางอย่างเกี่ยวกับซอฟต์แวร์ RAID ได้หรือไม่ ซอฟต์แวร์อะไร ลินุกซ์mdadmหรือdmraid? มีบางอย่างเฉพาะผู้ขายหรือไม่ อื่น ๆ อีก? เวอร์ชัน PostgreSQL และเวอร์ชัน OS โฮสต์ของคุณก็ช่วยได้เช่นกัน
Craig Ringer

คำตอบ:


6

เซิร์ฟเวอร์นั้นมีfsyncประสิทธิภาพการทำงานที่ช้ามากอย่างไม่น่าเชื่อไม่สามารถบรรยายได้อย่างน่าอัศจรรย์ มีบางอย่างผิดปกติมากในการติดตั้งซอฟต์แวร์ RAID 1 ของคุณ fsyncประสิทธิภาพที่แย่มากเป็นสาเหตุของปัญหาประสิทธิภาพการทำงานของคุณ

fsyncสก์ท็อปเพียงมีช้ามาก

คุณสามารถหลีกเลี่ยงปัญหาประสิทธิภาพการทำงานที่ค่าใช้จ่ายของการสูญเสียข้อมูลบางส่วนหลังจากที่ผิดพลาดโดยการตั้งค่าและการตั้งค่าsynchronous_commit = off commit_delayคุณจริงๆต้องเรียงลำดับจากประสิทธิภาพของดิสก์บนเซิร์ฟเวอร์ แต่ที่ของกราม droppingly ช้า

สำหรับการเปรียบเทียบนี่คือสิ่งที่ฉันได้รับจากแล็ปท็อปของฉัน (i7, 8GB RAM, SSD ขนาดกลาง 128G, pg_test_fsync จาก 9.2):

Compare file sync methods using one 8kB write:

        open_datasync                    4445.744 ops/sec
        fdatasync                        4225.793 ops/sec
        fsync                            2742.679 ops/sec
        fsync_writethrough                            n/a
        open_sync                        2907.265 ops/sec

เป็นที่ยอมรับ SSD นี้อาจไม่ยากต่อการสูญเสียพลังงานที่ปลอดภัย แต่มันก็ไม่เหมือนกับ SSD ที่ประหยัดพลังงานไม่เหมาะสำหรับการใช้งานจำนวนมากเมื่อเราพูดถึงต้นทุนเซิร์ฟเวอร์


1
ใช่ แต่สิ่งที่ทำให้ประสิทธิภาพการทำงานของ fsync ไม่ดี
Blubber

ฉันลองใช้ pg_test_fsync บน SSD ของตัวเองและได้รับตัวเลขประสิทธิภาพเทียบเคียง ฉันรู้ว่าฉันสามารถปิดการใช้งานการซิงค์ได้ แต่คำถามยังคงอยู่สาเหตุของปัญหานี้คืออะไร
Blubber

@Blubber คุณใช้ซอฟต์แวร์ RAID อะไรอยู่? ระบบไฟล์อะไร โฮสต์ระบบปฏิบัติการและรุ่นใด ตัวเลือกการเมาท์ระบบไฟล์ใดบ้าง ทั้งหมดนี้เป็นข้อมูลที่สำคัญหากคุณกำลังค้นหาสาเหตุที่แท้จริง โปรดอัปเดตคำถามของคุณ นอกจากนี้คุณยังควรทำสมาร์ทตรวจสุขภาพบนฮาร์ดไดรฟ์ ( smartctl -d ata -a /dev/sdx|lessและsmartctl -d ata -t long /dev/sdxตามมาด้วยsleep 90mหรือสิ่งที่smartctlจะบอกคุณตามมาด้วยอีก-d ata -aเพื่อให้ได้ผลลัพธ์)
Craig Ringer

@Blubber แม้ว่าคุณจะแก้ไขปัญหา RAID แล้วประสิทธิภาพการทำงานของคุณจะยังคงไม่ดีเท่าที่ควร ดิสก์ 7200RPM แบบเก่า (หรือแย่กว่านั้นคือ 5400RPM) เป็นตัวเลือกที่ไม่ดีสำหรับประสิทธิภาพของฐานข้อมูลโดยเฉพาะอย่างยิ่งหากไม่มีตัวควบคุม RAID ของฮาร์ดแวร์ที่เหมาะสมพร้อมกับแคชแบตเตอรี่สำรองซึ่งทำให้กลุ่มควบคุมขึ้นและเขียนบัฟเฟอร์
Craig Ringer

ฉันได้อัปเดตคำถามพร้อมรายละเอียดเพิ่มเติมเกี่ยวกับระบบไฟล์และการตั้งค่าการโจมตี ฉันเข้าใจว่าเครื่องนี้จะไม่ให้ประสิทธิภาพที่ดีมากในการกำหนดค่าปัจจุบัน แต่ประสิทธิภาพในปัจจุบันคือจริงๆที่ไม่ดี
Blubber

1

นี่เป็นpg_test_fsyncเอาต์พุตบนเซิร์ฟเวอร์ของฉันพร้อมการกำหนดค่าที่คล้ายกันมาก - ซอฟต์แวร์ Linux RAID1 บนดิสก์สำหรับผู้บริโภค 2 ระดับ ( WD10EZEX-00RKKA0):

# ./pg_test_fsync -s 3
Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
        open_datasync                     115.375 ops/sec
        fdatasync                         109.369 ops/sec
        fsync                              27.081 ops/sec
        fsync_writethrough                            n/a
        open_sync                         112.042 ops/sec
...

คุณทดสอบสิ่งนี้บนเซิร์ฟเวอร์ที่ไม่ได้ทำงานอย่างสมบูรณ์ใช่ไหม?


บางทีคุณอาจมีพาร์ติชันที่ไม่ได้จัดแนว ตรวจสอบ:

parted /dev/sda unit s print

นี่คือผลลัพธ์ของเซิร์ฟเวอร์ของฉัน:

Model: ATA WDC WD10EZEX-00R (scsi)
Disk /dev/sda: 1953525168s
Sector size (logical/physical): 512B/4096B
Partition Table: msdos

Number  Start       End          Size         Type     File system     Flags
 1      2048s       67110911s    67108864s    primary  ext4            boot, raid
 2      67110912s   603981823s   536870912s   primary                  raid
 3      603981824s  608176127s   4194304s     primary  linux-swap(v1)
 4      608176128s  1953523711s  1345347584s  primary                  raid

ตรวจสอบว่าแต่ละหมายเลขในStartคอลัมน์หารด้วย 2048 (ซึ่งหมายถึง 1MiB) สำหรับการจัดตำแหน่งที่ดี 4096B หารด้วย 4 จะพอเพียง แต่ยูทิลิตี้ทราบการจัดตำแหน่งเริ่มพาร์ติชันที่ขอบเขต 1MiB


นอกจากนี้คุณอาจใช้ตัวเลือกการเมานต์ที่ไม่ใช่ค่าเริ่มต้นเช่นdata=journalซึ่งมีผลกระทบอย่างมากต่อประสิทธิภาพ แสดงของคุณ: mount -v | grep ^/dev/. นี่เป็นของฉัน:

/dev/md0 on / type ext4 (rw,barrier,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0)
/dev/md2 on /home type ext4 (rw,barrier,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0)
/dev/md1 on /var type ext4 (rw,barrier,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0)

บางทีหนึ่งในดิสก์ของคุณเสีย สร้างพาร์ติชั่นหนึ่งตัวในแต่ละดิสก์โดยไม่มี RAID (บางทีคุณอาจจองพาร์ติชั่นการแลกเปลี่ยนบางส่วนไว้ในดิสก์ทั้งสอง - ใช้สิ่งนี้ - ไม่มีการใช้งาน RAID ในการสลับเลย) สร้างระบบไฟล์ที่นั่นและรันpg_test_fsyncบนไดรฟ์แต่ละตัว - หากมีปัญหาจากนั้นระบบที่ดีจะต้องรอเมื่อทั้งสองถูกทำมิเรอร์


ตรวจสอบว่า BIOS ของคุณถูกตั้งค่าให้ใช้โหมด AHCI แทนโหมด IDE เซิร์ฟเวอร์จะได้รับประโยชน์จากการจัดคิวคำสั่งดั้งเดิมซึ่งไม่สามารถใช้ได้ในโหมด IDE


ละเว้นการเปรียบเทียบกับ SSD มันไร้สาระที่จะเปรียบเทียบ


ฉันวิ่ง bonnie ++ ซึ่งแสดงให้เห็นถึงประสิทธิภาพที่ดี (ดีเท่าที่คุณคาดหวังจากดิสก์ sata ทั่วไป) นอกจากนี้พาร์ติชันจะถูกจัดตำแหน่ง เมื่อฉันรัน pg_test_fsync ในครั้งแรกที่มันเป็นบน VM จากนั้นฉันก็รันมันบนฮาร์ดแวร์จริงหลังจากปิดกระบวนการอื่น ๆ (รวมถึง VM) ประสิทธิภาพดีขึ้นเล็กน้อยประมาณ 40 ops / วินาทีซึ่งยังน่าเสียดาย ฉันจะทำการทดสอบเพิ่มเติมในพาร์ติชันแยกต่างหากถ้าฉันมีเวลาวันนี้ ขอบคุณสำหรับคำแนะนำทั้งหมด.
Blubber

ฉันได้แก้ไขคำถามเดิมของฉันด้วยข้อมูลเพิ่มเติมเกี่ยวกับตัวเลือกการเมาท์และการจัดแนวพาร์ติชัน
Blubber

1

ฉันรู้ว่าฉันอาจจะสายเกินไปที่จะตอบคำถามนี้ ฉันเคยเห็นปัญหาด้านประสิทธิภาพที่คล้ายกันกับ PostgreSQL และ MySQL เมื่อใช้ O_DIRECT ฉันใช้ระบบมาตรฐานขนาดเล็กโดยใช้ iozone พร้อมการซิงค์แบบเขียน (- + r ตัวเลือก) และมีและไม่มีตัวเลือก O_DIRECT (-I) ด้านล่างนี้เป็นคำสั่งสองคำที่ฉันใช้:

iozone -s 2g -r 512k -+r -I -f /mnt/local/iozone_test_file -i 0

และ

iozone -s 2g -r 512k -+r    -f /mnt/local/iozone_test_file -i 0

อันแรกคือ O_SYNC + O_DIRECT ในขณะที่ที่สองคือ O_SYNC เท่านั้น ในครั้งแรกที่ฉันได้รับประมาณ 30MB / วินาทีและครั้งที่สองฉันได้รับประมาณ 220MB / วินาที (ไดรฟ์ SSD) สิ่งที่ฉันค้นพบคือตัวเลือก has_journal บน ext4 ตะเข็บเพื่อทำให้เกิดปัญหา ไม่รู้จริง ๆ ว่าทำไม ...

Filesystem features:      has_journal 

เมื่อฉันเอาตัวเลือกนี้ออกมาสิ่งต่าง ๆ ก็เริ่มทำงานได้ดีทั้งการทดสอบถึงและรักษา 220MB / วินาที ในการถอนตัวเลือกคุณสามารถใช้สิ่งต่อไปนี้:

tune2fs -O ^has_journal /dev/sdX

คุณสามารถให้การทดสอบนั้นและดูว่าการแก้ปัญหาประสิทธิภาพการทำงานของคุณ


1
การปิดใช้งานสมุดบันทึกใน ext3 / 4 ไม่ใช่สิ่งที่ต้องทำโดยไม่ต้องพิจารณาอย่างรอบคอบและมีความเข้าใจที่ดีเกี่ยวกับผลกระทบ
ThatGraemeGuy

2
ฉันไม่เห็นด้วย. DBMS ทำการบันทึกและกู้คืนข้อมูลของตนเองเพื่อให้ความทนทานและอะตอมมิกของธุรกรรม วารสาร FS ไม่มีประโยชน์อย่างสมบูรณ์ในเรื่องนั้น ตราบใดที่ fsync ทำงานอย่างถูกต้องเอฟเฟกต์ของการทำธุรกรรมที่ได้รับมอบหมายสามารถเรียกคืนได้เสมอ
Caetano Sauer
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.