{"id":117,"date":"2011-01-26T09:27:07","date_gmt":"2011-01-26T15:27:07","guid":{"rendered":"http:\/\/soljerome.com\/blog\/?p=117"},"modified":"2011-01-26T09:27:07","modified_gmt":"2011-01-26T15:27:07","slug":"ext4-and-sqlite","status":"publish","type":"post","link":"https:\/\/www.soljerome.com\/blog\/2011\/01\/26\/ext4-and-sqlite\/","title":{"rendered":"ext4 and sqlite"},"content":{"rendered":"

I was recently setting up DBStats<\/a> for a Bcfg2 installation and was having some serious performance issues when a client was uploading statistics to the server.<\/p>\n

\r\nhwfwrv003.web.e.uh.edu:probe:current-kernel:['2.6.18-194.26.1.el5']\r\nhwfwrv003.web.e.uh.edu:probe:groups:['group:rpm', 'group:linux', 'group:redhat', 'group:redhat-5Server', 'group:redhat-5', 'group:x86_64']\r\nGenerated config for hwfwrv003.web.e.uh.edu in 0.044s\r\nHandled 1 events in 0.000s\r\nClient hwfwrv003.web.e.uh.edu reported state clean\r\nImported data for hwfwrv003.web.e.uh.edu in 139.942095041 seconds\r\n<\/pre>\n
This is drastically slower than normal. So, I remounted the sqlite database on a ramdisk.<\/p>\n
\r\n# losetup \/dev\/loop0 \/bcfg2\/bcfg2.sqlite\r\n# mount -t ramfs \/dev\/loop0 \/bcfg2\/\r\n# mount | grep ramfs\r\n\/dev\/loop0 on \/bcfg2 type ramfs (rw)\r\n<\/pre>\n
Here is the time it took once I moved the sqlite database to a ramdisk.<\/p>\n
\r\nhwfwrv003.web.e.uh.edu:probe:current-kernel:['2.6.18-194.26.1.el5']\r\nhwfwrv003.web.e.uh.edu:probe:groups:['group:rpm', 'group:linux', 'group:redhat', 'group:redhat-5Server', 'group:redhat-5', 'gr\r\noup:x86_64']\r\nGenerated config for hwfwrv003.web.e.uh.edu in 0.074s\r\nHandled 1 events in 0.000s\r\nClient hwfwrv003.web.e.uh.edu reported state clean\r\nImported data for hwfwrv003.web.e.uh.edu in 1.16791296005 seconds\r\n<\/pre>\n
That’s faster by a factor of almost 120! As you can see, something is very odd with the performance hit we are taking when using an ext4 filesystem. Just for comparison, I created an ext3 partition to hold the sqlite database.<\/p>\n
\r\n# mount | grep foo\r\n\/dev\/loop1 on \/foo type ext3 (rw)\r\n# ls \/foo\/\r\nbcfg2.sqlite\r\n<\/pre>\n
Here is the same client update again when using ext3 to hold the sqlite database.<\/p>\n
\r\nhwfwrv003.web.e.uh.edu:probe:current-kernel:['2.6.18-194.26.1.el5']\r\nhwfwrv003.web.e.uh.edu:probe:groups:['group:rpm', 'group:linux', 'group:redhat', 'group:redhat-5Server', 'group:redhat-5', 'gr\r\noup:x86_64']\r\nGenerated config for hwfwrv003.web.e.uh.edu in 0.037s\r\nHandled 1 events in 0.000s\r\nClient hwfwrv003.web.e.uh.edu reported state clean\r\nImported data for hwfwrv003.web.e.uh.edu in 1.60297989845 seconds\r\n<\/pre>\n
I was finally able to track this down to a change in the default kernel configuration used by Ubuntu for ext4 filesystems. The change is detailed at \ufeff\ufeff\ufeffhttps:\/\/bugs.launchpad.net\/ubuntu\/+source\/linux\/+bug\/588069<\/a>. Ubuntu apparently decided it was a good idea to turn on barriers by default in 10.04 (Lucid). Luckily, I was able to remount the ext4 partition without barriers (-o barrier=0) and the performance dropped back down to something more reasonable.<\/p>\n
\r\nhwfwrv003.web.e.uh.edu:probe:current-kernel:['2.6.18-194.26.1.el5']\r\nhwfwrv003.web.e.uh.edu:probe:groups:['group:rpm', 'group:linux', 'group:redhat', 'group:redhat-5Server', 'group:redhat-5', 'gr\r\noup:x86_64']\r\nGenerated config for hwfwrv003.web.e.uh.edu in 0.038s\r\nHandled 1 events in 0.000s\r\nClient hwfwrv003.web.e.uh.edu reported state clean\r\nImported data for hwfwrv003.web.e.uh.edu in 6.47736501694 seconds\r\n<\/pre>\n
That’s still much<\/strong> slower than ext3, but it’s at least acceptable in this particular case.<\/p>\n
While I can understand the reasoning behind changing something like this, it does not appear to be a good idea to drastically reduce the performance of a LTS release without at least warning people VERY LOUDLY<\/strong>.<\/p>\n
More information about this can be found at http:\/\/lwn.net\/Articles\/283161\/<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
I was recently setting up DBStats for a Bcfg2 installation and was having some serious performance issues when a client was uploading statistics to the server. hwfwrv003.web.e.uh.edu:probe:current-kernel:[‘2.6.18-194.26.1.el5’] hwfwrv003.web.e.uh.edu:probe:groups:[‘group:rpm’, ‘group:linux’, ‘group:redhat’, ‘group:redhat-5Server’, ‘group:redhat-5’, ‘group:x86_64’] Generated config for hwfwrv003.web.e.uh.edu in 0.044s Handled 1 events in 0.000s Client hwfwrv003.web.e.uh.edu reported state clean Imported data for hwfwrv003.web.e.uh.edu in 139.942095041 […]<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[7,12,3],"tags":[],"_links":{"self":[{"href":"https:\/\/www.soljerome.com\/blog\/wp-json\/wp\/v2\/posts\/117"}],"collection":[{"href":"https:\/\/www.soljerome.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.soljerome.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.soljerome.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.soljerome.com\/blog\/wp-json\/wp\/v2\/comments?post=117"}],"version-history":[{"count":5,"href":"https:\/\/www.soljerome.com\/blog\/wp-json\/wp\/v2\/posts\/117\/revisions"}],"predecessor-version":[{"id":123,"href":"https:\/\/www.soljerome.com\/blog\/wp-json\/wp\/v2\/posts\/117\/revisions\/123"}],"wp:attachment":[{"href":"https:\/\/www.soljerome.com\/blog\/wp-json\/wp\/v2\/media?parent=117"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.soljerome.com\/blog\/wp-json\/wp\/v2\/categories?post=117"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.soljerome.com\/blog\/wp-json\/wp\/v2\/tags?post=117"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}