{"id":11265,"date":"2018-05-24T13:05:35","date_gmt":"2018-05-24T11:05:35","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/"},"modified":"2018-05-24T13:05:35","modified_gmt":"2018-05-24T11:05:35","slug":"postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/","title":{"rendered":"Postgres, the fsync() issue, and ‘pgio’ (the SLOB method for PostgreSQL)"},"content":{"rendered":"

By Franck Pachot<\/h2>\n

.
\nThat’s a long blog post title, which is actually just a good pretext to play with Kevin Closson SLOB method for PostgreSQL: pgio
\nI use the beta version of pgio here. If you want to read more about it, you can start on https:\/\/kevinclosson.net\/2018\/05\/22\/sneak-preview-of-pgio-the-slob-method-for-postgressql-part-i-the-beta-pgio-readme-file\/<\/a>. If you are used to the SLOB for Oracle (https:\/\/kevinclosson.net\/slob\/<\/a>) you will quickly understand the ‘why’ and ‘how’ of pgio.
\n<\/p>\n

PostgreSQL’s fsync() surprise<\/h3>\n

You may have read about the fsync() issue. Postgres, from the beginning, relies a lot on the filesystem buffering to optimize I\/O. So they write() to the data files but fsync() only at checkpoints. This is ok when everything goes well because the writes since the last checkpoints are protected by the Write Ahead Logging, where fsync() occurs for each writes at commit (if you didn’t change the default parameters for WAL). But when a problem occurs, such as power outage, some writes may be lost, or partially lost, and that’s not easy to detect at checkpoint time with fsync(). <\/p>\n

So, basically, there’s a risk of corruption and there are no easy ways to detect it.<\/p>\n

You can read the details from https:\/\/lwn.net\/Articles\/752063\/<\/a> and that’s not the subject of this post.<\/p>\n

Most of the other databases are opening files with O_DSYNC, which means that the write() call will detect the error immediately. And the major ones are doing direct I\/O anyway because they have their own buffer cache and do not need the performance overhead and corruption risk of double buffering.<\/p>\n

Why is this so hard to fix?<\/h3>\n

So why is it so hard to do the same with Postgres? Just because it was not initially designed to optimize I\/O and postgres relied heavily on the OS filesystem for that. The database systems which sync at each write, and which can do direct I\/O, have implemented many optimizations to reduce the overhead of a disk latency at each write. They have their own buffer cache, with a background database writer which re-orders the writes in the optimal way. And they have multiblock writes for large contiguous writes which bypass the buffer cache.<\/p>\n

However, you may have a storage system where write latency is minimal, and you may have an application where the overhead here is not a big problem. This means that you should measure it in order to balance between performance and prevention of corruption. And this is where the SLOB method is awesome: reliable and predictable metrics to measure IOPS.<\/p>\n

pgio to the rescue<\/h3>\n

This is my first trial of pgio, in beta version. It cannot be easier. I’ve just un-tar-ed it:<\/p>\n

\ntar -xvf pgio-0.9.tar\ncd pgio\n<\/code><\/pre>\n
I’ve setup the pgio.conf with 4 schemas and 2 threads per schema:<\/p>\n
\nUPDATE_PCT=10\nRUN_TIME=300\nNUM_SCHEMAS=4\nNUM_THREADS=2\nWORK_UNIT=255\nUPDATE_WORK_UNIT=8\nSCALE=200M\nDBNAME=pgio\nCONNECT_STRING=\"pgio\"\nCREATE_BASE_TABLE=TRUE\n<\/code><\/pre>\n
Because I want to test writes, I’ve set the UPDATE_PCT so that 10% of calls will do an UPDATE. And I kept the default work unit to read 255 blocks and, for those 10% updates, update 8 blocks only. I’ll run that with 2 threads per schemas, which means 8 concurrent sessions. And they will run for 300 seconds.<\/p>\n
In this test I didn’t want to set different values. I just want to see what happens in IOPS for a common workload of lot of reads and small changes. the scale is 200M here. My workload sessions will find their buffers in memory.<\/p>\n
On each test, I’ve created the pgio database:<\/p>\n
\ncreate tablespace pgio location '\/u01\/pgdata';\nCREATE TABLESPACE\ncreate database pgio tablespace pgio;\nCREATE DATABASE\n<\/code><\/pre>\n
Then run the setup.sh to load data in those schemas:<\/p>\n
\nJob info:      Loading 200M scale into 4 schemas as per pgio.conf->NUM_SCHEMAS.\nBatching info: Loading 2 schemas per batch as per pgio.conf->NUM_THREADS.\nBase table loading time: 15 seconds.\nWaiting for batch. Global schema count: 2. Elapsed: 0 seconds.\nWaiting for batch. Global schema count: 3. Elapsed: 103 seconds.\nWaiting for batch. Global schema count: 4. Elapsed: 177 seconds.\nWaiting for batch. Global schema count: 4. Elapsed: 249 seconds.\n \nGroup data loading phase complete.         Elapsed: 249 seconds.\n                      List of relations\n Schema |   Name    | Type  |  Owner   |  Size  | Description\n--------+-----------+-------+----------+--------+-------------\n public | pgio1     | table | postgres | 200 MB |\n public | pgio2     | table | postgres | 200 MB |\n public | pgio3     | table | postgres | 200 MB |\n public | pgio4     | table | postgres | 200 MB |\n public | pgio_base | table | postgres | 29 MB  |\n(5 rows)\n<\/code><\/pre>\n
And then I’m ready to run the runit.sh<\/p>\n
ext4 mount option<\/h3>\n
My tablespace is on an ext4 filesystem:<\/p>\n
\n-bash-4.2$ df -HT \/u01\/pgdata\nFilesystem     Type  Size  Used Avail Use% Mounted on\n\/dev\/sdb       ext4   32G  1.2G   29G   4% \/u01\n<\/code><\/pre>\n
I’ll run the same workload, several times, with changing only one mount option:<\/p>\n
\n       async  All I\/O to the filesystem should be done asynchronously. (See also the sync option.)\n       sync   All I\/O to the filesystem should be done synchronously. In case of media with limited number of write cycles (e.g. some flash drives) \"sync\" may cause life-cycle shortening.\n<\/code><\/pre>\n
Which means that some runs will run with \/u01 mounted as:<\/p>\n
\n\/dev\/sdb on \/u01 type ext4 (rw,nosuid,nodev,relatime,sync,seclabel,data=ordered)\n<\/code><\/pre>\n
and some others will run with the default (async):<\/p>\n
\n\/dev\/sdb on \/u01 type ext4 (rw,nosuid,nodev,relatime,seclabel,data=ordered)\n<\/code><\/pre>\n
I did multiple runs and checked that the result is consistent among them. I’ll show only one result for each configuration.<\/p>\n
Run it with async<\/h3>\n
Here is the output of one ‘runit.sh’ when \/u01 was in async:<\/p>\n
\nDate: Thu May 24 10:56:57 CEST 2018\nDatabase connect string: \"pgio\".\nShared buffers: 128MB.\nTesting 4 schemas with 2 thread(s) accessing 200M (25600 blocks) of each schema.\nRunning iostat, vmstat and mpstat on current host--in background.\nLaunching sessions. 4 schema(s) will be accessed by 2 thread(s) each.\npg_stat_database stats:\n          datname| blks_hit| blks_read|tup_returned|tup_fetched|tup_updated\nBEFORE:  pgio    |   252209 |    118112 |       110420 |        6788 |          18\nAFTER:   pgio    | 25189171 | 136972696 |    159128092 |   147250205 |      573216\nDBNAME:  pgio. 4 schemas, 2 threads(each). Run time: 300 seconds. RIOPS >456181< CACHE_HITS\/s >83123<\n<\/code><\/pre>\n
This shows that, within those 5 minutes, I’ve fetched 147243417 tuples and updated 573198 ones.<\/p>\n
pgio takes snapshots of iostat, vmstat and mpstat. Here is a sample after 1 minute of run where we show that all CPU are busy in user or kernel, but not waiting on I\/O latency:<\/p>\n
\n10:57:51 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle\n10:57:54 AM  all   52.82    0.00   42.22    0.09    0.00    1.11    0.00    0.00    0.00    3.76\n10:57:54 AM    0   54.11    0.00   40.75    0.00    0.00    1.37    0.00    0.00    0.00    3.77\n10:57:54 AM    1   54.42    0.00   40.14    0.34    0.00    1.02    0.00    0.00    0.00    4.08\n10:57:54 AM    2   51.19    0.00   43.34    0.34    0.00    0.68    0.00    0.00    0.00    4.44\n10:57:54 AM    3   51.02    0.00   44.22    0.34    0.00    1.36    0.00    0.00    0.00    3.06\n10:57:54 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle\n10:57:57 AM  all   53.33    0.00   42.15    0.00    0.00    1.02    0.00    0.00    0.00    3.50\n10:57:57 AM    0   53.95    0.00   42.27    0.00    0.00    0.69    0.00    0.00    0.00    3.09\n10:57:57 AM    1   52.56    0.00   42.66    0.00    0.00    0.68    0.00    0.00    0.00    4.10\n10:57:57 AM    2   54.27    0.00   40.27    0.00    0.00    1.37    0.00    0.00    0.00    4.10\n10:57:57 AM    3   52.72    0.00   43.54    0.00    0.00    1.36    0.00    0.00    0.00    2.38\n10:57:57 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle\n10:58:00 AM  all   54.10    0.00   41.54    0.09    0.00    0.77    0.00    0.00    0.00    3.50\n10:58:00 AM    0   55.14    0.00   39.38    0.34    0.00    1.03    0.00    0.00    0.00    4.11\n10:58:00 AM    1   54.95    0.00   40.96    0.00    0.00    0.68    0.00    0.00    0.00    3.41\n10:58:00 AM    2   54.11    0.00   41.10    0.00    0.00    0.68    0.00    0.00    0.00    4.11\n10:58:00 AM    3   52.05    0.00   44.86    0.00    0.00    0.68    0.00    0.00    0.00    2.40\n10:58:00 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle\n<\/code><\/pre>\n
Run it with sync<\/h3>\n
Here is the output of one ‘runit.sh’ when \/u01 was in sync:<\/p>\n
\nDate: Thu May 24 12:18:54 CEST 2018\nDatabase connect string: \"pgio\".\nShared buffers: 128MB.\nTesting 4 schemas with 2 thread(s) accessing 200M (25600 blocks) of each schema.\nRunning iostat, vmstat and mpstat on current host--in background.\nLaunching sessions. 4 schema(s) will be accessed by 2 thread(s) each.\npg_stat_database stats:\n          datname| blks_hit| blks_read|tup_returned|tup_fetched|tup_updated\nBEFORE:  pgio    |   255169 |    119163 |       112734 |        6945 |          18\nAFTER:   pgio    | 15040938 |  74598977 |     87775490 |    86742056 |      337889\nDBNAME:  pgio. 4 schemas, 2 threads(each). Run time: 300 seconds. RIOPS >248266< CACHE_HITS\/s >49285<\n<\/code><\/pre>\n
This shows that, within those 5 minutes, I’ve fetched 86735111 tuples and updated 337871 ones. So, basically the IOPS have been divided by two here in this example when waiting on each writes to be synced to disk.<\/p>\n
pgio takes snapshots of iostat, vmstat and mpstat. Here is a sample after 1 minute of run where we show that all CPU are 30% idle waiting on I\/O completion:<\/p>\n
\n12:19:51 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle\n12:19:54 PM  all   29.95    0.00   27.79   10.88    0.00    1.26    0.00    0.00    0.00   30.13\n12:19:54 PM    0   30.63    0.00   27.46   11.27    0.00    0.70    0.00    0.00    0.00   29.93\n12:19:54 PM    1   30.07    0.00   27.62   12.24    0.00    0.70    0.00    0.00    0.00   29.37\n12:19:54 PM    2   30.28    0.00   27.82   10.92    0.00    0.35    0.00    0.00    0.00   30.63\n12:19:54 PM    3   28.02    0.00   28.02    8.56    0.39    3.89    0.00    0.00    0.00   31.13\n12:19:54 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle\n12:19:57 PM  all   30.10    0.00   27.92   11.24    0.00    1.00    0.00    0.00    0.00   29.74\n12:19:57 PM    0   29.29    0.00   28.57   10.71    0.00    0.36    0.00    0.00    0.00   31.07\n12:19:57 PM    1   30.88    0.00   28.07   11.93    0.00    0.35    0.00    0.00    0.00   28.77\n12:19:57 PM    2   30.31    0.00   27.18   12.54    0.00    0.70    0.00    0.00    0.00   29.27\n12:19:57 PM    3   30.43    0.00   27.67    9.88    0.00    2.77    0.00    0.00    0.00   29.25\n12:19:57 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle\n12:20:00 PM  all   29.51    0.00   27.00   10.76    0.00    1.08    0.00    0.00    0.00   31.66\n12:20:00 PM    0   29.58    0.00   28.17   10.56    0.00    0.35    0.00    0.00    0.00   31.34\n12:20:00 PM    1   29.72    0.00   26.22   12.24    0.00    0.70    0.00    0.00    0.00   31.12\n12:20:00 PM    2   29.12    0.00   26.32   10.88    0.00    0.35    0.00    0.00    0.00   33.33\n12:20:00 PM    3   29.34    0.00   27.80    8.88    0.00    3.09    0.00    0.00    0.00   30.89\n12:20:00 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle\n<\/code><\/pre>\n
So what?<\/h3>\n
Currently, Postgres relies on the filesystem to optimize the I\/O, but there’s a risk of corruption in case of failure. We can force to wait for I\/O completion with the ‘sync’ mount options of the filesystems, or even with some file attributes (chattr -R +S) for ext4 or xfs, but there’s a performance penalty. The important thing is to measure this penalty, and this is where pgio is great: measure the performance penalty with a workload that is customizable (amount of changes, amount of data,…) but also predictable (does not depend on other parameters like an application benchmark). When you know how being in ‘sync’ impacts your system, you can choose. And we can bet that future versions of Postgres will improve and offer ways to stay efficient without compromising the data at first power outage.<\/p>\n","protected":false},"excerpt":{"rendered":"
By Franck Pachot . That’s a long blog post title, which is actually just a good pretext to play with Kevin Closson SLOB method for PostgreSQL: pgio I use the beta version of pgio here. If you want to read more about it, you can start on https:\/\/kevinclosson.net\/2018\/05\/22\/sneak-preview-of-pgio-the-slob-method-for-postgressql-part-i-the-beta-pgio-readme-file\/. If you are used to the SLOB […]<\/p>\n","protected":false},"author":27,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[83],"tags":[1355,1356,77,624],"type_dbi":[],"class_list":["post-11265","post","type-post","status-publish","format-standard","hentry","category-postgresql","tag-fsync","tag-pgio","tag-postgresql","tag-slob"],"acf":[],"yoast_head":"\nPostgres, the fsync() issue, and 'pgio' (the SLOB method for PostgreSQL) - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Postgres, the fsync() issue, and 'pgio' (the SLOB method for PostgreSQL)\" \/>\n<meta property=\"og:description\" content=\"By Franck Pachot . That’s a long blog post title, which is actually just a good pretext to play with Kevin Closson SLOB method for PostgreSQL: pgio I use the beta version of pgio here. If you want to read more about it, you can start on https:\/\/kevinclosson.net\/2018\/05\/22\/sneak-preview-of-pgio-the-slob-method-for-postgressql-part-i-the-beta-pgio-readme-file\/. If you are used to the SLOB […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2018-05-24T11:05:35+00:00\" \/>\n<meta name=\"author\" content=\"Oracle Team\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Oracle Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"7 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"Postgres, the fsync() issue, and ‘pgio’ (the SLOB method for PostgreSQL)\",\"datePublished\":\"2018-05-24T11:05:35+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/\"},\"wordCount\":963,\"commentCount\":0,\"keywords\":[\"fsync\",\"pgio\",\"PostgreSQL\",\"SLOB\"],\"articleSection\":[\"PostgreSQL\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/\",\"name\":\"Postgres, the fsync() issue, and 'pgio' (the SLOB method for PostgreSQL) - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"datePublished\":\"2018-05-24T11:05:35+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Postgres, the fsync() issue, and ‘pgio’ (the SLOB method for PostgreSQL)\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\",\"name\":\"Oracle Team\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"caption\":\"Oracle Team\"},\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/oracle-team\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Postgres, the fsync() issue, and 'pgio' (the SLOB method for PostgreSQL) - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/","og_locale":"en_US","og_type":"article","og_title":"Postgres, the fsync() issue, and 'pgio' (the SLOB method for PostgreSQL)","og_description":"By Franck Pachot . That’s a long blog post title, which is actually just a good pretext to play with Kevin Closson SLOB method for PostgreSQL: pgio I use the beta version of pgio here. If you want to read more about it, you can start on https:\/\/kevinclosson.net\/2018\/05\/22\/sneak-preview-of-pgio-the-slob-method-for-postgressql-part-i-the-beta-pgio-readme-file\/. If you are used to the SLOB […]","og_url":"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/","og_site_name":"dbi Blog","article_published_time":"2018-05-24T11:05:35+00:00","author":"Oracle Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Oracle Team","Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"Postgres, the fsync() issue, and ‘pgio’ (the SLOB method for PostgreSQL)","datePublished":"2018-05-24T11:05:35+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/"},"wordCount":963,"commentCount":0,"keywords":["fsync","pgio","PostgreSQL","SLOB"],"articleSection":["PostgreSQL"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/","url":"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/","name":"Postgres, the fsync() issue, and 'pgio' (the SLOB method for PostgreSQL) - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2018-05-24T11:05:35+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/postgres-the-fsync-issue-and-pgio-the-slob-method-for-postgresql\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Postgres, the fsync() issue, and ‘pgio’ (the SLOB method for PostgreSQL)"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee","name":"Oracle Team","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","caption":"Oracle Team"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/oracle-team\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/11265","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/27"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=11265"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/11265\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=11265"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=11265"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=11265"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=11265"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}