ファイルシステムサイズの拡張時にデータベースアクセスがスローダウンする問題の解決 - Cybozu Inside Out | サイボウズエンジニアのブログ

はじめに こんにちは、技術顧問のsatです。 サイボウズでは、ファイルシステムサイズ拡張時にデータベースアクセスがスローダウンするという問題に長年悩まされてきました。本記事では運用本部の藤田と深谷がこの問題を解決した流れについて報告いたします。問題を解決するために2人はLinuxカーネルを修正しました。修正は社内に閉じたものではなく、執筆当時の最新 Linuxカーネルであるv4.17にマージされています。 問題 以下の操作の後にデータベースへのアクセスが一時的にスローダウンする ブロックデバイスのサイズを拡張する 上記デバイス上にあるファイルシステムのサイズを拡張する 原因 linuxカーネルはブロックデバイスのサイズ変更(縮小および拡張)時に、当該デバイス上にあるファイルシステムのページキャッシュ(後述)を無効化する*1 解決方法 ブロックデバイスのサイズ拡張時にはページキャッシュを無効

[smbd]

まったく本筋じゃないけど、ファイルシステムのサイズが足りなくなるほど巨大なSQLiteって、ちゃんと動くんだなぁ。なんでSQLiteを使ってるのかも知りたい。

[stealthinu]

『このメールはlinuxコミュニティの誰からも返事がもらえませんでした』大きなプロジェクトにパッチ投稿して反応もらえなかったりネガティブな反応だとそれだけで心が折れる。すげえなあ。

[sora_h]

SQLiteのつかいみちの方が気になる

[atsuizo]

“これはソース修正の手間は変更の行数に比例しないといういい例”

[nicht-sein]

"ソース修正の手間は変更の行数に比例しないといういい例"ほんとこれ！調査と影響範囲の精査がどれだけめんどいことか。。。

[n314]

問題解決能力が高い例

[khtno73]

『深谷はこの後、関連ソースの全調査によって、サイズ縮小直後に拡張したとしてもカーネル内の排他制御により上記の問題は起こりえないことを突き止めました』

[gfx]

おお、すごい。upstreamにも適用されてるので我々もこの修正を享受できる！👏

[hiboma]

ページキャッシュが原因であるところでゴールとして諦めてしまいそうだが、その先が解決されててすごいなぁ + おもしろかった

[hiromi_ayase]

SQLiteは速度的には最強というイメージがある。特に単一プロセスから使うのであれば基本的にはSQLiteかまたは組み込みに特化したDBを使うべきだが、意味もなく別プロセスで動くDBMS使ってるの多すぎる。

[ilyaletre]

さらっと全関連ソースの調査とか書いてあるけど大変だったろう。

[ono_matope]

かっこいいなー。こうありたい。

[walkingmask]

素晴らしい。「おわりに」が秀逸。

[tmatsuu]

素晴らしい。この恩恵は大きいはず

[mkusunok]

素晴らしい改善。こうした積み重ねの上にオープンソースが成り立ってる

[Nyoho]

素晴らしい。"4行の追加、2行の削除に過ぎませんが、ここにたどり着くまでに上記のような様々な試行錯誤がありました。これはソース修正の手間は変更の行数に比例しないといういい例"

[teppeis]

サイボウズっぽい真っ当エンジニアリング事例

[naaaaaaaaaaaf]

すごい

[kazuhooku]

顧客ごとにSQLiteなファイル作ってデータ入れることで、RDBMSにおけるマルチテナンシー問題を回避してるってことなんかな

[carrion-crow]

すごいなー。「サイズ縮小直後に拡張したとしてもカーネル内の排他制御により上記の問題は起こりえないことを突き止めました」他の箇所で対策してて、実は不要だった例外処理って良くある（やる）印象。

[threetea0407]

「深谷はこの後、関連ソースの全調査によって、サイズ縮小直後に拡張したとしてもカーネル内の排他制御により上記の問題は起こりえないことを突き止めました。」さらっと書いてあるけどここが一番やばい。

[rizenback000]

“これはソース修正の手間は変更の行数に比例しないといういい例ではないでしょうか。”

[ledsun]

修正箇所を最小に絞り込むには、技術力が必要ですね！

[a-know]

素晴らしい

[kagerou_ts]

つよい

[W53SA]

“関連ソースの全調査”気合を感じる。。。。

[BRITAN]

“この問題の修正パッチは二千万行におよぶlinuxカーネルのソースコードの中のたった4行の追加、2行の削除に過ぎませんが、ここにたどり着くまでに上記のような様々な試行錯誤がありました。”←おつかれさまでした！

[TakayukiN627]

これはソース修正の手間は変更の行数に比例しないといういい例ではないでしょうか。

[koyancya]

“この問題の修正パッチは二千万行におよぶlinuxカーネルのソースコードの中のたった4行の追加、2行の削除に過ぎませんが、ここにたどり着くまでに上記のような様々な試行錯誤がありました”

[i000i0]

upstreamにパッチ投げるところまでちゃんとやっていて素晴らしい

[t-cyrill]

“ブロックデバイスのサイズ拡張時にはページキャッシュを無効化しないようにlinuxカーネルを変更する”しれっと書いてあるけどマジでか

[sharaku3eyes]

ヤバイ

[chimerast]

どんな特性のブロックデバイスでもこのパッチをあてて問題ないのかが気になった。昔の感覚だと実稼働中のファイルシステムをオンライン拡張とか危なくてやらないので、安全側に倒す意図でそうなってたんだと思う。

[kuxumarin]

読みやすくてすこ