カテゴリ: linux

https://sourceware.org/ml/libc-alpha/2017-02/msg00079.html

目玉は

- explicit_bzeroのサポート (OpenBSDからの輸入)
- getentropy と getrandom の追加(いままではsyscallを直接呼ぶしかなかった)
- malloc_get_state と malloc_set_state functions の削除(うわさのemacs専用関数です。つかうのはemacsビルド時だけなのでemacs開発者は./configureを再実行してね)
- GDBのpretty printでmutexとcondition variableがきれいに表示されるように(なんでglibcに関係するんだろう?)
- pthreadの condition variableのアルゴリズムが変更され、順序が強く保証されるように
- pthread_rwlockがよりスケーラブルに

最初の2つが一番影響大きそう





 

6年ぐらい前に、execle, execlp が man では async-signal-safe にリストされてるけど間違ってるよという
チケットを切ったんだけど、ずっと放置されてて

https://bugzilla.kernel.org/show_bug.cgi?id=25292 

6年後に対応してもらえましたよ。実装がなおったんだよね。
glibc 2.24 からexec系 syscall がまともになりました。

https://sourceware.org/bugzilla/show_bug.cgi?id=19534

みんな、Adhemerval Zanella に感謝しよう。

これ結構ひどくて、multi thread で forkした場合は以降は async-signal-safe しか呼んではいけないので
exec呼んだらデッドロックリスクがある(かつmanには書いてない)という、たいそう罠な仕様だったのさ。
アーメン

 

ptraceを無効化してないと、PTRACE_O_SUSPEND_SECCOMP で自由にseccompを無効化できてしまう。
などと書いてある文献を見つけたのでちょっと調査

なお、このコミットだった模様
 
commit 13c4a90119d28cfcb6b5bdd820c233b86c2b0237
Author: Tycho Andersen <tycho.andersen@canonical.com>
Date:   Sat Jun 13 09:02:48 2015 -0600

    seccomp: add ptrace options for suspend/resume

    This patch is the first step in enabling checkpoint/restore of processes
    with seccomp enabled.

    One of the things CRIU does while dumping tasks is inject code into them
    via ptrace to collect information that is only available to the process
    itself. However, if we are in a seccomp mode where these processes are
    prohibited from making these syscalls, then what CRIU does kills the task.

    This patch adds a new ptrace option, PTRACE_O_SUSPEND_SECCOMP, that enables
    a task from the init user namespace which has CAP_SYS_ADMIN and no seccomp
    filters to disable (and re-enable) seccomp filters for another task so that
    they can be successfully dumped (and restored). We restrict the set of
    processes that can disable seccomp through ptrace because although today
    ptrace can be used to bypass seccomp, there is some discussion of closing
    this loophole in the future and we would like this patch to not depend on
    that behavior and be future proofed for when it is removed.

    Note that seccomp can be suspended before any filters are actually
    installed; this behavior is useful on criu restore, so that we can suspend
    seccomp, restore the filters, unmap our restore code from the restored
    process' address space, and then resume the task by detaching and have the
    filters resumed as well.

 

ようするにseccompが有効化されてるコンテナでもCRIUしたいじゃんってことらしい。
えーと、gdbもCRIUも使いたいけど、seccomp迂回は限定したいって時はどうしたら・・・・??



最近Rubyの著名デベロッパのakrさんがAPIデザインケーススタディという書籍を出版された。隙を見ては読んでいるのだけどこれが激烈に面白い。
役にも立たない一般原則とかいっさいすっ飛ばし、実例実例、また実例である。そしてすべての例がOSの制限やら過去との互換性やらいろいろな都合でトレードオフを勘案しながら取りうる選択肢のなかでのベストを見つけていくという題材になっているので話がどれもこれもが超面白い

みんな買おう。


それはさておき、一点だけちょっと微妙な記述をみつけたのでメモっておく。

P128からはじまる Column async-signal-safe関数 だけど
また、実際のところ、子プロセスでasync-signal-safeでない関数を使用す
るのは、珍しいことではありませんでした。たとえば、ネットワークサー
バの作り方の一つとして、クライアントからの接続のたびにforkを行い、
子プロセスでクライアントと通信する形態があります。この場合、子プロ
セスはexecしないので、POSIX的にはasync-signal-safeな関数しか使えませ
ん。しかし、実際にはさまざまな関数がかなり好き勝手に使われます。
 そのようなプログラムをサポートするため、多くのUnixではシングルス
レッドプログラムからforkで子プロセスを作った場合、async-signal-safeで
ない関数も問題なく動作するようになっています。ただし、その動作は
POSIXに反しているため、将来的にも動作が保証されるかはわかりません。

と書いてある(強調は筆者)んだけど、Open Group(現代ではPOSIXと同義)のforkのページを見ると(強調は筆者)
A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. 
なので、async-signal-safeの制限があるのは規格上も multi thread なプログラムだけである。わたしが規格をなにか見落としていないかぎり。




なんかスラドにあげられてしまったので、備忘録てきにちょっとまとめますかね。

きっかけは先月帰国したときに sonots がDeNAをはじめとして、Web企業では広く TCP_TIMEWAIT_LEN を変更してカーネルをリコンパイルして使っているという話を聞いたというもの。以下の様な議論を twitterで行い

Togetter: Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味?: http://togetter.com/li/871768

以下のように、スラドに転載されてしまったわけだ。

スラド: Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味?: http://linux.srad.jp/story/15/09/09/0648258/

いつものように、スラド民は元のスレッドなんかまるで読んでいないので、結論だけ書く。
tcp_tw_interval という TIME-WAIT を変更するsysctlが3年ほど前にupstreamで提案されたが却下されている。

http://thread.gmane.org/gmane.linux.network/244411/

その時の議論の抜粋

・AIXではtcp_timewait というパラメタで、HP-UXでは tcp_time_wait_interval というパラメタで同種の機能(TIME-WAIT変更)がサポートされている。Solarisにも同種の機能あり
・tcp_tw_reuse や tcp_tw_recycle がすでにあるのは知ってるが、NATでうまくいかない時もあるじゃないか
・SO_REUSEADDR使え
・tcp_tw_reuse 使え
・tcp_max_tw_buckets 使え
・early time-wait reuse は validだけど、TIME-WAITを短くするのはたんに危険なだけで意味がない

まだまだ知見を募集中なので、ユースケースとか意見とかありましたら教えて下さい

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

現状、ありとあらゆる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 はもはや推奨ではない。

↑このページのトップヘ