Исходные данные
Debian 8, MongoDB 3.2 реплика из трех серверов, SSD, XFS для /var/lib/mongodb, Raid 1 с помощью mdadm.
Официальная документация MongoDB советует использовать XFS для хранения файлов базы.
Заметил, что иногда база начинает тормозить на secondary серверах на самых примитивных запросах, запрос по ключу мог выполняться 5-10 секунд. Помогал рестарт базы и некоторое время все хорошо работало.
Выяснил, что диск постоянно перегружен и имеем высокий svctm, хотя фактически операций и записываемых данных очень мало.
iostat -dmx 3 5 sdb sda md4
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 100.67 0.00 281.00 0.00 1.26 9.16 0.80 2.83 0.00 2.83 2.82 79.20
sda 0.00 100.67 0.00 281.00 0.00 1.26 9.16 0.86 3.07 0.00 3.07 3.06 85.87
md4 0.00 0.00 0.00 377.67 0.00 1.25 6.75 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 94.00 0.00 277.00 0.00 1.22 9.00 0.81 2.94 0.00 2.94 2.88 79.73
sda 0.00 94.00 0.00 277.00 0.00 1.22 9.00 0.85 3.06 0.00 3.06 3.04 84.13
md4 0.00 0.00 0.00 364.67 0.00 1.20 6.71 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 92.00 0.00 263.67 0.00 1.18 9.19 0.77 2.93 0.00 2.93 2.91 76.80
sda 0.00 92.00 0.00 263.67 0.00 1.18 9.19 0.78 2.95 0.00 2.95 2.94 77.60
md4 0.00 0.00 0.00 353.33 0.00 1.18 6.82 0.00 0.00 0.00 0.00 0.00 0.00
Причем на мастер сервере нагрузка на диск меньше в 3-4 раза, чем на secondary, хотя должно быть наоборот, но тоже большая. На чтение идут запросы ко всем серверам равномерно.
Опытным путем пришел к тому, что опция nobarrier для XFS оказалась решением проблемы.
Так же нашел несколько статей, где как раз советуют для баз данных использовать nobarrier. (
https://www.slideshare.net/bytebot/tuning-linux-fo... https://docs.microsoft.com/ru-ru/azure/virtual-mac... )
iostat -dmx 3 5 sdb sda md4
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 121.67 25.67 496.33 0.36 1.77 8.36 0.03 0.05 0.36 0.03 0.05 2.53
sda 0.00 121.67 0.33 496.33 0.00 1.77 7.32 0.03 0.05 0.00 0.05 0.04 2.00
md4 0.00 0.00 26.00 614.33 0.36 1.76 6.79 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 115.00 34.33 463.67 0.47 1.69 8.91 0.03 0.07 0.27 0.05 0.07 3.47
sda 0.00 115.00 1.67 463.67 0.05 1.69 7.66 0.03 0.07 0.00 0.07 0.06 2.93
md4 0.00 0.00 36.00 577.00 0.52 1.69 7.38 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 121.67 18.33 477.00 0.27 1.72 8.21 0.03 0.06 0.36 0.05 0.06 2.93
sda 0.00 121.67 1.00 477.00 0.08 1.72 7.70 0.03 0.07 0.00 0.07 0.06 2.80
md4 0.00 0.00 19.33 596.67 0.35 1.71 6.85 0.00 0.00 0.00 0.00 0.00 0.00
Про nobarrier в статье
tolstiyman.blogspot.ru/2013/07/etcfstab.html прочел следующее
barrier - используя "шлагбаум"(barrier) файловая система запрещает запись блоков данных, пришедших после "шлагбаума", пока все предшествующие ему не будут перенесены на диск; таким образом достигается высокая надежность в ущерб быстродействию; отключая "шлагбаум" (barrier=0, nobarrier), мы ускоряем запись на раздел
Какие ужасные последствия может повлечь использование nobarrier?
И почему barrier так сильно влияет на производительность?
Сложный
Простой
