Money Forwardについての不満がいろいろ溜まってきたので忘れないようにメモる。超個人メモなので、気にしないように

MFのアプリを開くと目立つ所に資産総額と前日比が表示される。


前日比
 
わたしはこれが気に入らない。なぜ気に入らないのかしばらく自分でうまく言語化できなかったが、少しづつわかってきたので書いてみる。

まず、前日比が一見タップすると反応するように見えて、それは資産総額をタップされた事になっている
(タップの反応範囲がおかしい)ので、前日比の詳細を見たいのに、資産一覧(もってる口座一覧)が
出てきて非常に混乱する。
直感的なのは、前日比からの変化の原因になってレコード一覧が出てくることである
(前日付の支出全部と、変化のあった株一覧)

しかし、よく考えてみると、前日からの差分という考え方がMoney Forwardのサービスのありかたとマッチしていない。MFを使う以上はきっとユーザはいつもニコニコ現金払いではなくクレカなどで支払い、MFの自動記帳を
使っていると思う。ところがクレカのレコードは一週間に一度反映とか珍しくないので毎日速報なんて出ないのである。
よってこの前日比はただの飾りです偉い人にはそれがわからんのです状態。意味が無い。

このUIだとユーザにクレカよりも現金払いを推奨していることになるのだが、分かっているのだろうか?ダメUIなので、再考してほしい。週ごと、月ごとの差分なら株も現金もクレカも困らないのに。

・・・・・ということを後日MFの人にいうための備忘録。


 

最近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を走らなくさせることにより劇的に改善する

↑このページのトップヘ