タイトルは釣りです。はい。

現状、ありとあらゆるDBがTHPをdisableするよう推奨している。これはあんまり良い状況じゃないのでTHPを disabled by default に変えようという提案。
Ted Ts'o はデフォルトがenabledだから、パフォーマンスが良くなるケースが気づきにくいだけだろうと主張。まあ、そうだろうね。KVM hostとかだと anon ばっかりつかうし、guest OSでメモリ制限あるから、hostのreclaimは走らないしで、悪いケースになりにくそう。
Vlastimil Babka はそもそも page faultの延長で、コンパクション始めちゃうのがよくないので、デフォルトは今より less aggressiveであるべきという意見のようだ。

Googlerが今のままがいいと主張していて、エンタープライズ屋さんが変えたいという陣営なのかな。

http://www.spinics.net/lists/linux-mm/msg93357.html

As a general purpose sysadmin I've mostly struggled with its default being always, if it were never (or possibly madvise?) then I think all the very real performance problems would go away. Those who know they need it could turn it on. I have begun looking into asking the distros to change this (is it a distro choice?) but am not getting that far. Just to be clear the default of always causes noticeable pauses of operation on almost all databases, analogous to having a stop the world gc.

As for THP in APU type applications have you run into any JEMalloc defrag performance issues? My research into THP issues indicates this is part of the performance problem that manifests for databases.


Some more links to discussion about THP:

Postgresql https://lwn.net/Articles/591723/

Postgresql http://www.postgresql.org/message-id/20120821131254.1415a545@jekyl.davidgould.org

Mysql (tokudb) https://dzone.com/articles/why-tokudb-hates-transparent

Redis http://redis.io/topics/latency http://antirez.com/news/84

Oracle https://blogs.oracle.com/linux/entry/performance_issues_with_transparent_huge

MongoDB http://docs.mongodb.org/master/tutorial/transparent-huge-pages/
Couchbase http://blog.couchbase.com/often-overlooked-linux-os-tweaks

Riak http://underthehood.meltwater.com/blog/2015/04/14/riak-elasticsearch-and-numad-walk-into-a-red-hat/



※ 追記
Hadoop界隈でもdisable必須らしい。shiumachiさん、ありがとう。
https://twitter.com/shiumachi/status/639265740713885696

※ このあとTHP作者の Andrea Arcangeli の反論が投稿されてて結構おもしろかったので抜粋
・OracleがTHPで性能かわるはずねーだろ。Oracle SGAは1GB hugetlbfsを使うようデザインされてるんだぞ。
Oracleがへんな推奨だしてるのはunbreakable Linuxがバグってるだけだろ
・redisではたしかにTHPは問題がある。redisはsnapshotを取るためにfork()を使うが、このスナップショットをとっている
最中に親(元々のプロセス)がメモリに書き込みを行うと2MBのアロケーション+2MBのメモリコピー(4MBのメモリアクセス)
が発生する。これは4KBのアロケーション+コピーよりペナルティがはるかに大きい。
しかし、これはredisが userfaultfd を使うようにすれば解決する(※ するわけねーだろ)
・いくつかのalternative malloc(※ jemallocのこと)は積極的にMADV_DONTNEEDを使うので、このタイミングでページが
4kにバラされてしまい、またallocateしたあとで、2MBにするためにコンパクション走るために遅くなる。これは
alternative mallocが明示的にMADV_NOHUGEPAGE を呼ぶことにより解決できる
(※ mallocでdisableしちゃったら、システムでdisableするのとあんまり変わらないと思うぞ。と心のなかでツッコミ)
・みながTHP問題という場合、たいていは実際にはcompactionの性能問題である。その場合
echo madvise >/sys/kernel/mm/transparent_hugepage/defrag
として、compactionを走らなくさせることにより劇的に改善する

How to collect logs from a Red Hat OpenStack Platform environment https://access.redhat.com/solutions/705033

めも。
sosreportでOpenStackのログを収集できるが、

sosreport --enable-plugins=openstack_ceilometer,openstack_cinder,openstack_glance,openstack_heat,openstack_horizon,openstack_keystone,openstack_nova,openstack_sahara,openstack_swift

のようなクソ長いオプションが必要。
rhos-log-collector はもはや推奨ではない。

完全に自分用メモ


robocopy src dst /MIR /R:0 /W:0 /LOG:logfile.txt /NDL /TEE /XJD /XJF /DCOPY:T

/MIR
バックアップ元とバックアップ先をミラーリングします。
/R:0
ファイルコピーに失敗した場合に再度コピーを試す回数です。
/W:0
再試行する時の待ち時間(秒)です。
/LOG:
ログファイル名
/NP
バックアップ中の進行状況を表示しません。
/NDL
バックアップ結果として、ログファイルにファイルのみが出力されるようになります。
/TEE
バックアップの結果をコマンドプロンプトとログファイルの両方に出力します。
/XJD
フォルダのジャンクション・ポイントを除外する
/XJF
ファイルのジャンクション・ポイントを除外する

/DCOPY:T
日付を保存

以下は完全に自分用メモ

■インストールしたソフトウェア一覧
Google IME
DropBox
Chrome
1password
hidemaru
Tera Term
Auto HotKey
Explzh
Firefox
Skype
Lime Chat
VMware Player
Virtual Box
changekey
Dexpot

何も入れてないようでいて、いろいろと入れてるな。標準パッケージがないことがWindowsの
セットアップをめんどくさく、時間がかかるものにしていることがわかる

■バックアップをとらないといけない場所
C:\cdimage
C:\Thunderbird_mailbox
C:\users\kosakimo
C:\Users\kosakimo\AppData\Roaming\LimeChat2
C:\Users\kosakimo\AppData\Roaming\Thunderbird
C:\Users\kosakimo\AppData\Roaming\Mozilla\Firefox
C:\Program Files (x86)\teraterm\ttpmenu.ini

LimeChatとTeraTermのバックアップいつも忘れる

昔、kernel watch で真のO_SYNCサポートについての記事(※下記参照)を書いたことがあるんだけど、RHELではちょっと事情が違うことがわかった。

http://www.atmarkit.co.jp/flinux/rensai/watch2009/watch12b.html

時系列でいうと、まずkernel 2.6.33でO_SYNCサポートが入り(上記記事)、glibc 2.12 でそれに対応するためのヘッダファイル修正が入ったんだけど、RHEL6は kernel 2.6.32 + glibc 2.12 なんだな。

だからRHEL6でコンパイルしたアプリをRHEL6で実行するケース
→ O_SYNCはの実体は (__O_SYNC|O_DSYNC) なんだけど、カーネルのほうに、_O_SYNCの定義がないので、その部分は無視されて、O_DSYNCとして動作

RHEL6でコンパイルしたアプリをRHEL7で実行するケース
→ カーネルに_O_SYNCの実体があるので、O_SYNCが正しくO_SYNCとして動く

つまり、OSをバージョンアップするとアプリの挙動が変わってしまう。コミュニティ開発者がとんでもなく苦労して後方互換性を維持してもディストリのうっかりで台無しになることもあるよという例でした。

まあ、O_SYNCを使ってるのに、O_DSYNCセマンティクスを仮定してるアプリがいたら、そいつがアホという意見には同意する。同意するが、後方互換性とはそういうものじゃないんだよ。バグ互換も含めて考えるのが互換性。

↑このページのトップヘ