xfs stack overflow

XFS でスタックがオーバーフローするから避けたほうがいいんじゃないか的まとめ
xfs MySQL Linux
10145view 1コメント
9
Kazuho Oku @kazuho
@kosaki55tea サーバ系だと、ディスクにデータを保存するたぐいのプログラムはfsyncしまくるし、オンメモリのやつは swap に落ちるだけなので、例外パスで xfs が呼ばれることは、ほとんどないんじゃないかなーと
KOSAKI Motohiro @kosaki55tea
@kazuho でもhumyo.comはスタックオーバーフローで落ちまくってると報告されているからWeb系のサーバ運用だとダメってことよ?
Yoshinori Matsunobu @matsunobu
.@kazuho @kosaki55tea ML見るとbuffered writeしているようですが、ダイレクトI/Oで回避できないでしょうかね。
Kazuho Oku @kazuho
Web サービス界隈だと、そもそも ext3 がほとんどだったのが、MySQL のユーザーが一部 xfs 化しはじめた、みたいな印象 (観測範囲狭いですが)
KOSAKI Motohiro @kosaki55tea
無理。トリガーはwrite syscallではなくキャッシュ回収処理の延長なので1ページでもキャッシュが載っていれば呼ばれる可能性ある RT @matsunobu @kazuho buffered writeしているようですがダイレクトI/Oで回避できない
KOSAKI Motohiro @kosaki55tea
どうしてext4は避けられているのでしょう? RT @kazuho Web サービス界隈だと、そもそも ext3 がほとんどだったのが、MySQL のユーザーが一部 xfs 化しはじめた、みたいな印象 (観測範囲狭いですが)
KOSAKI Motohiro @kosaki55tea
DirectIOだと別のプロセスがキャッシュを乗せてしまうのを防げないので @matsunobu @kazuho
Kazuho Oku @kazuho
キャッシュに載ってるページが dirty でなければ、xfs は呼ばれないから問題ないんじゃないのかしら
Kazuho Oku @kazuho
ext3 は枯れてて安心だし、ext4 で速くなるよ!って話が広まらない限り、みんな ext3 使い続ける、みたいなw
KOSAKI Motohiro @kosaki55tea
それは正しいけどdirtyなページが無いことを保証するのは実際には無理。syslogとか色々デーモンいますし RT @kazuho: キャッシュに載ってるページが dirty でなければ、xfs は呼ばれないから問題ないんじゃないのかしら
KOSAKI Motohiro @kosaki55tea
むしろ遅いですけどねext4。まあいくつかの遅いオプションがデフォルトになっているのが主因なので設計ミスではないが RT @kazuho: ext3 は枯れてて安心だし、ext4 で速くなるよ!って話が広まらない限り、みんな ext3 使い続ける、みたいなw
KOSAKI Motohiro @kosaki55tea
XFSのdelayed allocationのほうが遙かにヒドイ壊れ方をするはずだが RT @smbd: @kosaki55tea なんとなく不安定そうなイメージがあるから?あとアプリが悪いのだけど、commit間隔の件が大々的に報じられてイメージが悪いとか?
Kazuho Oku @kazuho
同意です。たとえ運用でごまかせたとしても、そういう問題のある fs は避けたいですねorz RT @kosaki55tea: それは正しいけどdirtyなページが無いことを保証するのは実際には無理。syslogとか色々デーモンいますし RT @kazuho: キャッシュに載...
KOSAKI Motohiro @kosaki55tea
RHELを語るならXFSも土俵は同じではないかな RT @smbd: @kosaki55tea 不安定そう、っていうのは開発が開始してあまり日が経ってないからとか、ext4を採用したRHELが出ていなくて(RHEL6はdefault ext4みたいですけど)揉まれてなさそうとか
Kazuho Oku @kazuho
MySQL 屋さんの場合だと、xfs が壊れてもレプリケーションがあるさ、で片付くのかも。たいていの大規模運用の場合は。
Yoshinori Matsunobu @matsunobu
@kosaki55tea MySQL(InnoDB)では「mysqldプロセス以外は誰も読み書きしない巨大データファイルをダイレクトI/O(バックアップとかは例外)」というのが典型的な使われ方なんですが、これなら回避できるんじゃないでしょうか。
KOSAKI Motohiro @kosaki55tea
ファイルシステムがMySQL専用なら大丈夫な気がします RT @matsunobu: @kosaki55tea MySQL(InnoDB)では「mysqldプロセス以外は誰も読み書きしない巨大データファイルをダイレクトI/O(バックアップとかは例外)」というのが典型的な使われ方な
KOSAKI Motohiro @kosaki55tea
一日に5回も6回も落ちるとか言われているので相当厳しいと思うが RT @kazuho: MySQL 屋さんの場合だと、xfs が壊れてもレプリケーションがあるさ、で片付くのかも。たいていの大規模運用の場合は。
Kazuho Oku @kazuho
write >> read で fsync してないファイルサーバとかならともかく、O_DIRECT 前提な MySQL サーバが、そんな高確率で落ちてるんですか? RT @kosaki55tea: 一日に5回も6回も落ちるとか言われているので相当厳しいと思うが...
Yoshinori Matsunobu @matsunobu
@kosaki55tea ありがとうございます。自分が知る限り、「MySQLデータ領域用に独立したxfsファイルシステム + InnoDB + ダイレクトI/O」が(xfsを使う場合の)定番で、Facebookもこの構成だと聞いています。
KOSAKI Motohiro @kosaki55tea
@kazuho あ、ごめんなさい。元々の話はMySQLじゃないです。MogileFSとかいうKVS
Kazuho Oku @kazuho
MySQL(InnoDB) でページアウトが発生する場合、その対象になる可能性が一番高いのは InnoDB のバッファプールだし、バッファプールのページアウトが発生しないようにチューニングするのが基本になってると思います
KOSAKI Motohiro @kosaki55tea
@matsunobu なるほど。勉強になります。humyo.comの構成がヘンという理解をしました
KOSAKI Motohiro @kosaki55tea
@kazuho いやー、最近のlinuxはlumpy reclaimがあるのでチューニングではpageout 0には出来ませんよ。限りなく少なくは出来るけど
残りを読む(36)
ログインして広告を非表示にする
ログインして広告を非表示にする